Schaublin 125-CNC retrofit.

Thanks.

Good point. I didn't consider helix angle. I tried with G76 P1.27 J0.4 R1.8 Q30 but the tip chipped out after a few passes. I then went down in J over a few attempts, with 0.2 resulting in a lot of passes, and the tip wearing out rather than chipping. I ended up with R2 and J0.3. I'd put in a fresh tip and rerun the code to clean up the thread, and use that same tip to rough out the next part.

They are crap Amazon inserts, so maybe  as carbide prices went up, they mixed some sawdust into the mixture

I was was unsure how much overhang to give those jaws. I really need to make up some new ones, as all the only I have are heavily used.
Yeah, I only cut in both directions, as it gave me the nice chamfer on the step.

 

check the angle on the bar, and be sure of your tip height, both will break most threading insert, been there got the t shirt

Since I was able to create a usable tool changer control comp with the coding assistance of AI, I figured I had better confront the final boss beast of this CNC conversion... the spindle control. I was already crastinating on this before I turned pro.

If you remember, I retained the original motor, CVT and back gear, and added a VFD instead of the Dahlander motor winding switching. So far I was just manually controlling the back gear and CVT, and guessing what VFD frequency to command, with a single ratio hard coded on the INI, which is roughing right for about 1000 rpm.

I want to believe that I can use a comp to have the system follow S commands, including for CSS cuts.

 

So I have:
- huge variation in inertia, requiring PI gain scheduling based on overall reduction ratio
- no feedback of CVT or back gear position, which lead to the attempt to infer gear ratio from spindle encoder / analog motor speed command.

I got it sort of working with the assistance of ChatGPT(free) for coding. However, the need to freeze the ratio calculation during CVT bumps, or commanded speed changes means it very laggy, with speed corrections happening long into cuts. 

I have attached the ChatGPT created comp and hal, for general interest...
... continued next post, to separate the ChatGPT attachments from the Antropic AI generated files.
 

… continued…

Not being able to improve on that version, I started over in  Anthropic AI (free). This has been less successful. It is a more complex solution, and have had more issues with stability, and the ratio calculation freezing.  

However what is very positive is how easy it has been to have it generating data logging and analysis files. With better data, hopefully I can make faster improvement.   

I think I will do one more attempt to control this without adding hardware.  I will go back to my original concept for this.  

Rather than trying to control the CVT closed loop off that dirty inferred gear ratio, just command it open loop, with fixed ratios. Considering the CVT as five discrete gear ratios, one second apart, I’ll do a a survey of the system to create a lookup table of VFD Hz, CVT “gear” position, back gear position verse spindle speed, overall gear ratio, P and I values. My idea being that on spindle start, it sets the gearbox, then accelerates to the VFD and CVT nearest defined speed in the table, open loop, and then the PI closes the loop to control the VFD to control to that speed. Whenever the spindle is at a steady state long enough for the inferred ratio to become stable, the ratio inferred from commanded motor speed, could be used as a sanity check whether the CVT is still at approx the ratio expected.
Cheers,
Mark

Mark I thought about your issue some more and I have a  solution. Not terribly invasive a little bit of work but saves the variator. 

Return the speed control pid tuning to linux cnc

Put a closed loop stepper motor on the variator. Here's why

1. step counts are easy targets, so 10 steps = 1 point of gear ratio for example.

2. build a table of Frequency from command to stepper that optimizes torque.

So on Y you have commanded input from Lcnc as frequency
on X you have steps iun the table itself you have gear ratios. Build you selector logic to Always shoot for best torque.




Speed Command from g code
encoder feedback
min max home positions.
then spindle at speed output.

the look up table doesn;t even have to be complex could just be along switch statement, if <200 && >300 spnd cmd gear = 4

that's it. then let linuxcnc handle the fine control. your just grabbing the spnd cmd speed and setting the ratio.

See attached

www.alibaba.com/pla/IHSS57-36-20-Nema23-...rGX0_eUaArgzEALw_wcB


 

Thanks for your ideas, this all really helps. 

This is a summary of the various ways I could add sensors, or control to the overall gear ratio. 

1/ pull the motor fan, and use the shaft stud to drive an encoder, and then mount an electric cooling fan on the shround for the motor.
++ Seems most robust solution.
++ covers entire drive train with single unit.
++ high resolution, low noise
++ encoder in and encoder out, the gear ratio would be rock steady and real time.
++ does not require pulling the entire drive unit. 
++ spare encoder input available on 7i85

2/ Make a little amplifier to scale that 0-10V motor speed output to 0-36V
++ Simplest solution
-- I am not strong in electronics.
-- less resolution than motor encoder
-- lower qualiy signal than encoder

3/ use an optical or hall sensor to count motor fan fins, or CVT features.
++ Slightly simpler that adding an encoder... or not...
-- as it would need the entire drive pulled.
-- less resolution then encoder
-- doesn't sense gearbox ratio.
-- dirty environment, unsuitable for optical sensors.

4/ Add an encoder to the CVT linkage, or to the CVT lead screw.
-- better options above
-- need to pull drive unit.
-- non-linear relationship to ratio
-- needs LUT or algorythm to convert to approx ratio.
-- less resolution than motor encoder
-- doesn't sense gearbox ratio.

5/ Replace the CVT motor with a stepper or servo
-- more work than the better options above
-- large wiring change, add addition servo driver etc
 -- need to pull drive unit.
-- non-linear relationship to ratio
-- needs LUT or algorythm to convert to approx ratio.
-- less resolution than motor encoder
-- doesn't sense gearbox ratio.

6/ Use a laser range finder on the CVT belt with a look up table to estimate ratio.
-- dirty environment, optics will likely unreliable over time.
-- better options above
-- non-linear relationship to ratio
-- needs LUT or algorythm to convert to approx ratio.
-- less resolution than motor encoder
-- doesn't sense gearbox ratio.

7/ Using a sensor to detect backgear lever position .
-- dont think there is an external lever, it is internally, pneumatically actuated with no external moving parts.
-- Since it is only shifted stationary, this is the easiest to infer. I can log last position, and cross sheck it using overall ratio, so this seems unnecessary.

8/ adding a gear tooth detector in the gearbox
-- significant effort to pull, disassemble drive unit, and drill hole in housing, design and mount sensor
-- less resolution than motor encoder
-- better options above

Seems to me that the motor encoder would to be the most likely to simply work, and work best. It covers the entire drive train in a single component, offers the highest resolution, and provides (with the spindle encoder) the most direct measurement of overall reduction ratio without noise, interpolation, LUTs etc.

However, before I add a sensor which Schaublin didn't need when they designed this system in the first place, I am thinking of taking one last swing a software solution. My original idea, which I have not yet tried. How accurate does a lathes spindle speed control really need to be?

- divide the CVT range into 5 "fixed ratios", one second apart.
- survey the whole range, generate a look up table of CVT "fixed ratio", and VFD Hz.
- Command the CVT in one second bumps (gear changes).
- largely open loop with VFD frequency interpolated between LUT values.
- Maybe switch to closed loop to fine tune speed (but I am hoping not to need to)
-- if closed loop needed, add PI gains to the LUT.
--  I already have VFD "motor on speed" wired in, and had not thought to use that to gate and freeze the ratio calculation when it would be garbage.
-- when there is steady state operation, use the calculated ratio just to cross check and maybe correct for CVT drift after multiple shifts. In practice, I expect it to be on limits quite often, which is a natural drift reset.

If I can't get that working, and really do need a sensor, I tend to the motor encoder.