Schaublin 125-CNC retrofit.

I vote encoder.

An encoder separate fan will allow:

• lower continuous motor speed without overheating
• higher continuous motor speed without the chance of a 45-year old fan leaving the chat
• you and LCNC not to guess what the motor speed is, adding confidence you aren't going to send the motor in to orbit

All giving you a wider safe frequency/speed range for your VFD/motor - and thus making each 'step' in the CVT more useful (wider range).

Actually, I vote for getting rid of the CVT.  Do what CNC mfgrs have been doing since the 80's & 90's and stick a big a$$ spindle-servo in there with an 8kRPM top end and appropriate-ratio single-speed belt drive.  Just horse the thing.  Simplify your control loop and save your sanity.

But I digress...

I have a few points.

First: you refer to the fan multiple times. If your machine is like mine, and I have no reason to believe otherwise, the motor has no fan where you think the fan is, the thing there is the brake.

Second: regarding your solution 2, I can make a simple op-amp for you. Scaling to 24 V is easy, as you already have 24 V, and it would have 2.5 times the resolution of the system that gives satisfactory results for me. Yes, it has way less resolution than an encoder, but you do not need it. This would be the fastest and least invasive route.

Marti

My immediate reaction when I saw your problem was a cascade PID loop. These are two PID loops: fast and slow.
The fast loop is a normal encoder to VFD loop.
The second loop controls the CVT. That controller tries only to keep the output of the first loop at 6V (= 50Hz). I think you do not have to calculate the gear ratio, etc. Maybe it would work without any additional hardware.If the output of the fast controller (VFD) is below 5V, the CVT turns on until it hits the limit or the controller output is above 5V and below 7V. Above 7V, the CVT turns on in the other direction.

If this does not work and feedback from the CVT is needed, a Waterproof Wire Encoder (Aliexpress) can be considered. Then, the PV (actual position of the CVT) can be used to calculate / adjust the $K_p$, $K_i$, and $K_d$ of the fast VFD loop. Mark

my eyes glazed over looking at all the options but if its pneumatically actuated, why not a pressure switch? Cheap as chips!

 

Hi Rod. Since the back gear is only switched when stationary, there is no need for such feedback. logging the command is enough. Sanity check once the spindle turns and you can see the overall ratio.

This might be the point where I can give my software-expertise to this project

I wrote some software which simulates the spindle control behavior based on the files uploaded here 17.5.2026. I have very little understanding of actual linuxcnc, so take everything with a grain of salt. The simulator is quite crude and it's translated in python, as I do not have access to a physical LinuxCNC machine for now. I'll need some confirmation that it somehow resembles the actual behavior of the Schaublin now before I dig in further. It does look like that the pid works "ok'ish" on low gear, only a minor overshoot, but it's way off on high gear. There's some possibility that the simulator could be useful when developing a state of the art control. I would also say that no extra hardware is needed, many things can be deducted from the spindle speed, cvt end switches and the motor hz.

The thingy is now there, I did not spend too much time on it, it's also mainly vibe-coded. The translation of the .comp logic is in spindle_supervisor_model.py lines 161:582

github.com/heff3/schaublin-cvt-simulator

Easiest way to get it working is to use "uv", it's a modern python virtual environment manager (does not break your machine). AI will help with this one, but on mac the most convenient way is with "brew install uv". Brew is the most common package manager for osx.

After cloning the repository, one should be able to:
uv run python spindle_realtime_simulator.py

q - quits the application (or the usual ctrl+c)
space - starts the motor
k / j - tunes the target spindle rpm


The simulator behaves better once it has run awhile with a few toggles on/off, dunno if the real lathe behaves the same?

ALERT: The real lathe might have insufficient max rpm limit now. For example if one targets 2000rpm, the pid might overshoot it quite a lot.

my best guess, shaublin just wrote a very difficult to control pid algorithm with slow speed seeking, and they had a team of engineers, and you'll notice , they got rid of the variator, sometimes the best part is no part. for my suggestion with the closed loop stepper, KEEP the existing worm gear angle driver, make a coupler and adapter slap a stepper in place of the existing AC motor. keep the acme screw and angle drive, looks doable without disassembling the machine from photos. Also my path is, 4 wires from you 2 from the psu and 2 step dir  card. it doesn't need to be decimal perfect.