[Grbl_Esp32 Issue#439] Spindle Enable Behavior

未分类 bolang 4个月前 (10-14) 41次浏览

Issue #439 | 状态: 进行中 | 作者: reynolds087 | 创建时间: 2020-06-16

标签: bug


What version of the firmware are you using?

How do I check? I cloned the master branch about a month ago.

Is the problem repeatable?

I believe so, unless it’s a problem with my system.

Under what conditions does the bug occur?

When I turn on the ESP32, the spindle enable pin is active meaning the contacts of my relay are connected. In Candle, I turn the spindle on (no change to the enable pin, but the spindle begins rotating), and then when I turn it off, the spindle enable pin now turns off, relay disconnects the contacts and the motor stops rotating). I am debugging my mosfet driver, and sometimes the driver activates when it shouldn’t, so relay that connects the motor leads to the driver is controlled by the spindle enable pin with the intention of using it as a safety feature, but it doesn’t work that way because the enable pin is active at startup and allows the motor to engage when it shouldn’t.


评论 (8)

#1 – bdring 于 2020-06-18

What controller are you using? Can you show the schematic?


#2 – reynolds087 于 2020-06-23

The controller I am using is something I built, but the only part I am concerned about is the pin for spindle enable, which defaults to active at startup of the ESP32.


#3 – bdring 于 2020-06-23

We cannot offer good help if we cannot see the schematic. Please post it. Even if it is just a hand drawn portion of a schematic only showing the complete spindle circuit.


#4 – reynolds087 于 2020-06-24

I get what you’re saying, but the issue is completely separate from the spindle circuit. Think of it this way, a relay is attached to the spindle enable pin, with no spindle connected at all.

https://www.amazon.com/Youngneer-Raspberry-Arduino-Opto-Isolate-Microcontrollers/dp/B07ZM84BVX/ref=sr13?dchild=1&keywords=3.3+volt+relay&qid=1593035837&sr=8-3

This is the relay board that’s connected to the ESP32, and even with the spindle disconnected, it does the same thing. You can literally just test the pin, when you start the ESP32 it’s enabled before you send the command to turn the spindle on. Then after you turn the spindle on and off again, the pin will be disabled.


#5 – sjonholle 于 2020-07-31

The same happened here. At startup the pin is enabled and shut off is done by a M3 and then M5. Spindleenable is connected at GPIO0 and Spindleoutput is GPIO26. What helped me (finally) was compile the latest version (25-07-2020), use not my own machine-file but changed the pins in the file 3axis_v4.h and included this file. Hope this helps reynolds087 (i guess the problem lies in the changing names of the pins)


#6 – AlphaCircuit 于 2021-02-10

Ok I was having similar problems the solutions is place a 1K pull down resistor on your PWM output(ESP32 PIN) (to ground) …on power up I have noticed about 1-2 seconds were the RTOS booting and it handing over control to GRBL application and no actual control of the PWM Spindle pin ie its floating and will allow mosfets to act up, the pull down corrects this behavior by not allowing the pin to float high at the beginning of a reset or powerup.
Note you may also need to do this on the Enable pin(ESP32 pin) as well, as there is a definite time were the RTOS and the hand over to the App leaves it in a state it can float, so a pulldown resistor takes care of the unknown states.


#7 – bdring 于 2021-02-10

The @AlphaCircuit suggest is very good.

Be aware that some pins will actually change during bootup and can override a resistor. We have tried to put everything we have learned about ESP32 pins here.

https://github.com/bdring/Grbl_Esp32/wiki/Setting-Up-the-I-O-Pins


#8 – AlphaCircuit 于 2021-02-11

Sorry I will clarify on the Enable pin(ESP32 pin) I meant to say “Spindle Enable” pin on the ESP not the actual EN pin (aka reset for ESP), Note the Pull down has worked for me using pins GPIO 17 for the Spindle PWM,

Agree with bdring be careful with GPIO 0,2,12 (the boot strapping pins) as the results may not be what you think, agree that users need to be careful on what pins they use this solution on but does get around the RTOS letting a pin float into an unknown state .
But hopefully other users now have a bit of clarity to why a pin(s) is doing strange stuff in the first few seconds as the RTOS is at fault not the (GRBL)application The RTOS is leaving pins in a input state and it takes a 1-2 seconds to hand over to the application… so you get the situation none of the output pins are configured and left to float and a hardware fix is the only real easy fix.
Definitely NOT A GRBL_ESP32 fault… GRBL behaves correctly in this situation…


原始Issue: https://github.com/bdring/Grbl_Esp32/issues/439

喜欢 (0)