We allow 'stacking' of MDI commands - is it OK ???
I discussed here the possibilities of solving problems with race conditions in MDI commands.
C-morley brought this to my attention:
"keep in mind we allow 'stacking' of MDI commands - you can type one in and run it and type in another (while the first is still running) and it will be run after the first."
My opinion is that it is wrong. I think it should not be allowed to accept another command until the previous one is executed.
But that's just my OPINION. This is not a truth.
It is mandatory for the operation of some machines in some modes, but I don't want to start a discussion about standards here. I'm interested in your opinion on this situation. Do you think this should change?
Attachments:
Please Log in or Create an account to join the conversation.
On the other hand it is powerful and may improve your workflow...
Please Log in or Create an account to join the conversation.
Please Log in or Create an account to join the conversation.
I'm used to other controllers where 'stacking' isn't possible.I'm interested in your opinion on this situation.
My Fanuc and other controller (Haas, Fadal, Siemens) experience is that MDI is more like building a program than a 'quickie' command as in LCNC.
Four ways to get a machine to do something (besides jogging)
- Create a new program, give it a file name, then run it with a 'cycle-start' command
- Load an existing file then start it with a cycle-start command.
- Build a program with some form of 'conversational' feature, then start it with cycle-start.
- Enter MDI mode and create an MDI program of any length and start it with a cycle-start command
- Once finished, the MDI program stays loaded until you load a different program or start a new one
- Once gone, it's gone.
- While any of the above operations are in-progress you cannot activate an additional or new program or MDI entry.
- The only way to initiate machine movement (besides jogging) is with the cycle-start button. There is only ONE button that will start automated machine movement.
My opinion/preference would be that LCNC's MDI behave more like typical commercial controllers , to include the 'cycle-start to initiate' behavior.
Note that the last comment touches on my recent moaning about keyboard and on-screen jogging & controls.
Please Log in or Create an account to join the conversation.
- snowgoer540
-
- Offline
- Moderator
-
- Posts: 2362
- Thank you received: 763
- I edited your post to point the URL to the actual topic you referred to instead of the index so people don't get confused.
- You posted this in the Gmoccapy index, but issue #2586 states that you feel "This is NOT problem of Gmoccapy.". Would you like me to move this to a general discussion Index?
To address your post:
I am having a hard time following the specific reason you feel stacking MDI commands is "wrong", or more importantly why it's a problem? MDI stands for Manual Data Input. It's like choose your own adventure CNC machining. If you don't want it to stack commands, don't enter several at a time.
Perhaps I'm confused though. One such source of confusion from the other thread is where you pointed out that
c.mdi("G1 X10 Y20 Z30 F200")
and
c.mdi("G1 X10 F200")
c.wait_complete()
c.mdi("G1 Y20")
c.wait_complete()
c.mdi("G1 Z30")
give different paths to the same point as if it's a problem. The first is a one line 3 axis move. The other is three lines each containing a one axis move. That's standard behavior.
Moving on past GUI implementation of MDI commands, QtPlasmaC (as one example of probably many) makes use of the ability to stack MDI commands programmatically (via the python interface) for features like framing.
tldr; I certainly prefer this behavior, it's not only OK but necessary.
Please Log in or Create an account to join the conversation.
Thank you. You explanation helps - 'stacking' is, in fact, similar to the behavior I described for other controllers.
I think the difference is that other controllers show all the lines and are executed as a single (but multi-line) program.
Whereas LCNC's MDI does something similar - you just don't see the queue of lines that are in-progress or are yet to be completed in the typical GUI display.
Please Log in or Create an account to join the conversation.
- snowgoer540
-
- Offline
- Moderator
-
- Posts: 2362
- Thank you received: 763
From section 1.3.2.1 (of Version 3):
In the EMC system, the Interpreter is used both to interpret NC programs from files and to interpret individual commands entered using the manual data input (MDI) capability of the control system. When running an NC program from a file, the driver tells the Interpreter when to read another line of code from the program file. When using MDI input, the driver sends the Interpreter a line of code to read that the controller has received from its user interface. Either way, the Interpreter reads the line and tells the driver if the line was readable. If so, the driver tells the Interpreter to execute the line.
It's also notes a distinction between keyboard (MDI) and file (batch) modes:
The SAI has two input modes: keyboard (MDI) mode and file (batch) mode. In the MDI mode, the user types lines of RS274/NGC code at the keyboard. In the batch mode, the Interpreter reads lines of code from a file.
That being said, at the end of the day, these are ultimately choices made by those who created the existing GUIs. There's no reason you couldn't design a GUI that doesn't allow MDI command stacking, or one that behaves like Fanuc and uses the MDI to create a g-code program line by line and then only allow running it via Cycle Start (although for this particular one, I would argue for the use of a simple text editor instead). Or even one that doesn't support jogging via the keyboard.
It's also open source, so one could also fork the project and tweak the existing GUIs to your liking.
![:) :)](/media/kunena/emoticons/smile.png)
Please Log in or Create an account to join the conversation.
There's no reason...
Um... Perhaps a more accurate statement would be "There's no external impediment..." as my lack of competence is a very big reason.
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.Would you like me to move this to a general discussion Index?
I know, that it is not problem. I tried explain how wait_complete() works. I wanted to explain my previous question in a way that everyone can understand. I guess it didn't workPerhaps I'm confused though. One such source of confusion from the other thread is where you pointed out thatc.mdi("G1 X10 Y20 Z30 F200")
andc.mdi("G1 X10 F200")
c.wait_complete()
c.mdi("G1 Y20")
c.wait_complete()
c.mdi("G1 Z30")
give different paths to the same point as if it's a problem. The first is a one line 3 axis move. The other is three lines each containing a one axis move. That's standard behavior.
![:-( :-(](/media/kunena/emoticons/sad.png)
Otherwise, I'm glad you wrote your opinion about stacking.
Please Log in or Create an account to join the conversation.
On Heidenhain controllers, the MDI programm/histroy is a normel programm that you can edit and copy and so on, but in MDI mode it is only possible to run one line.
Please Log in or Create an account to join the conversation.