Mesa 7i77 output scale

They should be close to the same (the difference in commanded and actual position)
There is a subtle difference due the fact that they differ by one sample time
Ferror measures the difference in the current position and the previous commanded position and PID error uses current values for both.
This difference should be minor. If theres a big difference it may be that theres some configuration error or that they were not read in the same conditions

Looks like this config was built with pncconf.
There was a bug at one point where the fb was incorectly configured.

please look for this

net [AXIS]-vel-fb => pid.[AXIS].feedback-deriv

and not;

net [AXIS]-vel-fb => pid. [AXIS].command-deriv

[AXIS] being whatever axis your looking at (look at them all)

Just to be sure.

Chris M

Interesting

pid.N.error-previous-target bit in

[/b]Use previous invocation’s target vs. current position for error calculation, like the motion controller expects. This may make torque-mode position loops and loops requiring a large I gain easier to tune, by eliminating velocity-dependent following error.

I’ve not seen this used anywhere before and thought I’d see what it did.

setp pid.z.error-previous-target 1

With it set to 0 (presumably by default), pid and axis.ferror do not correlate at all.
With it set to 1 they do.
So … should it be set to 1 and if it’s not which error should we be tuning to?

with and without attached

I think its OK at 0 for velocity mode drives (in this case you can tune out the velocity
dependent error with FF1) Normally you do not use any integral term in linuxcncs PID
loop with velocity mode drives

for Torque mode or any where you use a integral, term I would set the option to 1

(and you always tune to minmize ferror)

I term was a killer …. Cruise now well under a micron …..Progress report tomorrow.

I now = 0

At the risk of going slightly off topic ....

I’m trying (still) to get to the bottom of a problem tuning the axis on a Harding HXL lathe.
Heidenhain 10 micron linear encoders on both axis, interpolated to give 25600 counts per mm.
The 7i77 is driving a control techniques Digitax ST drive with a 670W CT unimotor servo.
The motor and drive have been auto tuned successfully with the motor driving the load.
The drive is setup to do +/-1617 RPM at +/-10V
LinuxCNC is sending out the correct voltages given the demanded velocity

Doing some maths , the default acceleration setting for the drive is 1000RPM per 0.2 seconds, so

Ballscrew pitch (mm) (25.4/5) 5.08
Belt reduction (56/15) 3.733333333
1 rev of servo = mm 1.360714286
RPM required to do 2200 mm/min 1616.7979
Velocity mm/sec after 0.2 sec (1000/60*1.360714) 16.66666667
Velocity mm/sec after 1 sec (16.66667*5) 83.33333333

Acceleration is set to max of 60mm per sec per sec in ini.

For whatever reason, there always appear to be something in the region of a 10-14ms delay between the command and any movement reported back by the encoder.
This problem is almost identical to the Omron servo and drive on the X axis.
There are no filters set in the CT drive. Its response to the analogue input is 250us.

If I connect a 1.5 volt battery to the input of the drive, i get a response from the axis in <3 ms.

Granted that’s a step change rather than an acceleration ramp, but it sort of suggests that both the mechanical and electrical side of things are capable of the response and the acceleration.

Regarding error, axis.N.f-error - (float, out)

Float what? Velocity error or position error?

I decided to plot error_test.out which is encoder position less commanded position.

setp error_test.gain1 -1
net z-pos-cmd error_test.in0
net z-pos-fb error_test.in1

Does that give position error? If it does, its different to axis.N.f-error

Supposing that error units are microns of positioning error, with a 3 micron spike at the beginning of a move and better than 1 micron during the cruise section, have i reached the as good as it gets point?

There is only a small (150 usec or so) delay between LinuxCNC issuing a analog command
and the output being available on the 7I77 terminals. I suspect that the delay you see is drive velocity
tuning related.

An easy way to check drive velocity loop tuning is to lower the P gain (and I and D set to 0)
adjust FF1 for the best following error, and check for sluggishness or ringing during the velocity rampup
and adjust the drives velocity mode settings for best following. You can even set P to 0 and check the
velocity profile (the position will drift) In this case any ringing is entirely a drive tuning issue

(Commanded position - feedback position) is different than ferror because ferror is the difference
between the current feedback position and the _previous_ commanded position. The difference is
velocity*sample period.

ringing .. ? (sorry!)

ringing is oscillation. There seems to be some oscillation, instability during acceleration

Regardless of anything, the velocity ramp follows the acceleration ramp perfectly, once it’s overcome its initial cough and a delay of 10+ms.
Anything I touch on the drive makes matters worse. There’s no way I can increase P on the drive.
I changed the axis motor and drive on one axis (from Omron / Yaskawa to CT) as this delay was present on both X and Z in the hope that the drives / motors were the problem. The problem is identical regardless of the fact that there’s now a brand new, current, high end drive and motor on this axis.
Despite the “ringing” question, the servo sounds “right” with its autotune settings.
I don’t believe there’s a problem with LCNC / the 7i77 causing the delay.
But to be honest I’m on the verge of giving up.