ESP32 Buffering commands (loose communication) when spindle turned ON

[krupis]

The Spindle driver I use: https://inverterdrive.com/group/AC-Inverter-Drives-230V/Invertek-Optidrive-E3-2-2kW-1ph-3ph-IP20/ For the spindle , we use shielded cables.

I can move the motors freely when the spindle is not working, after the spindle is turned ON, the motors will respond to few commands when moving , and then stop responding to any commands at all. I opened a terminal and I can see that the commands are buffered:

We have seperated Spindle driver from the rest of the components and it is now sitting below the CNC machine in the cabinet. The rest of the components (Stepper drivers, ESP32, and Raspberry PI is sitting in one plastic box on the side of the CNC machine.

Did anyone face this issue with the spindle? Quick google search suggested that this is a well known problem with the spindle. What are the best ways to fix this problem?

It is worth mentioning that the ESP32 is being powered through the same USB cable that is used to communicate with Raspberry PI. Is that a common practise to use grblHAL in that way (without using an external power supply for ESP32)

Things I am considering at the moment

1. Replace the USB cable that connects the ESP32 and the Raspberry PI to the shielded cable ( currently we use just regular cheap usb cable).

2. Maybe try to isolate ESP32, Raspberry PI and the motor drivers inside a metal enclosure?

3. Use external filter for the spindle driver (I think there is one internally?)

Please suggest any other things and share your experience if you have

[terjeio]

Is that a common practise to use grblHAL in that way (without using an external power supply for ESP32)

I have no idea as I have not used a Pi for controlling grblHAL. But it should be ok if the Pi has an adequate power supply?

What kind of switches do you have for endstops and control inputs? Normally open or normally closed? I prefer normally closed due to better EMI resistance and safety (if a cable gets loose it will trigger the input).

Does the controller respond to a reset from the sender?

[phil-barrett]

RasPis are notorious for strange behavior when they are at the margin of their power supply. To make matters worse, there are a LOT of dodgy USB power supplies out there.

[krupis]

Thanks for the responses For the switches I use normally closed.

The raspberry pi is being powered from the original power supply that came with my Pi so that should be fine

On Tue, 9 Feb 2021, 19:53 phil-barrett, notifications@github.com wrote:

RasPis are notorious for strange behavior when they are at the margin of their power supply. To make matters worse, there are a LOT of dodgy USB power supplies out there.

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

[krupis]

I will test if the controller responds to a reset tommorow

On Tue, 9 Feb 2021, 19:44 Terje Io, notifications@github.com wrote:

Is that a common practise to use grblHAL in that way (without using an external power supply for ESP32)

I have no idea as I have not used a Pi for controlling grblHAL. But it should be ok if the Pi has an adequate power supply?

What kind of switches do you have for endstops and control inputs? Normally open or normally closed? I prefer normally closed due to better EMI resistance and safety (if a cable gets loose it will trigger the input).

Does the controller respond to a reset from the sender?

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

[phil-barrett]

The raspberry pi is being powered from the original power supply that came with my Pi so that should be fine

Possibly, but how much draw does the ESP system have? It depends on how much headroom the power supply has. I have a supply for a PasPi 4 that is fine until I connect a Teensy that pulls 100 mA.

[krupis]

Hmm. I cannot know for sure how much my ESP32 system draw. The power supply for Raspberry is rated for 3A. I will also try to disable the WIFI on the ESP32 that is known to draw quite a bit of current.

If you say that there could be a problem powering ESP32 through my PI, is there any way to overcome this problem? Should I power my ESP32 through some external source?

[phil-barrett]

I am not saying it is definite that you have an issue with it. Like I said earlier, the RasPi does exhibit odd behavior when at the limit of the supply and a draw spike when you are close to the limit will cause problems. I had to switch to a more beefy supply for my RasPi when testing against the Teensy. There are a lot of USB "chargers" that claim to have a high current capability that really don't. The official ones are usually pretty good though there is a staggering amount counterfeiting going on.

Powering the hardware from something other than the USB cable would eliminate that as a problem. You can use another USB power supply. You would need to figure out how to disconnect VUSB from from your PI connection and tap in the separate VUSB. Many (most?) dev boards have a way to do that though I am not familiar with ESP32 HW.

By the way, I use a USB ammeter when powering my hardware to understand total current draw. I made some "backpacks" for those ubiquitous panel meters that make it easy. I use it when running with a Teensy so I know its current draw.

[terjeio]

Please open a new issue in the new repo if this is still a problem.