Feature/automatic threading

[Pawcu]

Summary

IMPORTANT: Requires the corresponding PR on the STM32 Firmware in order to function: bartei/rotary-controller-f4#12

Add assisted threading support to, including the AT wizard flow, spindle sync / pitch validation, LHT/RHT fixes, and UI integration. This branch also includes upstream dev/main merge work and stabilization for the new assisted-threading feature.

What changed

• Added Assisted Threading UI and wizard flow:

  • rcp/components/home/assisted_threading_bar.py
  • rcp/components/home/assisted_threading_wizard.py
  • rcp/components/home/assisted_threading_settings_popup.py
  • rcp/components/home/at_mode_layout.py

• Added thread type and AT mode support:

  • rcp/components/home/thread_type.py
  • rcp/components/home/coordbar.py
  • rcp/components/home/dro_coordbar.py
  • rcp/components/home/servobar.py

• Fixed issue with servo/spindle sync in ELS mode:

  • rcp/dispatchers/axis.py

• Added/Updated UI/screen components

Behavior

• Implements a full assisted threading wizard and settings path
• Adds spindle sync validation and thread pitch safety checks
• Supports right-hand threads, left-hand threads and inner and outer threads. Contains direction-aware cutting logic but only supports cutting with the spindle only turning CCW.
• Improves wizard startup validation so scales must be set before AT begins
• Adds UI/state consistency across modes, popups, and plot/toolbar components

Notes

• Includes merged changes from upstream dev/main
• Focus is on assisted threading feature delivery plus integration bug fixes

[Funkenjaeger]

