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

More
03 Jan 2024 20:31 - 03 Jan 2024 20:36 #289694 by spumco
@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.

 
Last edit: 03 Jan 2024 20:36 by spumco.
The following user(s) said Thank You: zz912

Please Log in or Create an account to join the conversation.

More
04 Jan 2024 01:18 - 04 Jan 2024 01:21 #289709 by blazini36
Removing MDI stacking from Gmoccapy might be wise but there's a reason it's allowed in LinuxCNC. Unless something's changed the only way to push external Gcode into LinuxCNC is MDI. You can sometimes incorperate blending with some lookahead when the commands come in stacked but it seems somewhat arbitrary.

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.
Last edit: 04 Jan 2024 01:21 by blazini36.
The following user(s) said Thank You: snowgoer540, spumco

Please Log in or Create an account to join the conversation.

More
04 Jan 2024 07:01 #289743 by zz912
Is there any documentation for OpenPnP and Linuxcncrsh?

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.

More
04 Jan 2024 09:43 #289747 by blazini36
Not via linuxcncrsh but a server based on it with some extended functions. It was discussed here:
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.

More
04 Jan 2024 11:06 #289757 by snowgoer540

@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.
The following user(s) said Thank You: spumco

Please Log in or Create an account to join the conversation.

More
04 Jan 2024 11:12 #289759 by snowgoer540

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 :(

Please Log in or Create an account to join the conversation.

More
04 Jan 2024 11:35 #289761 by blazini36

@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.
 

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.

More
04 Jan 2024 11:43 - 04 Jan 2024 11:44 #289765 by snowgoer540

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.
Last edit: 04 Jan 2024 11:44 by snowgoer540.

Please Log in or Create an account to join the conversation.

More
04 Jan 2024 12:01 #289767 by blazini36
I seriously doubt there's any use to stacking commands in an MDI widget. Rather than saying "I know people who use Gmoccapy", it'd be alot more useful if anyone said "Yeah, I stack widgets in MDI because......"

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.

More
01 Apr 2024 12:49 #297368 by zz912

Please Log in or Create an account to join the conversation.

Moderators: newbynobiHansU
Time to create page: 0.146 seconds
Powered by Kunena Forum