Advanced Search

Yes, I already tested it and those new HAL pins work.Thanks.

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

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...

Are the motors connected to the linear axis?

This will affect the loop stability

Can you change the velocity loop gain on the drives?

Hello guys, 

a friend and i have planned a retrofit of an old industrial CNC Mill - a MAHO MH400E - since many years, after scoring it back in 2020 and driving it through Bavaria while the very first Corona wave hit the whole world.

The first intention was to retrofit the machine with Mesa hardware and LinuxCNC. After destroying two Mesa boards in another machine build, we decided to use propper industrial components. Therefore the desire to use EtherCAT with reliable Beckhoff hardware arose. After gathering all the necessary components over the years, it was finally time to implement drivers and everything in order to install the accumalted hardware into the Maho CNC mill. The whole process can also be found in my bachelors thesis and is publicly available on GitHub .
The thesis is intentionally written in a way, that beginners have all necessary EtherCAT commands, instructions on how to build the repos from source and CiA402 related information centralized in one place. 

The retrofit is not finished at the moment and the process of implementing every component into the CNC mill will be shared here. We aim to execute this retrofit to the highest possible standard, drawing on our professional backgrounds in electronics and mechanics.

Starting from 05/2026, the hardware is mounted inside the control cabinet - which is subject to change, all spindle motor speed controll with contactors will be removed and all the 400V components will be replaced with newer Siemens safety hardware and contactors. The machine is able to read the axes position with an accuracy of 2µm (1µm was planned). The root cause of this problem is subject of the future posts. I'll keep you posted. 

All machine files can be found in this GitHub Repo (Maho400E-LinuxCNC) , the custom interpolator PCB is also avaliable on GitHub (SinCosEnc-Conv_EP5101) , the custom EtherCAT drivers can be found in the seperate "linuxcnc-ethercat" repo and in the long shot, the Siemens Machine Keyboard ( Siemens-LinuxCNC-Interface ) is also planned for implementation as a seperate EtherCAT device. 

If you have any questions, just join the conversation

Best Regards
Patrick
 

I have taken many false starts at attempting this over the years. It is nice to finally do something about it.

I would love to know how Schaublin did this with no feedback other than the encoder, and less compute than a toaster. I am not sure if it did real CSS, or just lots of fixed, open loop timed steps. I will let you know how my last change software solution with such open loop, actually works (or not).

Assuming I fail... (good assumption ... and need to add a sensor...

Please share your argument for CVT lever feedback vs motor encoder.
I don't really see the advantage of feedback of the CVT positioning lever, given the non-linear relationship of position verses ratio, which would require an equation or LUT,  and have all the inaccuracies and slop in those linkages. That whole drive unit is beautifully engineered and made. Pulling that little 3ph CVT positioning  motor and replacing it with a servo (I have no step gens) adds a fairly complex  mechanical project, and the need for another servo driver (I dont have space for). 

A motor encoder would allow for a highly accurate, real time reduction ratio signal, which can be installed with just a mod to the motor cooling duct, a single cable (okay plus one for the electric fan), and connected to an existing spare 7i85 encoder channel. The back gear is only shifted stationary, so the ratio is only adjusted when running by the CVT. 
Cheers,
Mark
 

My first idea was same as SMC.Collins with a stepper motor instead of the existing AC one on the variator, the second idea would be a linear potentiometer bolted to variator, and analog reading on a Mesa input, low resolution yes, but more that enough for this case.
Set some ranges in hal and be done with it, let the VFD do the fine adjustments.

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.

 

Thanks, I will look into these parameters!

My thought behind adding it as an E-stop was to have it as part of the safety relay circuit outside of linuxcnc.

I need help with this. I can not seem to get mine working. If you remember how you where able to do it would be a great help. The hal file only loads after the psng probe screen. I can switch back to the gmoccapy change.ngc and it work as expected but i can then not probe like i want to. I can not get the correct tool height after gcode start. Any help would greatly be appreciated!

Measure between gnd and each channel.

You cannot do this without two  differential probes.

Measure the A,B signals relative to ground.

But as you said I don't think this is the issue as long as the position
readout is correct.
 

I was measuring it against the compliment. I had the probe on channel A and the ground on the probe clamped to the inverse channel A. Same thing for channel B.

Viewing channel a and channel b in HALSCOPE everything looks normal. So I’d assume this isn’t actually the issue either.

scsmith1451 wrote:

The GMOCCAPY documentation indicates that if no EMBED_LOCATION is defined, the the glade VCP will be floating. Is that no longer valid?

AFAIK this was never supported. Where do you have this info from? I can't find such in the current Gmoccapy documentation.

Have a look at this, no AI was harmed during that retrofit !
forum.linuxcnc.org/show-your-stuff/32784...-15-retrofit?start=0