Mesa 7i77 and linear encoder tuning PID.

Motor off in e-stop – wrench tuning ball screw harsh acceleration – red motor encoder – blue linear encoder


zoomed

OK so it does not look to be mechanical (well there's a little maybe belt stretch caused delay in the harsh accel trace)

So it looks like your velocity mode drive is not behaving like a velocity mode drive very well (there is a small delay in the 7I77s analog out but this is in the order of 150 uSec)

Sure seems like there is some slow filtering somewhere (analog in drive option?)

(analog in drive option?)

not sure what you mean Peter..........

If there is a low pass filter option on the analog input (some drives have this) this needs to be disabled

Nope .... nothing like that.
There’s a very big hammer on the workbench though.... perhaps disable the drive and all its parameters once and for all!
Looking at the traces, what surprised me was that despite turning the ball screw, the motor encoder still seems to lead the linear encoder slightly. I was expecting this to be the other way round.
Belt stretch causing a delay in the motor encoder, as the ball screw to encoder path should be more rigid. I’ve also connected a heidenhain MT25 measuring probe in place of the linear encoder.
It only has 25mm of travel, measuring the carriage movement and fed back to the 7i77. Same grating pitch as the encoder. Exactly the same traces as from the linear encoder, suggesting nothing wrong with the linear encoder setup mechanically.
I can also delay the output from the IChaus interpolator by 5ms, and i see precisely 5ms delay on the trace.

Not being up on the laws of physics, what would be considered to be an acceptable mechanical delay from beginning of ball screw rotation to feedback from the encoder?


If i dump the drives, anything you could recommend?

After reading (a little) the manual i would suggest (analyse and decide at your own risk !):

- Setup parameter 1 (MEM01) CN-01 value to BOED instead of 80EC.
Explanation:
- Servo always ON, now is becoming ON by Run Command.
- P control switch condition = NO. Instead of switching betwen PI and P based on value Cn-0C (actually torque 200%)

For a trial, in order to gain experience and simplify the system, i would suggest:
- Disconnect the belt (motor without load).
- Manually Adjusting Gain: manual section 3-7-2, be sure to follow the Gain Adjustment Flowchart.
- Test with LinuxCNC and do a PID tunning with HAL oscilloscope.

Another stab in the dark: did you use pncconf to generate your original HAL file? I has a bug with D term (it connect the encoder velocity to the PID.N.command-deriv pin instead of the PID.N.feedback-deriv pin and havoc ensues...)

I used pncconf in the hope it might help as it didnt support the 5i25/7i77 when they first arrived so had to edit an example setup.
After several weeks spotted something about command-deriv somewhere on a forum and changed as below.

Changed:
net x-vel-fb => pid.x.command-deriv
To :
net x-vel-fb => pid.x.feedback-deriv


net x-index-enable <=> pid.x.index-enable
net x-enable => pid.x.enable
net x-output => pid.x.output
net x-pos-cmd => pid.x.command
net x-vel-fb => pid.x.feedback-deriv
net x-pos-fb => pid.x.feedback

Values for drive set by auto tune.

I couldn’t arrive at “BOED ”

Delay gets much worse if bit F ... Torque FF switching is turned off.

Servo sitting on bench, no belt / no load.