Ahh your talking only of a syntax error.
Is it not possible to copy and paste multiple commands in some/all screens?
Sent from my Galaxy
-------- Original message --------
From: Bertho Stultiens <l...@vagrearg.org>
Date: 2025-06-06 11:10 a.m. (GMT-08:00)
To: emc-developers@lists.sourceforge.net
Subject: Re: [Emc-developers] Proposal: Change default behavior on abort to 'M2'
On 6/6/25 7:00 PM, Chris Morley wrote:
> Uses enters three commands before first one finishes. First command
> can't finish for some reason. The other commands are already entered
> (stacked) They should not run.> In other words, If there is an error in MDI,
> the stack of commands
> should be flushed and an error posted. This seems reasonable.
The scenario you describe would be handled the same as today because, as
I'm told, you can queue commands in the MDI today:
1) enter command #1 --> long operation starts
2) enter command #2 --> no error on entry
(operation #1 still running)
3) enter command #3 --> no error on entry
(operation #1 still running)
4) operation #1 produces a machine error --> Operational error handler
is invoked
(command #2 and #3 in queue should be flushed)
If the queue is not flushed today, then it should be.
But, what is the current behaviour? Please note that this scenario is
/distinct/ from what we've been discussing previously because your
scenario is _not_ an MDI entry error.
Lets assume operation #1 causes a stall. What happens then? Probably
some kind of machine abort. How that abort is triggered and invoked will
set the stage for what exactly happens. The front-end should be able to
"see" what state the machine ends up in and act accordingly. Again, what
happens today?
> As for resetting everything, ya I agree probably shouldn't.
> I guess it might depend on the actual error.
If the MDI command *entry* fails, then it should not reset anything,
just do nothing.
If the MDI command fails to *execute* that is a different story and
resetting may be a dire consequence of the error (handler) to get back
to a known state.
--
Greetings Bertho
(disclaimers are disclaimed)
_______________________________________________
Emc-developers mailing list
Emc-developers@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/emc-developers
_______________________________________________
Emc-developers mailing list
Emc-developers@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/emc-developers
