On 2020-04-18 10:35 p.m., Robert Ellenberg wrote:
Well it does.
ie G10 adjust the tool offsets.
How tool offsets work are defined by the Gcode rules.
We could produce a different interpreter that converts ChrisMorley code
into motion moves.
maybe it doesn't have tool offsets, linuxcnc motion would be fine with it.
It's the interpreter that converts users made code into motion moves.
This does seem to be the crux of the problem - motion needs to know some
things about the parent language that the motion moves comes from. This
is what state tags does.
Chris, one little nitpick: state tags exist BECAUSE motion doesn't know
anything about the interpreter state. It's a way for motion to report what
the state was that generated a motion command, without having to understand
or use any of it directly. There are a few small exceptions (like peeking
at the spindle command speed to check if a synced move is safe), but mostly
motion doesn't care about the state tag.
Thanks for correcting me I'm learning as I discuss.
Now if you want motion to do such things as step each line of gcode,
then motion would start to need to know more what the gcode, would it
not? I guess not but we would need to have more motion commands that are
used to sync things? I am not up on statetags (or really any of this
much - trying to get it clear in my head.)
Chris
_______________________________________________
Emc-developers mailing list
Emc-developers@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/emc-developers
