Mesa 7I77 - Torque vs Current mode Position Error

Good morning everyone and Peter since you, likely, will be the one to respond. I am not sure if this is a Mesa, servo amp, or general Linuxcnc question, but anyway here goes:

First off I would consider myself a middle of the road to slightly more advanced Linuxcnc user. I have built about a dozen step and direction machines.

In the past couple months I have built 2 machines with analog servo amps controlled by Meas 5I25/7I77 combo. Machine number 1 is using Glentek servo amps at 165VDC with tacho's in velocity mode. Machine number 2 is using Copley servo amps at 80VDC in torque mode.

Machine number 1 runs at full rapids and feed speeds and the programmed position never is off more than .0001" from the commanded position.

Machine number 2's position is fairly consistant from cycle to cycle, however the actual position versus the programmed position is usually off half to .001". I can post screenshot of the hal-scope if necessary but in my opinion it is about spot on. Very little to no over/under hooks and a nice flat line during the moves at maximum speed. I can set the min ferror to about .0012 and it will run all day long at maximun rapids and feeds. I have been through all the mechanicals, encoders, and backlash and ruled out any deviations there. I suspect that Linuxcnc / Mesa cards are not commanding enough analog voltage to bring the axis into position because it is within the following error limits.

These machines run in a commercial setting and machine number 2 needs better accuracy. Nothing crazy but a couple tenths to a half max is what I need.

So if it is a "normal" postional errors between torque and velocity modes I will get motors with tacho's or add them to the motors I have. The Copley servo amps can go either way.

My question is this something I need to troubleshoot / tune this or is it simply a difference between velocity and torque modes?

Thanks for your advice and or recommendations in advance.

Kent

Machine number 2's position is fairly consistant from cycle to cycle, however the actual position versus the programmed position is usually off half to .001"

First thing to ask is are the encoder resolutions (in terms of counts per linear movement) the same? If not, then you must compare it in terms of encoder counts.
Generally, without the tech feedback, you need a higher resolution encoder. getting velocity info from a quadrature encoder is a tricky business, as that position is quantized in both distance (encoder counts) and time (servo period). Subtracting successive position samples leads to horrible "noise". Mesa and some Pico Systems interface boards/software drivers have velocity estimation from timestamps which make this "better", but don't totally solve this problem.

If you can swap in encoders with higher resolution, that would be the easiest way to fix it. But, maybe you are looking in the wrong place. Assuming you have shaft encoders on the motors and ballscrews, then all the things you are looking at with Halscope and PID error are only what the encoder can see! If there is backlash or wear in the ballscrew/nut, that won't show up as LinuxCNC sees it, but it WILL show up in the part. It is fairly easy to check backlash. Get the best dial test indicator you have, and put it against a rod in the machine spindle. Creep the indicator toward the rod until the pointer moves. Then, start backing away on 0.0001" increments, and count how many you have to click before the pointer moves. That is your backlash.

Jon

Torque mode often needs a higher than normal servo thread rate
since you are closing the velocity loop in LinuxCNC. A higher
servo thread rate allows a higher stable D term. which in turn
allows a higher P term and lower following error Also
Torque loops typically need significant I term.

Note that the following error setting has no effect on the PID behavior,
it just sets the threshold for generating a following error fault

@jmelson and tommylight - Thanks for your suggestions. Resolution is nearly 42,000 pulses per inch and ball screws are new Thompson's with a a touch less than .0002" of backlash.
Been down that road already

@Peter. I will give your servo thread rate and tuning suggestions some attention tomorrow and see what happens. I will report back.

Thank you.

By comparing axis.N.joint-pos-cmd vs axis.N.joint-pos-fb it was only varying around .0003" before the lastest tuning with peters advice. Now I am at about .0001" which is excellent.

What had me confused was that I was comparing GMOCAPPY's position readout to axis.N.joint-pos-fb and I discovered that gmocappy position was all over the place by .005-.010" and did not match up to either axis.N.joint-pos-cmd or axis.N.joint-pos-fb in halmeter

New tuning and a different UI and all seems well now however I am a bit curious as to where gmocappy "grabs" this reading. Anyone know why or where this position readout comes from?

I did like gmocappy for the brief time that I used it but in a commercial environment the mismatch position is unacceptable to me.

Thanks
Kent