1988 Fadal 4020 Conversion Thoughts: MESA 6i24 + 7i49 + ?

Oh and I did also just remember that I could use these DC drives in torque mode by disconnecting the tachometers. Someone did this with a Kflop conversion of the same mill with the same drives - by cutting a resistor lead and soldering a wire onto said resistor past the velocity feedback loop on the drives.

Does anyone have insights on if I would be better off bypassing the tachometers like this?

With LinuxCNC + 7i49 it seems like the resolvers would provide accurate speed feedback? Then I have one less failure point without the tachometers in the mix.

hilo90mhz wrote: Do you know of any quantitative analysis comparing their specs (update rate, accuracy) vs encoders? I have googled this but not come up with any good resources mostly just industry stuff saying they each have their place etc etc with no real hard numbers.

I don't know of anything quantitative, no.

Resolvers are probably less linear than encoders, in that 1 shaft degree with an encoder is pretty much exactly always the same number of encoder counts, whereas with a resolver, unless they are very carefully made, this isn't necessarily true.
The fact that they have to be made so carefully is why they are expensive to buy new.
Resolvers specified for a CNC machine should be very linear, but possibly still not quite as good as a good encoder.
That said, if it is 5% non-linear on a x6 resolver and a 5mm leadscrew that's an absolute error of 40µm, but no cumulative error.
On that basis you would want less than 5% non-linearity.
I think that my spindle resolver on the mill is worse than that, as I think it was designed to be a handwheel input or similar. Only noticable when hobbing gears when you can see the speed of the 4th axis change. The gears come out OK, tough, so I am not convinved that it isn't a genuine cycling variation in spindle speed. I plan to run a calibration on it, and if there is a problem, it is very much fixable in HAL....

On the other side of the coin, if you get a glitched measurement with a resolver, the next measurement will correct it. A glitched encoder count stays there until you next home. (though you would need a lot of them, and in apreferred direction, to accumulate a significant error)

I have my lathe set up to use the fact that resolvers are absolute and that LinuxCNC can save the position to arrange to never have to home the machine (unless the position.txt file gets corrupted)

Thanks for the insight Andy! That was a great explanation and basically answers all the questions I had about resolvers.

The Fadal machines actually have no homing or end stop switches at all! They instead have alignment pointers on all 3 axis - and as long as you shut down the machine at home position or jogged it close to those markers and then issued the CS command it would use the absolute nature of the resolvers to find its home position without any other sensors - neat and dead simple system.

Judging by what you've done with your lathe sounds like I could duplicate this and not need to add any new homing switches which was something I wondered about.

Is there an easy way for me to do this same setup that Fadal used with the alignment markers on LinuxCNC? Maybe I would have to write a python routine to find some absolute reference value from the resolver? I believe the resolver position must be less than +/- 90 degrees of the resolver reference position for this to work. By "reference" I mean some arbitrarily chosen position on the resolver as it is by nature absolute, not an actual reference like on an encoder.

hilo90mhz wrote: Do you know of any quantitative analysis comparing their specs (update rate, accuracy) vs encoders? I have googled this but not come up with any good resources mostly just industry stuff saying they each have their place etc etc with no real hard numbers. Ideally comparison would be between resolvers with 7i49 vs a high count encoder used with the 7i52 or similar? but I am not sure this exists.

The update rate is set entirely by the device that excites and reads back the position. The resolver is basically a transformer with a magnetic coupling that changes with angle of rotation.

The converter I build uses the Analog Devices 2S1200 converter chip, and the default excitation is 10 KHz.
So, 20,000 times a second it makes a reading of the sine and cosine signals coming back from the resolver and fits them to an angle. A tracking circuit approximates the velocity and generates counts that are converted to quadrature. It can go as fast as 4 million counts/second (but that would require the resolver to be spinning at 60,000 RPM.)

The thing I am most worried about failing is the brushed DC motors(4 brushes per motor), brushed DC tachometers(4 brushes per tachometer) and the 30 year old DC motor drives that rely on those tachometers for speed feedback.

Besides them failing I am worried I will not be happy with the following error or response speed of this system with these older design components, but that may be misplaced and I wont really know until I buy the conversion boards and rig it all up to try and spend the time to tune them.

Well, in a hobby environment, the motors should last a lifetime. Since the tachs don't carry current, they should last even longer. If you are putting this machine into full-scale production, then replacing them with modern brushless motors makes sense.

Jon

Thanks Jon, now that you say it that makes perfect sense that the update rate is based entirely on the electronics reading the analog values as the sensor is purely analog...

Do you have anymore information online about the Analog Devices 2S1200 based converter you make?

www.mouser.com/datasheet/2/28/11BRW-300-F1-6-958427.pdf
I have read the resolver datasheet more now and see that it specifies "max error from E Z: +/- 6 minutes" which I assume means it has +/- 6 arc minutes per revolution accuracy? The transformation ratio is 0.5 (I originally thought it was 1/6th but that was the accuracy of 6%).

My ball screws are 0.2" per revolution.
Calculations to determine accuracy based on datasheet:
6 arc minutes accuracy = .1 degree
360 / 0.1 = 3600 points per revolution accuracy
.2" / 3600 = 0.000188" or 0.00477mm or 4.77um accuracy
Does this makes sense?

I am okay with that accuracy

My resolvers are rated for 2500hz - do you know what this means and if they should not be operated at any other frequency? less linearity at other frequencies?

You are right I should probably not worry about the motors/brushes too much in a non high volume production environment, this will be used for prototype development work and low volume production.. Accuracy is important. That just leaves the DC drives which are repairable / replaceable with modern equivalents..

I'm still about 50/50 with replacing vs keeping these motors / drives, leaning slightly towards keeping them right now.

hilo90mhz wrote: Is there an easy way for me to do this same setup that Fadal used with the alignment markers on LinuxCNC?

You can just set up LinuxCNC for immediate homing. Then you can power-up, jog to the markers and press home. That will give you accuracy as good as the marks.

To get the extra bit of accuracy from the resolver absolute position might take some experimentation with the "home absolute encoder" INI options and the absolute pins of the resolver driver.
I think that, compared to my lathe, it is harder to use the marks than to use the full-absolute emulation.