ESP32 spindle control help

[krupis]

Hey. I have a CNC setup using ESP32 & Raspberry PI. ESP32 is programmed with grblHAL software.

At the moment, I am manually controlling the spindle. The controller that I use: Optidrive ODE-3-220105-1F42-01.

I would like to try an implement some spindle control from my ESP32 device. I do not have much simmilar experience therefore I would like some general advice regarding controlling the spindle using ESP32 microcontroller.

I have read the controller datasheet : https://www.driveswarehouse.com/Assets/Document/ODE3-20M.pdf And also did some additional research regarding controlling methods and from what I found out, the most convenient method to control the spindle would be using 0-10PWM signal (I believe grblHAL implementation is using this method on spindle control as well)

To implement 0-10V pwm I would need some 0-10 pwm module such as: https://www.aliexpress.com/item/32834921874.html

The only issue that most of these modules are using 5V logic so I will not be able to use these modules on ESP32. I would somehow need to convert 3.3V logic to 5V logic or use 0-10V PWM module that works on 3.3V.

Also, from the controller datasheet that I use , I read a lot about 4-20m protocol but I assume it does not have anything to do with 0-10V pwm?

[terjeio]

(I believe grblHAL implementation is using this method on spindle control as well)

It uses PWM, that is why a converter has to be added if the spindle does not support that.

The aliexpress module may be usable as-is, if not by a small modification as there seems to be an optocoupler at the input. My guess would be to reduce R2 from 330 to 150 ohm?

Also, from the controller datasheet that I use , I read a lot about 4-20m protocol but I assume it does not have anything to do with 0-10V pwm?

Yes and no, they are both DC but one is voltage the other is current (industrial current loop). 4-20mA is less suspectible to interference but not widely used for CNC machines?.

[HuubBuis]

You can use a logic converter to convert the 3v3 logic to 5V. There are a lot of cheap modules available. I mean these kind of converters: logic converter The versions that use a FET (for every channel a separate chip) can, depending on the type of FET used, shift 3V3 to 10V and can be connected directly to the Optidrive. Sparkfun uses a BSS138 FET that is suitable for this.

[HuubBuis]

I am not sure what you mean by To implement 0-10V pwm

a 0-10 volt PWM signal or a PWM to 0-10 volt converter. The above option works if a 0-10 volt PWM signal is needed.

[krupis]

Thanks for the comments. I will buy 3.3V to 5V and PWM to Voltage Converter Module 0-10V. I have also noticed in my drivers folder there is a subfolder "spindle" and in there we have a modbus. I think it is not ready for production yet but it could be better than 0-10V pwm control since I would be able to issue other various commands rather than just controlling speed. I assume I would need to modify the code to get the modbus working to get the commands and registers all correct for my particular driver but I will leave that for another day sometime

[karoria]

My suggestion is to use 0-10v analog voltage for rpm control for now, unless you are too good at coding. For Modbus way, each spindle vfd has its own set of modbus instructions (as manufacturer changes), which has to be coded correctly and is a bit lengthy process. For 3.3pwm to 0-10 analog, I suggest using an opamp and set gain to 3. You need a pot for adjusting to precise voltage outputs. Also a capacitor at 3.3pwm side for filtering. This way you will save 2 different circuits.

[phil-barrett]

Yes, skip the converter. Here is the 0-10V circuit from my breakout board. It uses 5V input but is simple to change for 3.3V input - change R28 to 20K. It uses the LM358 dual opamp but only uses 1/2 of it. You could swap in just about any opamp. It uses a 2 stage filter with an aggressive cut-off frequency to filter out f_PWM. The trimmer potentiometer allows fine tuning the output voltage.

[krupis]

Cool. I have now do not have access to 12V but I will be making a custom esp32 pcb for grblHAL and I will include the schematic you have shown here. Thanks a lot

If any of you have used ESP32 for grblHAL, you might be fammiliar with another issue I have. The internal pull up resistors dont seem to work for my buttons. They keep triggering, however adding external pullups seems to fix the problem

