Mesa 7i77 output scale
23 Jul 2013 02:21 #36909
by PCW
Replied by PCW on topic 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
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
The following user(s) said Thank You: ROG
Please Log in or Create an account to join the conversation.
23 Jul 2013 07:23 #36920
by cmorley
Replied by cmorley on topic Mesa 7i77 output scale
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
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
Please Log in or Create an account to join the conversation.
24 Jul 2013 23:47 #36997
by ROG
Replied by ROG on topic Mesa 7i77 output scale
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
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
Please Log in or Create an account to join the conversation.
25 Jul 2013 01:55 - 25 Jul 2013 01:56 #37000
by PCW
Replied by PCW on topic Mesa 7i77 output scale
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)
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)
Last edit: 25 Jul 2013 01:56 by PCW.
Please Log in or Create an account to join the conversation.
25 Jul 2013 03:13 - 25 Jul 2013 03:14 #37007
by ROG
Replied by ROG on topic Mesa 7i77 output scale
I term was a killer …. Cruise now well under a micron …..Progress report tomorrow.
I now = 0
I now = 0
Last edit: 25 Jul 2013 03:14 by ROG.
Please Log in or Create an account to join the conversation.
25 Jul 2013 23:54 #37036
by ROG
Replied by ROG on topic Mesa 7i77 output scale
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?
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?
Please Log in or Create an account to join the conversation.
26 Jul 2013 00:24 #37037
by PCW
Replied by PCW on topic Mesa 7i77 output scale
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.
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.
Please Log in or Create an account to join the conversation.
26 Jul 2013 00:50 #37038
by ROG
Replied by ROG on topic Mesa 7i77 output scale
ringing .. ? (sorry!)
Please Log in or Create an account to join the conversation.
26 Jul 2013 00:56 #37040
by PCW
Replied by PCW on topic Mesa 7i77 output scale
ringing is oscillation. There seems to be some oscillation, instability during acceleration
Please Log in or Create an account to join the conversation.
26 Jul 2013 02:49 #37042
by ROG
Replied by ROG on topic Mesa 7i77 output scale
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.
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.
Please Log in or Create an account to join the conversation.
Time to create page: 0.113 seconds