Why the need to manually clear alarms after an abort?

[ghost]

Why it is required to press abort twice in order to fully complete an abort and clear the alarm? This seems to be the case with both Smoothie and GRBL.

Is this double process really necessary or can it be simplified to one click?

[cprezzi]

Because Smoothieware goes to alarm state if there are still commands in the planer quere when halt is executed.

[cprezzi]

Smoothie does this allways, Grbl only when the abort was in between a command execution.

[tbfleming]

grbl issues this which explains why:

ALARM: 3 - Reset while in motion. Grbl cannot guarantee position. Lost steps are likely. Re-homing is highly recommended.

Abort in grbl is aggressive; it ignores the acceleration limits.

[ghost]

Perhaps a machine setting which asks: "Actions to take on Abort" Smoothie users would choose to clear the alarm. GRBL users would choose to re-home their machine, or whatever is appropriate.

[tbfleming]

Why? We have a button to clear it. We just need to make it more clear when there is an alarm, which the drawable UI will support.

[ghost]

It is a suggestion from the feedback we have been getting from a number of our users in an attempt to make Laserweb less technical and more friendly. Most users don't care about alarms etc. They want to abort, or whatever, and continue on with their work. Needing to press this button twice is silly to them.

Like I said, it's just a suggestion based un our user-base feedback.

[cprezzi]

It wouldn't be appropriate to auto-clear alarms of the controller. The controller raises the alarm to tell the user he has to check the machine and decide what he needs to do.

[tbfleming]

I'm now split on this; I wasn't before. Auto-clearing an alarm is risky. Auto homing after an alarm is a disaster waiting to happen; a stop button should stop, not cause motion. But, it does make since that new users would believe it's silly to hit a button twice.

[tbfleming]

Using the same button for stop and clear alarm is a space-saving measure. Maybe the answer is to keep them separate.

[tbfleming]

grbl: it sends a feed-hold (!) followed by a soft-reset (ctrl-x). What if it waits for motion to stop before sending the ctrl-x? It could look for Hold:0 in response to the status query (?).

[ghost]

In LW3 we popped up a Modal on Alarm that explained it to the user...

[cprezzi]

@tbfleming The abort button should NOT wait until current motion is finished or decellerated, it should stop as quick as possible. It's an abort and not a stop button. It's a software version of an immergency stop. That's why I use ctrl-x.

If someone just want's to stop the queue, he can press pause. Then he has time to decide, if he wants to abort the job, or resume. This way no alarm is raised (at least with grbl).

[cprezzi]

@openhardwarecoza I didn't like that popup. Nowbody understud the explanation and knew what to click.

I don't think there should be anything changed. It works. Just Klick that f..ing button! ;)

[FabCreator]

Pause and abort are 2 functions which are not interchangeable in my opinion

From a technical stand point the current system is correct, The abort is a soft e stop, being such it should follow the same standard of an E stop When a project is aborted the machine must halt instantly, It then needs to be in a state in which it cannot continue or move until manually reset Abort moving the controller into an alarm state and then having to click clear clear alarm achieve this function perfectly.

The issue i think we are having is the pause button in smoothie does not pause when instantly, in some cases the job will finish before it pauses. therefore we have users using abort as the pause, this is incorrect. I would suggested trying to 'fix' the pause so it will stop without loosening steps / missing lasered areas and within a few seconds.

[tbfleming]

We'd need someone to volunteer to work on Smoothie. They could rework its protocol to not need 2 com ports while they're at it.

[ghost]

Thanks for everyone's input to this question.

It is clear now that the abort is quite an important function akin to an emergency stop. I believe it is currently being used incorrectly by lots of users who treat it as a 'stop' button.

Presently, you can run, pause and un-pause a job. There is no way to 'stop' a job without hitting the abort button.

Users who understand their machines will be aware that they need to first 'pause' their job and once the machine has stopped moving, they can press abort to safely stop the job without adverse effects. They understand alarms , e-stops and states their machines are in. But i believe Laserweb should be easy to use for the average person, and not only the tech-savvy CNC crowd.

I can already hear people saying 'well it's not hard to press a button twice.... or that's that way it's done in CNC world' but please appreciated that there are users who don't understand all these things. If we have to actually spend time explaining a simple process or writing an explanatory tutorial on how to stop a job, then I'm sure you can understand there is something flawed with the methodology.

I appreciate the opportunity to share our thoughts and our extensive user base feedback/experience with this dev team.

[cprezzi]

I know you are trying to optimize your laser-engraver for the mass market, but I belief people that are not willing to develop a basic understanding of this technology should not use a machine like a laser cutter or cnc mill. The risks for themselfs and their surroundings are just too high.

[ghost]

While i do agree with @cprezzi i also feel like we can help with that... where is a newb supposed to learn how these "complicated" systems work? We were all there at one time? Thats where i felt the role of helpful explanatory popups may be helpful (even if my lw3 implementation was still too high level)

[ghost]

Also, thanks @domenic-d 's - as you say, you are just conveying " extensive user base feedback/experience" - that is a fact, that is a large portion of users we dont hear directly from.

[tbfleming]

There's a risk with explanary popups that they'll be like:

• Microsoft's explanary popups
• npm's error messages

They tend to bury the 3-or-4 word (sometimes letter) explanation experienced users need with tons of worthless stuff that help nobody.

[ghost]

I think we have reached the end of this discussion and no change to the current setup has had any traction. Closing for now.