phord/Teacup_Firmware — comment on commit 522b863ee80254b7870835856f2cd4748522ee52
File:  line 0
By phord:

I actually added the config structure because I had plans to expand it with other config data, like x/y/z/e scaling (dynamic steps_per_m for easier calibration). Also, I tried to remove the one "unavoidable" division per calculation by prescaling the divisor to a power of 2 instead of a power of 10 (meters). I kept the prescaled steps_per_m here in the config structure. But I had some overflow problem on negative values in my division, so I put it on hold for now.

I wasn't certain of the usage of next_target and move_state (unfamiliar code) so I didn't feel comfortable adding my fields there. But also I was thinking of the absolute_e value as a config-global setting, not one that you would typically change on the fly. But I can see how some g-code generator may have different ideas and take liberties with m82/m83 that I'm not prepared to handle.

I've been experimenting with two or three different slicers and they all have their quirks. Some of them just work better in absolute mode, it seems. So I've gotten used to adding m82 or m83 as appropriate for each one in my resulting g-code since I created this patch.

I updated update_current_position as rote. I essentially replaced the MACRO-using logic with variable-using logic across the board. I don't see any reason to treat one case as special.

I think M82/M83 should be processed the same way M90/M91 is.

I think you are right. I didn't look at that closely, but I understand it more now in the context of this discussion.