search

grblHAL / STM32F1xx

grblHAL driver for ST STM32F1xx (Redpill, Bluepill)
Other
40 stars 27 forks source link

E-stop/alarm issue #51

Closed LaurentLM closed 6 months ago

LaurentLM commented 7 months ago

Hello,

I am using a reprogrammed Mach3 BOB which works great for my mini mill.

The only issue I found is that when the e-stop is active, I am still able to jog the machine. The e-stop is detected by grblHAL and reported by ioSender as a red square above the E or the R letter, depending on configuration. The controller does not seem to enter alarm state.

I tried many build configurations with ESTOP_ENABLE set and unset, building with the web interface, PlatformIO and STCube. The issue happens in all cases (e-stop becomes reset when the flag is set to 0, but still no alarm state and I am able to jog the machine).

I also have a Teensy board and the problem does not happen there, despite very similar flag settings/configurations.

terjeio commented 7 months ago

I'll look into this later - I have a busy weeh ahead.

LaurentLM commented 7 months ago

Thanks Terje - no rush.

Out of curiosity, I tried a few other things on my side: Reverting to a commit from February 2023 and the issue still happens. When a program is running, e-stop triggers Alarm 3 and stops the program. When homing, e-stop triggers Alarm 6, as expected.

Let me know if there is anything else I can do to help troubleshooting.

LaurentLM commented 6 months ago

E-stop now works as expected and triggers alarm. Thanks for looking into this!

I did look at the fix and, as I understand it, the if statement below is always true: https://github.com/grblHAL/STM32F1xx/blob/090372792299b64bf2b73415a11a42483f30f6ff/Src/driver.c#L2094-L2095

Not sure this is related, but I also get an error when probing (same as issue 499. The probe now triggers Alarm 4 (and stops moving) just after the first contact. Looking at the code, I cannot figure out why the changes impacted the probe.

terjeio commented 6 months ago

I did look at the fix and, as I understand it, the if statement below is always true:

My bad, I added the always true when debugging - will fix in the next commit.

The probe now triggers Alarm 4 (and stops moving) just after the first contact.

The retract (latch) distance is too short?

LaurentLM commented 6 months ago

Thanks a lot, this is brilliant. Everything works fine now.