Mesa 7i77 and linear encoder tuning PID.

It’s mainly the start of any move. I ended up with best case scenario of 3-4 micron spike at the beginning. But then that leads you to an axis that is “optimised” for one feed rate only, and it’s awful at any other feed rate.

I sent Omron a lengthy email explaining the problem last Wednesday. Heard nothing back.

I’ve spoken to one guy on the phone in the past regarding the serial lead pin- out for the config software, he was helpful, but I don’t think he wants to get involved with this.

I’ve had enough of the drives now. I really need to replace one drive and hopefully not the servo and try something to eliminate the drive as the culprit once and for all.

The question is what with?

The Omron U series drives (rebranded Yaskawa Sigma 1 series) are, to be fair, getting on a bit, but should still be capable. I don’t have the financial resources to spend £ks on new industrial stuff and find myself at DIY CNC sites looking at “Bonmet” AC drives and the like and thinking surely these must be a step backwards. Ebay is an option but no idea what to look for.

You mentioned some drives before, Mesa I believe ...... but I think they were torque mode only?

After 30 hours of tweaking … over the weekend, I’ve drawn the conclusion that the drives are going in the bin.
In my opinion, they are un-tunable if the servo is attached to any kind of load.
I set the velocity loop in the drive as PCW suggestion.
Initially with the servo off the machine and no load. Worst following error including acceleration phase, 0.3 microns.

With their own load inertia you have a good following error.

Motor then put back on machine, and tried with same drive settings, …. massive instability / oscillation.
Set FF1=1 ….. And re-tune drive velocity loop with servo on machine.
Speed loop gain Cn-04 (Hz) – this affects the acceleration ramp.
Speed loop integration constant Cn-05 (ms) – this needs to be set to the minimum value, otherwise there is a delay before acceleration commences.
Cn-17 Torque command filter time constant (ms) - any amount of this adds significant delay before any movement of the servo. Has to be set to zero to get anything like any kind of immediate response.
So, if the last two parameters are set to minimal values, then speed loop CN04 – Gain, has to be such a low value that although the acceleration ramp begins quickly, with the minimal settings of CN05 and CN17, but is not steep enough to keep up with the demand.
Any increase, then causes instability, unless CN17 and or CN05 are increased, which adds a delay before the acceleration ramp commences..
Viscous circle.

When you attach the motor to the machine you have a higher inertia so you have to adjust Cn-04 Speed loop gain.
Page 3-40 of the manual: Cn-04 Speed loop gain adjusts the speed loop response. As the gain is increased, the servo rigidity is strengthened. The greater the inertia rate, the higher this is set. If the gain is set too high, oscillation will occur.

You could try to get out of the vicious circle with the parameter Cn-28 Compensating gain (Page 3-42) Decreases the speed loop gain by the set
value when a large torque is output due to acceleration, deceleration, etc. Increasing the compensating gain will reduce motor vibration and will also enable setting a larger speed loop gain, allowing faster positioning. Increasing the compensating gain too much will delay following accelerations/decelerations. Adjust the compensating gain only after adjusting the speed loop gain (Cn-04) and the speed loop integration constant
(Cn-05). Depending on the values of the speed loop gain (Cn-04) and the speed loop integration constant (Cn-05), the upper limit of the compensating gain may be 100 or less. An error will occur if the compensating gain is set too high. Set the compensating gain to 0 when autotuning. The gain will not be adjusted correctly if the compensating gain is not set to 0.

If you have delays you could improve the acceleration ramp reading:
Chapter 3-5-8: Torque Feed-forward Function (Speed Control with HA/LA/V/W Models).
The torque feed-forward function reduces the acceleration time by adding the value of the torque command input (TREF) to the current loop; it can be used with speed control.
• Normally a derivative value is generated in the Controller and this value is input to TREF.
• Overshooting will occur if the feed-forward amount (the voltage input to TREF) is too high, so adjust user parameter Cn-13 (the torque command scale) as required.
Note 1. If torque feed-forward is input when the motor’s rotational speed is fixed, the rotational speed won’t match the speed command. Design the Controller’s circuit so that torque feed-forward is applied only when the motor is accelerating or decelerating.

You have to use another DAC output to connect this reference. Perhaps it could be the FF2 and/or the D output of the PID, so it only acts when accelerating/decelerating, not when the speed is constant.

Cn-04 Speed loop gain adjusts the speed loop response. As the gain is increased, the servo rigidity is strengthened. The greater the inertia rate, the higher this is set. If the gain is set too high, oscillation will occur.
This was set to 130 with the motor off the machine.

I can’t set it that high with the servo on the machine without getting severe oscillations.

So if anything, i should be increasing CN-04, but cant.

If i do, then if I try to cancel out these oscillations using Cn-05 Speed loop integration constant or Cn-17, it introduces a delay

I set Cn-28 to 1 for the traces you see with the motor off the lathe, this seemed to help.

But it seems to do nothing to help when the servo is on the machine. If anything it makes matters worse.

Ok ... lets try “Chapter 3-5-8: Torque Feed-forward Function”