[HuubBuis]

3V3 processors have very weak pull up/down resistors, typical 40k.

To improve noise immunity, NC switches do a better job due to the lower impedance and like you said, adding pull up resisters does help.

[krupis]

Thanks. On top of that, Can I ask another questions here regarding the limit switches. I think I have seen somewhere that the default configuration is Normally open . I have added a 10k pull up resistors and pull my signal line to +3.3V . When the button is pressed, it should connect the signal to ground.

However, I am noticing some very strange behaviour. When connecting a limit switch which is wired in Normally open configuration, the homing does not work properly. I have tested with just Z axis and the Z axis just moves 1 step down and then stops returning an error. However, wiring the same limit switch in normally closed position it seems to work fine!

I have tested with multimeter the limit signal and when the limit switch is not pressed, I have 0V, and when it is pressed I get 3.3V. The homing seems to work fine with this configuration. The Z axis travelled up untill it reached the limit switch and then backed off a step and slowly return to the limit.

Can someone clarify me regarding the limit switch? What is the default way to use them in grblHAL and whether it should be activated with HIGH or LOW signal?

I was under the impression that it is active LOW logic for everything including the buttons, limit switches and etc, but as I have explained above, limit switches appear to be working properly when signal HIGH

[phil-barrett]

Grbl and grblHAL use active low for mechanical switch inputs. This is fairly common because of open collector/drain allows "wire ORing" of signals and just about every microcontroller has built in pull up resistors to support that. But it is not uncommon to see active high and some microcontrollers have pull-down resistors to support that as well.

Don't confuse that with using normally open (NO) or normally closed (NC) sensors/switches. You can use either type with active low or high inputs.

grblHAL defaults to NC switches because they are more EMI resistant. It is harder for EMI to force the signal high when current is flowing (NC) than it is for EMI to do so when there there is no current (NO). Grbl classic defaults to NO switches. NC switches need to be wired in series making it a little more complex to wire up than NO switches in parallel.

[terjeio]

@krupis That Invertek drive seems to be a nice one, and the ModBus commands in use is AFAIKT properly documented so I think it should be fairly easy to add a plugin for it.

A problem is that the ESP32 is short of pins, you may consider adding an I2C I/O expander to your design to work around that. There is code to handle a PCA9654E available already, I have made use of that in the _cnc_boosterpackmap.h. Adding EEPROM or FRAM for settings/data storage may also be a good idea.

[krupis]

Understood. Thank you very much. Could you also clarify which part of the setting selects active low or active high for limit switches. For example now they work on active high, what setting I change to put them to active low mode?

I will be writing a plugin for modbus once I get the basic funcionality running which should be very soon

On Thu, 4 Feb 2021, 17:39 phil-barrett, notifications@github.com wrote:

Grbl and grblHAL use active low for mechanical switch inputs. This is fairly common because of open collector/drain allows "wire ORing" of signals. But it is not uncommon to see active high and you can configure many microcontrollers to work that way.

Don't confuse that with using normally open (NO) or normally closed (NC). You can use either type with active low or high inputs.

grblHAL defaults to NC switches because they are more EMI resistant. It is harder for EMI to force the signal high when current is flowing (NC) than it is for EMI to do so when there there is no current (NO). Grbl classic defaults to NO switches. NC switches need to be wired in series making it a little more complex to wire up than NO switches in parallel.

— You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub https://github.com/terjeio/grblHAL/issues/229#issuecomment-773401118, or unsubscribe https://github.com/notifications/unsubscribe-auth/AFJU62SA2HU4W4VR4GDUFTLS5K5THANCNFSM4XALH3XA .

[terjeio]

Settings inherited from Grbl are documented here and grblHAL extensions here.

Test branch grblHAL has recently gotten a $help command that can be used (from a terminal) to list settings info:

E.g. output from $help limits is:

$5: Invert limit pins as axismask
$18: Pullup disable limit pins as axismask
$20: Soft limits enable as boolean
$21: Hard limits enable as bitfield where setting bit 0 enables the rest:
    0 - Enable (1)
    1 - Strict mode (2)
