We allow 'stacking' of MDI commands - is it OK ???
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.
Please Log in or Create an account to join the conversation.
Iforce2d made a gcode server aimed at having commands pumped into LinuxCNC via OpenPnP, similar to how 3D printers work. Linuxcncrsh was the basis for it but that seems to be a forgotten interface these days. If I had to guess I assume the "stacking" was an attempt to accomodate drip feeding via linuxcncrsh but since people tend to ignore that interface exists some of the functions may not regard it.
Personally I think the MDI stacking should be expanded to be more consistent in LinuxCNC itself. Stacking might not be preferable in common UI's but the UI should handle feeding the commands one by one if that's the case.
Please Log in or Create an account to join the conversation.
I agree with you that feeding the commands one by one should be handled by the GUI.
Please Log in or Create an account to join the conversation.
forum.linuxcnc.org/38-general-linuxcnc-q...not-possible-via-nml
And it exists here with the documentation
github.com/iforce2d/linuxcnc-gcode-server
I built a PnP and I was working on getting it all set up with this and got sidetracked. OpenPnP is a PIA, I did get Linuxcnc and the server all set up with some movement in OpenPnP but its a ways off from being functional.
Please Log in or Create an account to join the conversation.
- snowgoer540
-
- Offline
- Moderator
-
- Posts: 2362
- Thank you received: 763
@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
![:) :)](/media/kunena/emoticons/smile.png)
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.
- snowgoer540
-
- Offline
- Moderator
-
- Posts: 2362
- Thank you received: 763
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 you're speaking specifically to Gmoccapy, this is the right place.. I was just making sure because of the open issue referenced in the other thread.
The MDI implementation in Gmoccapy is specific to Gmoccapy.
If I were a rentier and I didn't have to go to work, I would study programming at university.
Work sure does get in the way of a lot of fun things
![:( :(](/media/kunena/emoticons/sad.png)
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)
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.
- snowgoer540
-
- Offline
- Moderator
-
- Posts: 2362
- Thank you received: 763
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.
I know a lot of people use Gmoccapy. I'd be hesitant to change long-standing behavior/functionality that I'm not sure I've ever seen anyone else describe as a problem.
It's easy to say "just don't do it" but fat fingers and touchscreens.....
I'm not understanding how removing a GUI's ability to stack MDI commands will prevent user input error caused by fat fingers and touchscreens. That can/will happen entering one line at a time.
Please Log in or Create an account to join the conversation.
It's LinuxCNC behavior because it's useful for plenty of things not related to a typical UI
Please Log in or Create an account to join the conversation.
github.com/LinuxCNC/linuxcnc/issues/2956
Please Log in or Create an account to join the conversation.