Home button isn't active in alarm state

[calabr]

After hard reset GRBL indicate alarm and waitig for home sequence, if enabled. Home sequence can be started in any time, bur GUI Home button isn't active in alarm state and confusing users. Also bright red Reset button looks rezer like alarm sign, which should be hendeled before any next operation.

[terjeio]

Sender version please? You may want to try the latest edge version.

Are you running grbHAL on your controller, if so which build date? I have made a few changes lately to improve user feedback and make startup more robust. These are available in the test branch. If for another controller then it is possible that some changes has to be made, I have to admit that I do not spend much testing with legacy grbl.

Also bright red Reset button looks rezer like alarm sign, which should be hendeled before any next operation.

Not sure what you mean by this. You want another color? I have chosen red because it works a bit like an E-Stop button, and is the same color as the Mach3 namesake.

[calabr]

IO sender Beta-8

; Grbl ; 1.1h.20190825 ; [OPT:V,15,128]

Just after progrem started. Home button disabled, but $H from the MDI works normally and Home become enabled after Unlock.

As you can see, ALARM indicator and Unlock button looks very similar

• My suggestion change the button design to only red frame, or red text to visually separate them. also playing with houming I found strange behavior - after error during houming "Alarm 9" blink on state indicator for a moment and then sender reset GRBL and clean alarm number. With different types of alarm it seems no auto-reset.

I found also some issues with jogging etc. What is your prefer - create separate issue for every new, or add all to the single thread?

[terjeio]

Home button disabled, but $H from the MDI works normally and Home become enabled after Unlock.

I have changed the behaviour for legacy Grbl to enable the Home button on startup. This may not always work though as it is impossible to find out if homing is actually enabled in all circumstances. And Grbl suggests $H to unlock even if homing is not enabled... I have uploaded a new edge version with this and other changes for you to test.

As you can see, ALARM indicator and Unlock button looks very similar

I am sorry, they do not look similar to me. Changing the button style to put a red frame around them would be IMO odd. So I'll leave it as is.

playing with houming I found strange behavior - after error during houming "Alarm 9" blink on state indicator for a moment and then sender reset GRBL and clean alarm number.

This is another legacy Grbl oddity - at least my Mega version resets itself on alarm 9 and then the following status reports does not indicate which alarm is active. I have added a workaround that stores that last alarm number and adds that as long as alarm state is reported. Note that legacy Grbl controllers should be reset on connect, most by toggling DTR, some by toggling RTS. Many grblHAL controllers does not support reset on connect so the default is No action.

I found also some issues with jogging etc. What is your prefer - create separate issue for every new, or add all to the single thread?

Separate issues is often the best as otherwise they may become hard to follow.

[calabr]

I have changed the behaviour for legacy Grbl to enable the Home button on startup.

Thanks, now it's works from the start. Beta-8.8

This is another legacy Grbl oddity - at least my Mega version resets itself on alarm 9 and then the following status reports does not indicate which alarm is active.

My Mega328 version also resets on this alarm.

I have added a workaround that stores that last alarm number and adds that as long as alarm state is reported.

It's create another issue - ALARM state cannot be differenciated from Locked state. After reset nothing changed on the screen and looks like reset not issued. It's probable better store last alarm, error and last command before it in the pop-up window or status bas report.

Note that legacy Grbl controllers should be reset on connect, most by toggling DTR, some by toggling RTS. Many grblHAL controllers does not support reset on connect so the default is No action.

I tryed both - with and without DTR - all works the same for my board

[terjeio]

It's create another issue - ALARM state cannot be differenciated from Locked state. After reset nothing changed on the screen and looks like reset not issued.

Handling messages from the controller and presenting them in the status bar is problematic. Now and then I try to improve this but I am not yet happy with how it works. I may change when messages are sent in grblHAL to make this easier. A part of this is deciding on when a message should be removed from the status bar. IMO the controller should send an empty message on the relevant state changes...

If unsure use the console to see what has been sent.

On a reset then the message "Waiting for the controller (portparams)..." is briefly shown in the status bar. Note that some UI elements are not updated on a reset (coolant, spindle status) due to the Grbl bug mentioned in #86. Again this is fixed in grblHAL.

[calabr]

According to current situation with messages, I propose to revert back Betta 8 behaviour and add additional popup window, for example on the click to status indicator or behind it, with short event log, for example Time, event, description (helpful for alarms and errors) For 2-3 latest events. Only events, which changing state indication. Looking console can be confusing for some users, especially traffic - saving communication shortening in GRBL