So, I use one of the 6 servo analogue outs connected to Tref.

I’m guessing something like:

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

net x-Torque_Feed-forward => pid.x?????????????
setp hm2_5i25.0.7i77.0.1.analogout0-scalemax [AXIS_0] Torque_Feed-forward_OUTPUT_SCALE
setp hm2_5i25.0.7i77.0.1.analogout0-minlim [AXIS_0] Torque_Feed-forward_OUTPUT_MIN_LIMIT
setp hm2_5i25.0.7i77.0.1.analogout0-maxlim [AXIS_0] Torque_Feed-forward_OUTPUT_MAX_LIMIT

net x-Torque_Feed-forward => hm2_5i25.0.7i77.0.1.analogout1

Andy

Yes PSU is integrated into drives.

This might sound really dumb but!

"Whether they end up velocity mode, torque-mode or whatever depends on how you set up the PID in HAL."

So what dictates if I’m in Velocity mode or torque mode in HAL?
I'll post both INI and HAL in a while.
As you can imagine, some of the values change hourly, such as encoder number, PID/FF, max accel ... servo / trag period

When is started out with this, I wasn’t sure if I should be using T or V mode, but could never find anything in the manual that mentions something like “MODE=VELOCITY” ... that would be far too simples

This bit ..... I do understand!

Your drives have a velocity PID loop inside the drives, but that does not seem to want to be tuned.

but ....


what dictates if I’m in Velocity mode or torque mode in HAL .......????

I would hate to think I’m wasting my time and everybody else’s trying to tune a drive to respond in velocity mode output if Linuxcnc thinks it’s in torque mode!

I set Cn-28 to 1 for the traces you see with the motor off the lathe, this seemed to help.

The range is 1 to 100, try with another values to see what happens.

Ok ... lets try “Chapter 3-5-8: Torque Feed-forward Function”
So, I use one of the 6 servo analogue outs connected to Tref.
I’m guessing something like:
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
net x-Torque_Feed-forward => pid.x?????????????

HAL connection example:
net x-torque-ff pid.x.commandDD => hm2_5i25.0.7i77.0.1.analogout1
or
net x-torque-ff pid.x.errorD => hm2_5i25.0.7i77.0.1.analogout1

setp hm2_5i25.0.7i77.0.1.analogout0-scalemax [AXIS_0] Torque_Feed-forward_OUTPUT_SCALE
setp hm2_5i25.0.7i77.0.1.analogout0-minlim [AXIS_0] Torque_Feed-forward_OUTPUT_MIN_LIMIT
setp hm2_5i25.0.7i77.0.1.analogout0-maxlim [AXIS_0] Torque_Feed-forward_OUTPUT_MAX_LIMIT
net x-Torque_Feed-forward => hm2_5i25.0.7i77.0.1.analogout1

[AXIS_0]Torque_Feed-forward_OUTPUT_SCALE must be in INI file and in this case must be analogout1 not analogout0

Manual says: loadrt pid .... debug=1. I have never used that, so check to see what happens.
pid.N.errorD float ro (only if debug=1) Derivative of error. This is the value that is multiplied by Dgain to produce the Derivative term of the output.
pid.N.commandDD float ro (only if debug=1) Second derivative of command. This is the value that is multiplied by FF2 to produce the second order feed-forward term of the output.

Connect the hal oscilloscope to check to have values only on the accelerating/decelerating phase of the move. Must be 0 during the constant velocity phase of the trajectory. If this is not OK, we have to choose another output parameter of the PID or correct them doing some mathematics.

andypugh wrote:

ROG wrote:

what dictates if I’m in Velocity mode or torque mode in HAL .......????
I would hate to think I’m wasting my time and everybody else’s trying to tune a drive to respond in velocity mode output if Linuxcnc thinks it’s in torque mode!

HAL is a Hardware Abstraction Layer. It really does not care what the numbers mean. HAL itself has no concept of the difference between the different types of control.

If you have
net vel-cmd => pid.0.command
net fb encoder.0.velocity => pid,0.feedback
then that would be a velocity control loop. In this case vel-cmd would need to be derived from a higher-level PID controller, as the LinuxCNC Motion module only outputs position commands.

My config, when it is all together will have lines like

net cmd axis.0.motor-pos-cmd => pid.0.command
net fb encoder.0.position => pid.0.feedback
net drive pid.0.output => hm2_5i23.0.8i20.0.0.current

That's a direct position-to-current loop. It might not work very well. Time will tell.

OK .... I get the subtle differences between the two.

It’s a steep learning curve, when starting from scratch, even using Linux for the first time.
I confess that I haven’t entirely grasped the concept of “net this” and “setp that” in its entirety.
I’m sure it will all just click at some point.

So, as my drives respond (supposedly) by increasing the servo rotational speed, hence velocity of the axis proportionally with the output of PID-X, which relies on velocity from the encoder, for feedback – then as far as my HAL config is concerned, that constitutes velocity mode.
(Bit of a eureka moment for me there!)