Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

E-stop/alarm issue #51

Closed
LaurentLM opened this issue Apr 21, 2024 · 5 comments
Closed

E-stop/alarm issue #51

LaurentLM opened this issue Apr 21, 2024 · 5 comments

Comments

@LaurentLM
Copy link

LaurentLM commented Apr 21, 2024

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
Copy link
Contributor

terjeio commented Apr 23, 2024

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

@LaurentLM
Copy link
Author

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.

terjeio added a commit that referenced this issue Apr 25, 2024
@LaurentLM
Copy link
Author

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:

STM32F1xx/Src/driver.c

Lines 2094 to 2095 in 0903727

if(input->mode.irq_mode == IRQ_Mode_Change ||
DIGITAL_IN(input->port, input->pin) == (input->mode.irq_mode == IRQ_Mode_Falling ? 0 : 1) || true) {

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
Copy link
Contributor

terjeio commented May 6, 2024

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
Copy link
Author

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

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants