We allow 'stacking' of MDI commands - is it OK ???

snowgoer540 wrote:

spumco wrote:

@snowgoer540 - 

Your earlier response prompted me to read the NIST rs274 document, and both it and LCNC's manual have this to say:

(rs274 v3 - 3.6.1)

Note: It is OK to program M0 and M1 in MDI mode, but the effect will probably not be noticeable, because normal behavior in MDI mode is to stop after each line of input anyway.


Does this jibe with your understanding of how MDI is working?  The NIST document doesn't discuss external python commands, of course.


Morning fellas!

I did see that, but I didn't take that to mean that stacking is unallowable. That does - at least high level - describe the behavior of the MDI, stacked or otherwise. Each line is executed and the motion stops. It just so happens if there's another command queued, it moves on and executes that. Thus rendering M0 or M1 pointless since any motion would have already stopped when it gets to it. Sort of like I said earlier, if you want it to have no more motion after a command, don't send any more :)

I say "at least high level" because stacked gcode commands will be subject to G64 path blending, which shows that the interpreter is looking ahead at "stacked" MDI commands. Which to me, is evidence that multiple MDI commands was planned for (at the core LinuxCNC level) and is therefore perfectly valid.

I guess the thing I wonder is - the capability exists and is even planned for, so why is that a problem? If you don't want it to continually execute MDI commands is not the solution then to refrain from entering more than one at a time? I'm not sure what problem removing stacked commands would be solving? It seems to me that the perception that this is "wrong" comes from the knowledge of what other controllers do and do not allow.