is G76 working on ESP32?

[David1r20]

Hello. How can I get the thread function on an ESP32 with TB6600 drivers. I also have optical encoders to monitor the rotation of the shaft.

I just flashed the firmware I saw that the thread function is active on the Grbl-GCode-Sender Is this to work on ESP32? any suggestion?

[terjeio]

Currently only the MSP432 driver has support for lathe mode extensions (G33, G76 etc), and is for now in an experimental state. The ESP32 driver needs to be enhanced for these extensions, optical encoder inputs (including index pulse) and a PID loop for the Z-axis position is required.

It would be nice if somebody (you?) could help with adding (and testing) lathe support for additional drivers. IMO quite a bit of the code from the MSP432 can be reused, the tricky part is likely to be the encoder interface (convert pulse input to RPM and angular position).

[David1r20]

let's do it then. I've been looking at other repositories, see if anything can help us.

https://github.com/fschill/grbl-Mega/tree/spindle_sync

https://github.com/HuubBuis/grbl-L-Mega

[terjeio]

The grblHAL core has build in support for both G33 and G76, to "activate" these a couple of new functions are needed in the driver. I would use the MSP432 driver as a base.

Two timers are used in this implementation, one free running and one which counts pulses from the encoder.

The free running timer is 32 bit wide and rolls over after 23 minutes - note that this is the maximum length of any spindle synced motion that can be handled for now in this implementation.

The timer counting pulses does just that - it has its clock input wired to the encoder pulse input pin. It is also set up to generate interrupts, in this implementation every four pulses.

Also, a second interrupt capable input pin is required for the index pulse.

Input from the timers and the index pulse is then used to calculate RPM and angular position. Some basic calulations are done in the interrupt handlers, the most time consuming only on request.

The first step will be to implement code for these calculations. The grbl core calls functions via the HAL interface struct and uses some flags to determine what is available.

Functions:

hal.spindle_get_data points to spindleGetData in the MSP432 driver, returns RPM, angular position or counter data based on what is requested.

hal.spindle_reset_data points to spindleDataReset, called at the start of spindle synced motion - used to initalize variables. After this is called hal.spindle_get_data gets called repeatedly with request for counter status until two index pulses has been detected. After that the motion starts.

Flags: hal.driver_cap.spindle_sync must be set to true
hal.driver_cap.spindle_at_speed, must be set to true - MSP432 driver does this when settings.spindle.ppr > 0 (ppr - pulses per revolution from the encoder).

I do not know if there is any usable code to be lifted for this from the ports you mentioned but I doubt so, this as code for handling timers and interrupts are generally not portable as-is.

Second step will be to implement a PID loop for the Z-position, I believe this can be skipped if the spindle RPM does not vary a lot under load or the tolerance requirements are not very high. Be aware that I have used floating point math for the PID calculations in the MSP432 driver, this may be problematic for ESP32 as these are done in an interrupt context. ESP32 panics if the FPU is accessed in an interrupt context...

[terjeio]

Continue discussion here.