It all depends on what the user expects to happen. Or, said in another way, what would be the logical progress of actions and consequences when an operation is performed at it succeeds or fails.
There are distinct differences in actions in interactive mode (MDI) or automatic mode (run g-code program).
G55 (set coordinate system) G81 X10 Y10 Z-3 F100 (drill a hole, but forgetting the R retract value) (clear error, try again) G81 X10 Y10 Z-3 F100 R1 (this time the line is accepted, but are we now no-longer in G55?)
When performed in interactive mode, then it is an error to alter the state of the machine when an error occurs interpreting a command.
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.
If the machine executes any command (in the background) as a response to a faulty MDI input, then you are altering the machine's state, which is not expected.
The real problem will be a faulty command that /can/ be executed but fails while it is executing. The user will probably abort the operation is one or another way. What then happens to the machine's state is a matter for debate. It would depend on what happened and how you terminate(d). However, altering too many settings may be, again, not what the user expects. Here probably should consider the difference between "abort operation", "stop operation" and "cancel operation".
From a user's perspective, you would like to back-track until you get a machine state that is acceptable and in line with what the user did up to the problem. What you do not want is always to reset the machine to some "default" state, dropping all/many settings when in interactive mode. A good thought here is "Users expect something like a do/undo stack.". (Unfortunately, we cannot un-drill that hole)
-- Greetings Bertho (disclaimers are disclaimed) _______________________________________________ Emc-developers mailing list Emc-developers@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/emc-developers