ok

So $5 is what you need to use to change to active low.

$help on its own lists available arguments.

[krupis]

Settings inherited from Grbl are documented here and grblHAL extensions here.

Test branch grblHAL has recently gotten a $help command that can be used (from a terminal) to list settings info:

E.g. output from $help limits is:

$5: Invert limit pins as axismask
$18: Pullup disable limit pins as axismask
$20: Soft limits enable as boolean
$21: Hard limits enable as bitfield where setting bit 0 enables the rest:
    0 - Enable (1)
    1 - Strict mode (2)
ok

So $5 is what you need to use to change to active low.

$help on its own lists available arguments.

Understood. Can you also please clarify me regarding the mechanical push buttons. I have initially thought that the default configuration is active LOW, however, I noticed problems when I have wired the buttons.

I have 2 buttons wired up : Feed hold and start cycle. I have added 10k pullup resistors for both buttons and once they are pressed up, the signal is connected to GND.

In this configuration, the bCNC program constantly thinks that the buttons are being pressed, so it thinks that the logic is active HIGH?

I have changed the $14 (Invert control pins as bitfield) to 6 and $17 (pul up disable control pins as bitfield) to 6 as well. Now my feed hold and cycle start buttons seem to work fine active LOW. But that should not be the case ?

From what I understand, I have made changes to $14 and $17 which changed my mechanical button configuration to active HIGH ( if default is active low) and I have added internal pull down resistors?

But still, I have externall pull ups and button seems to active activate when connected to GND so I cannot get my head arround what wrong is going on here

I also cannot find any information regarding $14 ( Invert control pins as bitfied). in the documentation $14 is documented under a different instruction:

[terjeio]

I have initially thought that the default configuration is active LOW

All inputs are defaulted to active high (normally closed switches).

I also cannot find any information regarding $14

See the wiki.

in the documentation $14 is documented under a different instruction:

Where did you find the referenced documentation? $5 is for inverting limit inputs and is carried over from legacy Grbl, $14 is a grblHAL specific setting.

[krupis]

I have initially thought that the default configuration is active LOW

All inputs are defaulted to active high (normally closed switches).

I also cannot find any information regarding $14

See the wiki.

in the documentation $14 is documented under a different instruction:

Where did you find the referenced documentation? $5 is for inverting limit inputs and is carried over from legacy Grbl, $14 is a grblHAL specific setting.

Thanks for rapid response.

According to the previous post you have made 6 days ago "Grbl and grblHAL use active low for mechanical switch inputs" and now you just said that all inputs are configured for active HIGH.

Can you clarify that for me please as now I am confused.

Although I now understand what my problem is regarding with Feed stop and cycle start buttons. I just use a regular push button which is normally open, and that is why I had to invert the logic.

And thank you for clarifying regarding the $14, I sometimes confuse myself between grbl and grblHAL specific documentation. Sometimes I cannot find all command details in grblHAL documentation therefore I try to find it in grbl docs.

[terjeio]

According to the previous post you have made 6 days ago "Grbl and grblHAL use active low for mechanical switch inputs"

That was by @phil-barrett not me, perhaps it will be better to stick to "normally closed (NC) switches" for describing inputs?

Sometimes I cannot find all command details in grblHAL documentation therefore I try to find it in grbl docs.

Documentation for grblHAL needs more of work, but still I wonder where you found that $14 specification...

[krupis]

Oh yeah you are right it was not you! So I assume he was wrong saying that all the mechanical switches use active LOW?

Yes I should definately stick with NC and dont mix NC and NO in my system cause that just makes everything more complicated.

So now I know for sure that I should: Use NC switches for both limit switches and mechanical push button Default Active HIGH for all inputs

The image that I have sent regarding $14 was taken from: https://github.com/terjeio/grblHAL/blob/master/doc/markdown/settings.md

[terjeio]

So now I know for sure that I should: Use NC switches for both limit switches and mechanical push button Default Active HIGH for all inputs

