- Posts: 596
- Thank you received: 98
Please Log in or Create an account to join the conversation.
Please Log in or Create an account to join the conversation.
@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)
Code: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.
Please Log in or Create an account to join the conversation.
This depends on whether the MDI widget uses more GUI than Gmoccapy. If yes, please move. I didn't know exactly where to put this thread. I also considered the GladeVCP topic, but I don't know if the MDI widget is made in glade.
If I were a rentier and I didn't have to go to work, I would study programming at university.
Please Log in or Create an account to join the conversation.
That's pretty much what I said, this behavior is likely intended but not well developed for external command feeding. The question here I suppose is "Is this useful/wanted in Gmoccapy?" Probably not, so Gmoccapy should take some steps to prevent it. It's easy to say "just don't do it" but fat fingers and touchscreens.....
@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)
Code: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.
Please Log in or Create an account to join the conversation.
That's pretty much what I said, this behavior is likely intended but not well developed for external command feeding. The question here I suppose is "Is this useful/wanted in Gmoccapy?" Probably not, so Gmoccapy should take some steps to prevent it.
It's easy to say "just don't do it" but fat fingers and touchscreens.....
Please Log in or Create an account to join the conversation.