PID Trainer, issue on setup

[Peter Nachtwey]

i don't want to be that guy. But check out this video.

https://www.youtube.com/watch?v=K-F_T59ZDPw

I know it is not a PLC, but it is amazing none the less.

It does introduce a novel idea that may be useful to GIT. It uses a touchscreen to track ball position.

May be worth considering...

The math that goes into that is much more than basic PID. The setup also costs a lot more than what GIT wants to spend.
The plate or touch screen provides very good feed back since it provides an X and Y analog feed back that can be read very quickly.


To generate those patterns a target generator is necessary. The math for the target generator dwarfs that necessary for the PID. Also, two more gains should be added to track the target position more accurately since a PID will always lag. There should be a velocity and acceleration feed forward too. These need to be real feed forwards not just a bias . The velocity feed forward needs to be multiplied by the target velocity and the acceleration feed forward needs to be multiplied by the target acceleration. In this application the velocity feed forward gain will be low since in only compensate for the mechanical friction of the V-channel. One a flat plate the velocity feed forward should be 0.
I have symbolic formulas for the velocity feed forward and acceleration feed forward to.


The transfer function for GIT's ball and beam is almost like this spinning motor with a lot of inertia in the disk. The difference is that I am applying current which creates a torque that causes angular acceleration instead of a rolling acceleration as in GIT's example.

https://deltamotion.com/peter/Videos/AutoTuneTest2.mp4
At about 1 minute I show the calculated PID gains and velocity and acceleration feed forwards.
The whole video is only about 2 minutes long.
Tuning GIT's system could be so simple. BUT!!! This motor is a ***** to tune manually because the damping is so low. The derivative gain must be adjusted first to provide damping. Otherwise the motor will oscillate back and forth if the proportional gain is set first at any decent level. This part is not intuitive.



Now you guys know why I wasn't taking this thread too seriously.

 

[drbitboy]

​

This eliminates most of the non-linearity of acceleration wrt CV, because CV ∝ servo angle ∝ sin(θ) ∝ acceleration when θ is zero*, and away from zero the correction is

 ____________________

√(1 - (k(1-cos(θ))2)

​

where cos(θ) ≈ 1.0, so this correction is much smaller than that for articulated links.

* i.e. not approximates ∝

___

 

[drbitboy]

For anyone who follows this point, this page of the distance sensor datasheet shows a major part of the problem with the original setup: the distance input signal (voltage), and therefore also the PID's PV, are not linear with the position of the ball*.

Near the setpoint it is likely "close enough" to linear, but the non-linearity for large errors is going to be a problem for any linear-presupposing PID system model.

Linearization, or at least a rough approximation of same, of that sensor's input signal with respect to distance is trivial (a handful of RSLogix 500 rungs), of course, but this is another question I (and this thread) took far too long to ask.

* The servo arm linkage also introduces non-linearity between the PID CV (servo signal) and the restoring force sin(tilt), applied to the ball on the beam, but I doubt that is as much of a problem as the sensor.