This feature evidently also requires your corresponding changes to the STM32 firmware ( PR: bartei/rotary-controller-f4#12 ) in order to function - a rather important detail for this PR!

[Funkenjaeger]

This is rather timely, as I am currently working on revising the ELS UI and was beginning to add the capability to turn or thread up to a shoulder with electronic stop, jog to retract, and re-sync for the next pass - similar to what you've done, but less automated. I already made my own firmware changes, but with a different approach than you used.

I'll take a closer look at what you did and consider whether I want to adopt your approach instead.

[Pawcu]

This feature evidently also requires your corresponding changes to the STM32 firmware ( PR: bartei/rotary-controller-f4#12 ) in order to function - a rather important detail for this PR!

Yes! I knew I was missing something when writing the description. Thanks for pointing it out - updated it accprdingly

This is rather timely, as I am currently working on revising the ELS UI and was beginning to add the capability to turn or thread up to a shoulder with electronic stop, jog to retract, and re-sync for the next pass - similar to what you've done, but less automated. I already made my own firmware changes, but with a different approach than you used.

I'll take a closer look at what you did and consider whether I want to adopt your approach instead.

Glad to hear it might help, hope that maybe we can find a middle ground so we can merge this to main 😊

[Funkenjaeger]

Glad to hear it might help, hope that maybe we can find a middle ground so we can merge this to main 😊

Agreed!

On the firmware front, it's interesting to me how differently you and I approached the challenge of accomplishing the electronic stop and maintaining sync between spindle and leadscrew between passes. I don't think either is right or wrong, just very different, so I'm having a hard time comparing to decide which I like better!
(I think your idea of latching the spindle phase is quite clever, by the way)

On the software front, I was planning to integrate into the ELS mode page and support simpler use cases like turning up to a shoulder. The wizard approach is great for automated threading cycles, I'd just like to figure a way to fall back to a simpler UI workflow for the simpler/less-automated use cases without needing to have a separate mode/screen for it.

[Pawcu]

Glad to hear it might help, hope that maybe we can find a middle ground so we can merge this to main 😊

Agreed!

On the firmware front, it's interesting to me how differently you and I approached the challenge of accomplishing the electronic stop and maintaining sync between spindle and leadscrew between passes. I don't think either is right or wrong, just very different, so I'm having a hard time comparing to decide which I like better! (I think your idea of latching the spindle phase is quite clever, by the way)

On the software front, I was planning to integrate into the ELS mode page and support simpler use cases like turning up to a shoulder. The wizard approach is great for automated threading cycles, I'd just like to figure a way to fall back to a simpler UI workflow for the simpler/less-automated use cases without needing to have a separate mode/screen for it.

OK I'm curious now how did you do it on the firmware side? 😁 Oh and I had some help from chatgpt to get good ideas on how to do it so I can't take full credit for it XD
I was thinking of implementing it on the els page as well but since mine does a lot of automation, I wanted to keep the els page for the simpler els modes in case you don't want to use the wizard. This way you still get full control.

[Funkenjaeger]

OK I'm curious now how did you do it on the firmware side? 😁

I'd describe my approach as being a digital adaptation of the way an operator would thread on a purely mechanical lathe using the half nut and threading dial:

• Operator mechanically stops the carriage by opening the half nut ≈ ELS stops it by cutting off step pulses
• Leadscrew keeps running while half nut is disengaged ≈ ELS keeps track of skipped step pulses while stopped as if the leadscrew were still running
• Operator manually resets the carriage for the next pass while half nut is disengaged ≈ operator is able to jog the carriage (using the existing RCP jog mode of the firmware) while ELS is stopped
• Operator uses the threading dial to determine when to re-engage the half nut to be in sync ≈ ELS re-syncs by calculating and performing a short move, less than or equal to half a thread pitch, and re-engaging normal ELS motion

For that last step (re-sync), I could take inspiration from your implementation and rather than doing the short re-sync move, just wait for the spindle to rotate into phase before resuming - then it would be even MORE analogous to using a threading dial.

I'd describe your approach as CNC-like, as you're calculating the cutting move (# steps) in software up front before starting the move. Makes sense for the automated threading use case, as you're basically implementing a whole canned cycle that just happens to involve some operator intervention.

So now the questions I'm thinking through are:

• Can your firmware approach be readily adapted to also support the simpler use cases?
• Can my firmware approach be readily adapted and integrated with your wizard?
  • (I think it already supports the cutting moves, and there's already support in the original FW and SW for an indexing function, used by the Indexing mode, which I think would support the rapid carriage reset moves with trapezoidal ramp)
• Which end result is more elegant?

Oh and I had some help from chatgpt to get good ideas on how to do it so I can't take full credit for it XD

Oh no worries, Claude is helping me out, I'm just being rather prescriptive about how I want it implemented :)

I was thinking of implementing it on the els page as well but since mine does a lot of automation, I wanted to keep the els page for the simpler els modes in case you don't want to use the wizard. This way you still get full control.

Makes sense. What I was thinking is that by default, the ELS screen would come up in basic mode, no advanced features enabled and looking pretty much the same as it does now, just with a button for toggling the advanced features on/off. When toggled on, a new bar would appear (either above the ELS bar, or right below the Z axis bar) that would have some UI controls for simpler electronic stop use cases (e.g. turning up to a shoulder), and then a wizard button that would bring up your assisted threading wizard instead for the max level of automation.

[Pawcu]

Not sure I'm fully following your approach but then again my engineering and lathe skills suck (hence why I really wanted to implement this assisted threading xD)
I like your idea of integrating with the ELS page. We could implement it like that as well.

First priority though I think would be to split the wizard into separate files for better readability and testing. Github copilot came with a nice plan, but broke everything during implementation. Still need to try Claude (ran out of credits last time xD)

In the meantime I also want to try and implement a compound slide feature where the els advances just slightly for each doc based on a calculation (which I still need to learn 😅)
Luke also wants a multi start thread... Which I think would be nice as well. But getting ahead of myself xD

[Funkenjaeger]

In the meantime I also want to try and implement a compound slide feature where the els advances just slightly for each doc based on a calculation (which I still need to learn 😅)

Similar to what you achieve by setting the compound to roughly half the thread angle and advancing the tool from pass to pass using the compound instead of the cross-slide - except leaving the compound slide out of it and accomplishing the compound movement electronically instead? Neat idea, and wouldn't take much to implement.

Luke also wants a multi start thread... Which I think would be nice as well. But getting ahead of myself xD

Sounds similar to the indexing feature of the existing RCP Index mode screen, which seems to be oriented toward cutting/grinding spiral flutes - which are basically multi-start threads, in a way. I don't think it would take much... in my FW I'd just increment the leadscrew by an offset equal to / . In yours, I think you'd just increment your latched spindle phase by / . The UI could just be a copy-paste from the Index mode screen.

[Pawcu]

Similar to what you achieve by setting the compound to roughly half the thread angle and advancing the tool from pass to pass using the compound instead of the cross-slide - except leaving the compound slide out of it and accomplishing the compound movement electronically instead? Neat idea, and wouldn't take much to implement.

In theory yes. But I tend to realise that what seems simple in my mind always ends up in opening a can of worms and bugs :D

Sounds similar to the indexing feature of the existing RCP Index mode screen, which seems to be oriented toward cutting/grinding spiral flutes - which are basically multi-start threads, in a way. I don't think it would take much... in my FW I'd just increment the leadscrew by an offset equal to / . In yours, I think you'd just increment your latched spindle phase by / . The UI could just be a copy-paste from the Index mode screen.

Yes i might take some of the UI from that. However I was thinking most of the setup would be done in the popup, and once you finish one thread cut at full depth, then you move to the next one. Still need to have a proper think about it.

[Funkenjaeger]

To avoid further cluttering your PR, I started an issue on my own fork for further discussion about the alternate implementation I'm working on. I welcome your feedback/collaboration.
Funkenjaeger/rotary-controller-python issue #1

I completed an initial mockup of how I envision it all being visually integrated into the ELS mode screen, with an incremental approach where the user can enable progressively more automation as they choose, from basic turning up to a shoulder all the way up to the mostly-automated assisted threading wizard based on your implementation. Screenshots and explanation are in the above linked issue.