Questions regarding electronic lead screw

[ddovod]

Hello. First, thank you very much for all the work you do for this project! I'm looking for a project that can be used as an electronic lead screw for the lathe with CNC capabilities, so the lathe can be used either in manual mode (with convenient feedrate configuration and other semi-automatic stuff) or CNC mode. All the projects I've found so far was either els-only or cnc-only, so I decided to try to adopt grblHAL to perform els tasks and probably implement it as a plugin with custom control panel, mpg, joystick, display, etc never mind. The idea is to feed grblHAL with commands based on joystick and other inputs state in close to realtime manner. For example, G33 can be used for threading, G93-95 for turning, G1 for async operations like slots or gears, and somehow get the spindle position to use it as a dividing head. My setup is stm32f411 blackpill + 2 steppers + 1800ppr quadrature encoder. The encoder has 3 outputs: 2 pulses with phase shift (A and B) and index (Z). As far as I can see, grblHAL accepts 2 inputs from the encoder (A and Z or B and Z). Looks like it assumes that the rotation is always goes in one direction, so if I enter G33 Z-100 K1, wait for Z to reach -50, stop the spindle and run it in opposite direction, the carriage will still be moving towards Z-100, please correct me if I'm wrong. I understand that full support of reverse rotation is pointless for G33 because it doesn't make sense to run gcode in reverse direction. But I see very common use case in manual turning when you sometimes stop the spindle, measure the part, start it again, turn etc, and when the spindle is stopped, you can accidentally move it backwards a couple of degrees, and the position becomes invalid. To solve this problem, the firmware should use all 3 inputs from the encoder anyway, so the first question is: how hard would be to ignore backward rotation of the spindle (considering 3 inputs), but when it starts spinning forward again, to keep track the thread as it was before? Or probably it would be easier and more correct in general to implement this behaviour as a separate mode/gcode/mcode? The second point is related to the presice configuration of sync point between spindle angle and linear axis position. Sometimes I need to restore a thread, so I need to place the cutter right between the threads, save the "sync position" and run it as usual in sync mode. Sometimes I need to cut a multistart threads, so I need to cut a thread, set new "sync position" 0.2mm farther or 40 degrees farther or so, cut another thread, move it again etc. So the second question is: do you plan to support something like this, or is it easy to achieve this with a plugin? What do you think in general, is it worth to try to make els on top of CNC firmware? Also, what rpm can grblHAL theoretically handle on f411 blackpill with 1800 PPR encoder? Thank you very much, and sorry for a longread

[terjeio]

So the second question is: do you plan to support something like this

I am not sure, perhaps indirectly as I want to support G33.1 (rigid threading) and this would require quadrature encoder support.

is it easy to achieve this with a plugin?

It is likely this will require core changes, implementing G33.1 in the core first may help. How easy to implement ELS functionality depends on ones skillset?

What do you think in general, is it worth to try to make els on top of CNC firmware?

I cannot answer this in any meanyful way as I do not know what it would take to do it.

Also, what rpm can grblHAL theoretically handle on f411 blackpill with 1800 PPR encoder?

In excess of 100K if using a 32bit timer configured for quadrature decoding? You would have to check that the required pins are available on the Blackpill...

Perhaps this project can be used as reference?

[ddovod]

and this would require quadrature encoder support

It would be great if this data will be available and somehow configurable on the plugin level so one can read and reset current spindle and linear axis sync point

In excess of 100K

You mean 100k impulses per second? That translates to something around 3000rpm which sounds great.

You would have to check that the required pins are available on the Blackpill

STM32, specifically f411, has 4 timers capable of handling quadrature encoder signals, it automatically maintains a register value depending on rotation direction. On blackpill PA15 and PB3 are T2 channels 1 and 2, and these pins are used as SPINDLE_PULSE_PIN and SPINDLE_INDEX_PIN on blackpill right now. TIM2 is 32-bit timer with encoder mode support. I'm not familiar with other hardware that you plan to implement spindle sync for, but probably it make sense to consider to use these 2 inputs as A+B instead of A+Z and calculate Z programmatically.

How easy to implement ELS functionality depends on ones skillset?

Yes sure, but I assumed that you have probably thought about ELS already and have some thoughts and insights. I'm planning to dig into grblHAL plugins and examples, grblHAL looks so powerful and it would be great if the ELS idea will fit here

[terjeio]

You mean 100k impulses per second?

The counter should easily handle 100K+ RPM if it is similar to the MSP432 quadrature encoder peripheral, IIRC it can handle 20MHz+ input.

It would be great if this data will be available and somehow configurable on the plugin level

It is already available via the hal.spindle struct, but I guess I have to add a direction property. Configuration is via $-setting(s).

so one can read and reset current spindle and linear axis sync point

This is the tricky part. E.g. should the encoder data result in motion commands sent through the planner or should it drive the stepper interrupt callback directly...

STM32, specifically f411, has 4 timers capable of handling quadrature encoder signals

I know, however I have never configured any of them for encoder input.

I assumed that you have probably thought about ELS already and have some thoughts and insights.

Not so much about ELS, full CNC control has been my focus. I have been aware of Clough42s project for some time and I find that interesting - at least single axis movement could use his approach. Multi-axis synced movements (think tapered threads) might be a tad more complicated...

It would be nice if we could cooperate on making this work. My lathe is fully CNC controlled so I have no means to test ELS functionality. However, I hope I can modify it to support rigid tapping which would share some of the code with ELS.

[ddovod]

Thank you very much Terje, I think I should first try to implement some ideas and wire things for grblHAL. Lets keep this issue open, next time I'll come back with more specific questions