Mesa 7i77 and linear encoder tuning PID.

VNR

Usually Position Loop Gain is 1/4 of Speed Loop Gain (parameters of the drive).

I’ve tried changing the position loop gain to its extremes and it doesn’t seem to have any effect on the trace.
- Instead of the linear encoder, use only the encoder output of the drive to see what happens.
I’ll try this ... I need to make a cable.


- What happens if you use MAX_ACCELERATION 1/2 of MAX_VELOCITY ?

Do you mean literally like below ... as the units are different?
This should give 3000 mm/min (if i read the manual correctly) but acceleration would be minute.
MAX_VELOCITY = 50
MAX_ACCELERATION = 25

- What happens if you put SERVO_PERIOD = TRAJ_PERIOD * 0.5 (or 0.25) ? (and coment BASE_PERIOD if you are not using it).

So ... do i not need BASE_PERIOD then?
Can this line be added directly like this to ini?

SERVO_PERIOD = TRAJ_PERIOD * 0.5


- Do you have a another filter, feed-forward or delay parameter in the drive ?

There is a bit that can be set to enable feed forward, but i think that’s only valid for torque mode and it doesn’t seem to have any effect if i turn it on or off.

Peter

The drive has an auto tune function, but I could never get it to tune. This was early days so I’ll revisit this and see what it comes up with. I should be able to plot what’s going on in the Omron software, similar to halscope but this doesn’t work.
The drive has a bit that can be changed to enable “speed” or “torque” mode. Then there are separate connections for speed ref and torque ref. If I set the drive to torque ref, and have the output of the 7i77 connected to speed ref, nothing happens so this confirms that the drive is responding to what’s connected to the speed reference input.
Now I’ve got velocity being plotted, that might help ... am assuming that i forget following error until I’ve got the velocity ramp looking the same as the analogue out ramp, and then start to look at the flowing error with fine tuning of parameters?


Andy

The output of the Heidenhain linear encoder is connected only to the 7i77.
The motor has a 2048 count incremental encoder built in; this is connected to the drive, and must be connected to the drive.
The drive can output the servo encoder pulse - 2048 pulses as a differential output. This output is not connected to anything at present.

All

Forgetting the mechanical side of things for one moment or assuming that they were perfect, how close would you be expect to be able to get in terms of positioning and following error to an industrial control like a Heidenhain TNC415/425 which would use the same sort of encoders and analogue drives?

am assuming that i forget following error until I’ve got the velocity ramp looking the same as the analogue out ramp, and then start to look at the flowing error with fine tuning of parameters?

Yes, thats one way, currently the velocity loop in the drive is not performing well so one option is to first tune the velocity loop in the drive as well as possible and then tune the position loop in LinuxCNC. Note, one way to do this is set LinuxCNCs PID terms to 0,0,0 and set FF1 to 1 (and FF2 to 0) This just passes the (scaled by FF1) commanded velocity to the PID output with no feedback at all

Also can you post your LinuxCNC P,I,D, FF1,FF2 values?

a velocity mode servo (with the velocity loop in the drive) should have a position loop in LinuxCNC with mainly P and FF1
(FF1 should be 1.0 if the PID parameters are normalized, that is the PID output scaled in machine units per second)
very little if any D should be needed as that part of the control should be done in the drive (its velocity loop gain is equivalent to linuxCNCs D ). When everything is tuned close to minimum following error, some I can be added for 0 static error/minimum cruise error.

A torque mode servo will have a balance of P and D in LinuxCNCs position loop (P alone will be unstable) and very little FF1. A torque mode servo also will likely be improved with some FF2 to add the additional torque needed for accel/decel

There are some complications I have ignored here (like the fact that the drives velocity feedback is coming from the rotary encoder and LinuxCNCs position feedback is coming from the linear encoder and there is some "spring" between these.
Because of this "spring" its probably better if you can get the drives velocity loop to perform well rather that run the drive in torque mode with only linear encoder feedback.

PID/FF etc - These (mainly P) obviously get changed – a lot

Some thoughts ......
I’ve changed the drive for a brand new one in case there were any legacy parms in there that i can’t get too or don’t know about.
I’ve tried auto tuning and it worked, on one occasion. All the parameters were defaulted before the auto tuning and the only parameter that it changed was the speed loop gain was increased from 80 to 212. If the speed loop gain is left this high, I just get massive oscillations regardless of P being anything from 0-100

Out of curiosity, I observed the velocity trace while turning the ballscrew by hand with the drive off, any disturbance / rotation to the ballscrew induces movement on the velocity trace, immediately. The ballscrew is easy to turn; i can move it easily by rotating a 40mm diameter spacer on the end of the BS where the original tacho sat with my fingers. Not very scientific but I’m leaning towards the fact that the drive just isn’t responding quickly enough for some reason to the output from the 7i77.

I’ve got rid of BASE_PERIOD and changed both traj and servo period to 1000000

Even if I stick P in at 50, the 12ish ms delay at the beginning does not change.

Some other interesting points, I have a TESA inductive probe set up with an LCD display unit. This system is accurate to within 0.1 of a micron. The probe is measuring the x crosslide movement.
If I set the unit to display 1000.0 microns when the axis is at say 25.000mm and then move 1 mm with MDI, then move back to the reference point with MDI, it settles immediately at the reference point – 1000.0 microns.... bang on every time!

Also, i have a 500 count encoder set up in one of the spare encoder channels as an MDI input.
This is set up so that it takes 100 or so encoder counts to jog one micron, this it does.
There’s some fluctuation on the display when its half way between 0.1 microns, but it is possible to jog in tenth of microns..... Just to really add to the confusion!

P looks too low to me, does it become unstable if you add more P?

Yes if I increase P enough, i can hear and see them as previous plots show oscillations , but only during the move. See post #23120

It seems that P does nothing to improve the “launch” delay, it remains as a constant regardless.

can I see the same plot with P set to 20?

P=5