Yes, that is IMO best practice when it is possible to choose.

Ok, so the bad description is on me - it has been a long time since I wrote that. More documentation to be updated...

[krupis]

No problem. Thank you very much for all the help. I have been receiving amazing help so far

[phil-barrett]

There is a terminology confusion, I tried to be clear but obviously wasn't. The input pins are pulled high (to VCC, typically 3.3V, 5V in Arduino) by default - that is their state when nothing is attached. NO and NC are interpretations of the input pin state. grblHAL defaults to NC switches/sensors which will pull the input pin low during "Normal". 8-bit grbl only supports NO input switches (cycle start, feed hold, ...). A very welcome addition to grblHAL is the ability to set them as NC or NO. Note that limit switches in grbl and grblHAL can be set up as NO or NC via $5.

This is why grblHAL on a BOB with no switches attached will initially come up in an alarm state. A frequent point of confusion and far away the number one support question.

[krupis]

I see now. Thanks for clarifying :) are you using grbl yourself?

Is it a good option for emergency push button to use one of the intended GPIO pins for( I assume it is just going to perform a "reset" on ESP32 simmilarly as if I short the reset pins.

However, in that configuration I have no control of stepper motors and they will still have power so I dont know if that is safe for emergency stop. One of the better options for emergency stop button I see is to perform a reset on ESP32 as well as shutting power to the motor drivers

Can you share your setup for emergency stop if you have one>?

[phil-barrett]

I see now. Thanks for clarifying :) are you using grbl yourself?

every day. I develop breakout boards for grblHAL and support my customers (and others). Some days I even get a chance to go to the shop and do real CNC work.

Here is a blog I did on the estop issue. I see it as a set of layers. Note that this is somewhat specific to grblHAL running on a Teensy 4.1 - EStop does not cause a processor reset. Otherwise, it is generally applicable.

[krupis]

Thanks I have read a blog and it was helpfull. At the moment, I only have feed hold button, but now I want to implement something that was mentioned as a 2nd option.

Raising an alarm without causing the processor to reset seems like a good idea. Since I use ESP32, I would assume that there should be a software implementation for that already and a dedicated gpio pin but under the control pins, I can only find:

I assume thats none of them what I am looking for.

[krupis]

Since I have 2 NC channels on my emergency stop button, I guess I could wire it simmilarly to:

one of the channels would reset my ESP32, and the other would disconnect 24V supply for the motor drivers. I think that would be the safest way right?

[terjeio]

Raising an alarm without causing the processor to reset seems like a good idea

This can be done by using the RESET_PIN. This is not the same as the processor reset input, it will stop execution of code and reset grblHAL only. grblHAL also has an e-stop function that is a little less harsh than the inherited reset, I have made that the default option for some drivers by simply setting a different flag in the driver code when the reset input is asserted:

https://github.com/terjeio/grblHAL/blob/e41177bdec206b08d582fa1c657eacf7e963925d/drivers/IMXRT1062/grblHAL_Teensy4/src/driver.c#L1056-L1060

Using a relay to cut motor power (to both steppers and spindle) in addition to terminate a running program is definitely a safer way to handle a e-stop. If the spindle motor driver supports it e-stop should also engage a/the braking resistor.

[phil-barrett]

Good info there. On the Spindle/VFD, I have seen a number of discussions about the danger of cutting power before spindle has spun down. As it is spinning down, the spindle generates back-EMF and can damage the VFD electronics if external power is cut. I believe a braking resistor helps with this but not 100%. This thread on CNC Zone is one example.

[HuubBuis]

If a VFD connected to a running spindle, can be damaged just by disconnecting the VFD power supply (or blow a fuse), it is a bad designed VFD. This damage should never happen for an ordinary VFD.

A breaking resistor could reduce more damage by slowing down de spindle as fast a possible.

[phil-barrett]

I will not argue with "bad design" but that is the world we live in. The people posting on that CNCZone thread are not lightweights and have demonstrated expertise.

The resistor also provides a path to ground other than through the IGBTs.