On 6/5/25 2:57 PM, andy pugh wrote:
The user would expect that the user interface tells the user of the
error in the command entered and simply refuses to execute a faulty
command. The state of the machine should not be altered because, from
the user's perspective, nothing was done or executed.
I agree, but you will find that if you are in MDI mode and;
M6 S1000
M8
then the spindle starts and coolant turns on
Then
G81 Z-10 (missing R word)
the coolant and spindle turn off.
This is just an annoyance that I have been putting up with, but at
least the change here is obvious.
This is not only an annoyance. It is bad interaction design.
As you say, you have been "putting up with" the problem. It is IMNSHO
obvious that this MDI behavior is utterly wrong and should be altered.
I think it hints that faulty MDI does result in an abort, so altering
the scope of abort requires consideration of the MDI case.
My guess is that any MDI command is fed into the interpreter as if it
was a (single line) program. This is obviously problematic.
(I would be easily persuaded that MDI faulty inputs should just do
nothing at all)
That is also what you expect. Therefore, it should behave as such.
Fixing the real problem here may require some lateral thinking. If my
guess is right as outlined above, then it may be a more difficult
alteration to implement. It will depend on the separation of layers and
whether you can alter the interpreter's operation from the "outside".
You need to be able to return the error on a bad command without going
through auto procedures and recovery.
--
Greetings Bertho
(disclaimers are disclaimed)
_______________________________________________
Emc-developers mailing list
Emc-developers@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/emc-developers
