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.
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.
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.
I have a lot of ideas in my head to improve LCNC, unfortunately I don't have the computer skills to do it. If I were a rentier and I didn't have to go to work, I would study programming at university. So that I can realize my ideas in Pull Requests. My posts often have a higher logic that I can't easily explain.Otherwise, I'm glad you wrote your opinion about stacking.
Please Log in or Create an account to join the conversation.
