tuning problem

Hi

I have LCNC 2.5.2, pncconf Bug is not the Problem!

Problem: Adding slightest portions of DGain (0.02 is enough!) instantly makes the axis oscillate.
PGain can be raised to 2, then it gets unstable too. DGain doesnt help at all.
IGain seems to make no difference, whether its 0 or 4?

System:

Stoeber SDS Posidyn Drive, B&R Motor, Velocity and Torque of drive tuned by raising P and I till it became stiff and not too noisy.
PGain of Velocity is pretty high (300%) but the drive is running smoothly.

Can this be a mistuned velocity loop from the drive killing the LCNC PID?

Tried 500000 and 1000000 as Cycletime, made no difference.

Help?

Its possible that low values of P are appropriate when machine units are mm but 2 seems quite low
This means full scale velocity correction occurs at a position error of 5 mm.
(assuming the output scale is the default 10V)

It may be that your velocity tuning in the drive is close to instability
(you can check by putting a step in the velocity command and checking the drives response)
Note that any D term is usually inappropriate for velocity mode drives
(the 'D' term, that is velocity feedback is what you are tuning by itself in the drive)

The main terms needed for a velocity mode drive are P, FF1 and perhaps I if low static
error is important

JT has a nice velocity mode tuning tutorial:

gnipsel.com/linuxcnc/tuning/servo.html

Thanks a lot, Yesterday I found by trial and error out what you are writing
I was concerned that this means sth is totally wrong, but you calmed me down - Thanks.

Also thanks for the link to the tuning guide. Ill try to write an article about my tunings as soon as I have some spare time.

The Axe is now tuned in a way that there is only ~0.005mm RELATIVE following error, except for accelaration phases (neg. and pos.)
There are spikes 10 times the normal following error on accell and decell phases.

BUT, the is an absolute following error that is dependent on the axis POSITION? What is that? its only +-0.01mm, but... That is much for my application...
Encoder resolution is ~8 steps per 0.01mm

As far as I understand the accell and decell spikes mean the drive itself is not well tuned?
Can this come from a Latency or filtering/lowpass?

Best regards,
julian

Sounds like you need to play with the FFx settings

FF2 should be able to help with your accel errors (probably be a very small number, a little goes a long way)

and (I'm not sure about this) FF0 might be able to help with your positional error?

Hi

Ok, Update from me:

Tuning is good, ~ +-5um while constant speed and accel/decel, up to 20m/Min

P=5
I=0
D=0.04 #less than 0.03 is unstable
BIAS = 0.0512
FF0 = 0
FF1 = 0.002421
FF2 = 0

Only bad thing left is that at the start and end of the accel/decel I have very short spikes of f-error up to 50um!
Accellaration is set to 1000mm/s*s which shall be ok for the drive, it means ~1A current, it is rated 1.5A continous.

The manual of the drive states the analog in is read each ms, => @1khz

Sometimes the spikes are 10-15um, sometimes they are 40-50um high. May this be because of Mr. Shannon and the fact that my servo thread is running twice as fast as my drive can respond?
Would it help to reduce the Servo thread to 2ms, or is this just a cosmetic solution?

The spikes are ~1-2ms wide. Ill try to send Screens tonight.

Best regards

PCW wrote:

[...]
It may be that your velocity tuning in the drive is close to instability
(you can check by putting a step in the velocity command and checking the drives response)
[...]

How can I do this, send "Steps" tho the drive?

best regards

You can use the HAL siggen component to directly drive the analog output
Normally velocity mode drives have an integral term so you should expect
some velocity overshoot from a input velocity step.

1 KHZ is pretty slow sampling, but should not be too much of a problem
for a velocity mode drive unless the velocity feedback is also sampled at
that rate (that is the errors caused by a a mS delay in sampling the
velocity command are very small, in the 1 u region at 1 M/S^2 acceleration)

In a general sense the spike problem comes from limited servo bandwidth
trying to track a profile with infinite jerk (LinuxCNCs trapezoidal motion profile)

Solutions are better servo bandwidth (though velocity command bandwidth
is not as important as velocity feedback bandwidth), or adding jerk limited motion to LinuxCNC