Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Absolute mode isn't sticky, leading to continuous relative/absolute transitions #74

Open
fake-name opened this issue Dec 29, 2021 · 2 comments

Comments

@fake-name
Copy link
Contributor

I'm doing some gcode generation that uses entirely absolute moves.

Every single move winds up surrounded by a G90/G91 pair:


G90 ;absolute
G1 X5.000000 Y5.000000 Z5.600000
G91 ;relative
G90 ;absolute
G1 X5.750000 Y5.000000 Z5.600000
G91 ;relative
G90 ;absolute
G0 X5.750000 Y5.000000 Z16.000000
G91 ;relative
G1 F3.0
G90 ;absolute
G0 X6.250000 Y6.000000 Z16.000000
G91 ;relative
G90 ;absolute
G0 Y6.000000 Z5.750000
G91 ;relative
G90 ;absolute
G0 X6.250000 Y6.000000 Z5.750000
G91 ;relative
G90 ;absolute
G1 X6.000000 Y6.000000 Z5.750000
G91 ;relative

Looking at the code, this seems to be because nothing can ever set the gcode writer to absolute mode other then an explicit call to absolute().

It seems to me that if you call an absolute move call, it should set the state to absolute and leave it there, until any call to a relative motion function.

@DerAndere1
Copy link
Contributor

The described behaviour only occurs with abs_move(). If you don't like its behaviour, use move() instead of abs_move(). then, mode can be set with absolute() and relative() as you mentioned. One could argue that rel_move()should be implemented for symmetry with abs_move().

I like the idea of being able to set the default mode to absolute during instantiation of the G class. If I am not mistaken, that will be added in #75

@fake-name
Copy link
Contributor Author

fake-name commented Mar 15, 2022

I get that,

The main issue I have here is the ridiculous, continuous

G91 ;relative
G90 ;absolute

output.

I'm using calls to abs_move() because I'm exclusively doing absolute moves, and having the calls explicitly include abs makes the intension clearer.

Effectively, G91 should only be emitted before a G0 that uses absolute coordinates where the machine is in relative mode, and G90 should only be emitted if the machine is in absolute mode, and a G0 is emitted that needs to use relative motion. This does mean the G object needs to track some additional state, unfortunately.

My g-code files are 60% G90/G91 without changes that implement the above.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants