PID Trainer, issue on setup

drbitboy said:
Note that, in the simulation, you can get away with PD only because the CV is perfect i.e. CV is θ, so a PID output CV (θ) of 0 is indeed a level channel, so it is ideal, and the output of the PD will be 0 when the ball has stopped (dE/dt = 0) at the setpoint (E = 0). In an actual system, to get an angle of 0, the PID output CV may not be 0, so either an offset bias, or its fraternal twin Integral action (accumulation), will be required.
Click to expand...
Our motion controller doesn't need a bias or will take care of that so I didn't include it. The motion controller was directly connected to the motor that turn/tilted the rail. There was no mechanical adjustments for linkage required. There are really only two things that one could get nitt picky about. I didn't model the motor response. I said why. Also, the Kp and Kd are fixed and don't change as function of angle. I ignored this because the angles don't get that big for obvious reasons.


You have to remember that I was making this simulation for college students and only one knew anything about Runge-Kutta and no one had actually used it in real application where there is a system of non-linear equations. I said that the college students eventually got the system to work using a PD control with the table tennis ball and being very conservative with the gains to keep the rail relatively level and the motion/energy low.



I did need to look up how a ball rolls down a slope without sliding but after that it was pretty straight forward, for me at least.
 
Peter Nachtwey said:
Our motion controller doesn't need a bias or will take care of that so I didn't include it.
Click to expand...


That is exactly what I said.

I took @Peter Nachtwey's PDF, and applied it in Octave (Matlab clone), based on the links here and here, wrote the script in the first attachment, then ran it in Octave (second attached image), which plotted the result.

I still think that, if a CV value of 0 does not make the beam level, there must be a bias or integral term in the PID to get the ball to be stationary at the setpoint. Consider this:

  1. Assume the beam is not level with a PID output CV of 0;
  2. Assume there is no bias or offset, external to the PID, to correct for that;
  3. With those assumptions, ...
    1. If the ball is at the setpoint position of 0, then the PID error must be 0;
    2. If the error is 0, then the P term must be 0;
    3. If the ball position is stationary (velocity is 0), then the D term must be 0;
    4. If the PID is PD-only, then Ki is 0, and the I term must always be 0;
  4. Putting that all together, ...
    1. If the ball is both stationary and at the setpoint position of 0, then the CV must be 0 (P=0 + I=0 + D=0).
    2. If the CV is 0, then the beam must not be level (cf. item 1, above)
    3. If the beam is not level, then the ball will roll away from the setpoint position of 0.
The ball would eventually end up stable at some position, but it would be at an offset from the setpoint. Also, if a PID output CV of 0 places the beam close to level, then with an actual ball on an actual beam, there might be enough friction that the ball would be stable at the setpoint position.

I am sure that the Octave code can model a CV-level offset in the P_ball = ... transfer function, but it is going to take resurrecting some neurons that have not seen voltage in decades.
balanceball_peter_plot.png​

balanceball_peter.m.source.png balanceball_peter_run.png
 
Small issue (I hope).... trends are below, different settings than yesterday, red is SP, pink is PV, white is CV

PIC 459 shows a good control and I am happy with it, PIC 616 has the same setup/settings but the PV is high and never tries to go down any further, 8 out of 10 times it will work good but every so often if will fall short or high and not try to get any better, I dont have a deadband set

Is this the issue that you guys thought would happen? I tried PD only but not very much luck

20230308_135459.jpg 20230308_135616.jpg
 
Is there noticeable backlash in the linkage?

The PID update time is 10ms; how fast does the servo respond? How well does this work if you change the Loop update time (and the STI time) to 100ms? 50ms?

With an update time of 10ms and a Ti of ~300 (seconds? minutes), I would say there is not much difference between this PID and PD.

Feed Forward in MicroLogix may have been inherited from SLCs; look in SLC manual e.g. here.

I have found in some situations that any output bias is compensated for by Integral action (eventually), but with that large Ti I don't know if that is true here.

Interesting paper here (and many others around the 'net); what I found interesting was the linkage choice made to try to make the relationship between the servo and beam angles as close to linear as possible.
 
drbitboy said:
The PID update time is 10ms;
That should be fast enough. That is what I used in my simulation but



how fast does the servo respond?
Click to expand...
This is a good question. By default, our controller responds every millisecond but it the PLC was updating only every 10 ms then the motion controller would see the input change insteps which isn't good.



How well does this work if you change the Loop update time (and the STI time) to 100ms? 50ms?
Click to expand...
That would make it worse.



With an update time of 10ms and a Ti of ~300 (seconds? minutes), I would say there is not much difference between this PID and PD.
Click to expand...
The system has too many integrators already. In my example I would thinking in terms of energy, integrating energy. With a constant tilt the energy still builds up.



I found interesting was the linkage choice made to try to make the relationship between the servo and beam angles as close to linear as possible.
Click to expand...
We do that with tiny hydraulic cylinders. This simplifies the "linkage" problem


BTW, I thought of another simplification I could make. The sin(x) is about x when the angles are small and the tilt angles are small.
Click to expand...
Click to expand...
 
Are you scaling the PV and SP to 0-100 or 0-16383? If the former then it is working with reduced resolution.

I don't think this would be the cause of the oscillations, but it would make the response noisier than it needs to be.
 
geniusintraining said:
every so often i[t] will fall short or high and not try to get any better, I dont have a deadband set
Click to expand...


I think this is because the RSLogix 500 PID does its math in integer space. The Integral action increment applied to the PID output CV from scan to scan is so small (less than 1, or maybe less than ½) that it is truncated to zero so nothing accumulates. Part of the problem may be the limited PV-SP scaling, if it is indeed 0-100.

I saw the same behavior when I was emulating a Honeywell PID several decades ago.
 
Last edited:
Peter Nachtwey said:
This is a good question. By default, our controller responds every millisecond but it the PLC was updating only every 10 ms then the motion controller would see the input change insteps which isn't good.
Click to expand...


Looking at the video and how fast the ball moves, a 100Hz update rate should be more than adequate.

That said, I wonder if this comes down to resolution again, but for the output this time: the portion of that servo's range used by that short arm does not look very large, and CV limit range is 25 (40-65), so even if it the PLC updates at 100Hz, the rate of outgoing steps (changes) may be much slower.
 
Peter Nachtwey said:
drbitboy said:
How well does this work if you change the Loop update time (and the STI time) to 100ms? 50ms?
Click to expand...
That would make it worse.
Click to expand...
Normally I would agree, but if the Loop update time is too short (it has a linear effect on the Integral action per scan) and the scaling so coarse that the integer math is truncating changes from scan to scan, then increasing the Loop update time might attenuate those issues. The ball is moving pretty slowly, so 10-20Hz might still be fast enough.
 
drbitboy said:
Is there noticeable backlash in the linkage?
Click to expand...

There was and now just a little, I will be back in the AM and work on the linkage some more but its just a little now, this is just the proto type so when I start building them I will make it tighter for sure

I did increase the Feed Forward Bias that seam to help a little

Yes I am scaling the input 0-100, I will try and removed or widening the limits on the CV to see if that helps in the AM and yes the ball is very slow, I will also make another video

Thanks for the help guys!
 
geniusintraining said:
There was and now just a little, I will be back in the AM and work on the linkage some more but its just a little now, this is just the proto type so when I start building them I will make it tighter for sure
Click to expand...


Yes, that may be part of the problem; see the video just after 0m53s: there is a sharp jerk; the whole thing rocks a bit, but what I notice is the cotter pin swinging around a bit, which tells me the pin held by that cotter pin is not tight.

Try putting a strong-ish rubber band around and compressing the linkage so lash is removed; obviously that is neither a permanent nor a marketable solution, but for now during development and testing it should provide a qualitative indication how much the backlash is contributing to any problems.

Btw, I asked The Google about table tennis rules, and @Peter Nachtwey's MathCAD PDF does indeed model regulation ping pong balls!
 
drbitboy said:
Normally I would agree, but if the Loop update time is too short (it has a linear effect on the Integral action per scan) and the scaling so coarse that the integer math is truncating changes from scan to scan, then increasing the Loop update time might attenuate those issues. The ball is moving pretty slowly, so 10-20Hz might still be fast enough.
Click to expand...
What!? No floating point! I thought I saw a floating point integrator value above.
 
Here are some ideal models. I am not implying that these tuning parameters (KP,KI,KD) are quantitatively suitable for the current trainer, but I am rather hoping that the effects of doubling or halving KP and doing the opposite to KD, or of scaling them both by a factor of ten, will be qualitatively similar to what the physical trainer responses might be, and that may provide a guide for possible direction to improve tuning. With those caveats, generally, it appears that, for this model*,

  • increasing KP and decreasing KD decreases the per-cycle attenuation of oscillations
    • i.e. more and larger oscillations
    • i.e. moving left to right in the plots below
  • increasing both gains decreases the time to the end of oscillations
    • i.e. moving top-right to bottom left in the plots below
N.B. those are independent gains.

N.B. the correlation of CV=0 to a level beam is perfect in the model, so CV will be zero when the ball's acceleration is zero generally and when the ball's velocity is 0 and not changing specifically; that is why this model can get away with neither non-zero TI nor non-zero bias; non-zero value(s) for those, or calibration of PID output CV to a level beam, will almost certainly be required by the trainer.

E.g. it looks to me that the [5,0,4] is similar to @genius intraining's current best tuning, so

  • halving KC and quadrupling TD might move the trainer's behavior toward the [2,0,8] case,
  • OR
  • increasing KC might move the trainer's behavior toward the [50,0,40] plot.
This is all pure conjecture of course; the trainer's tuning could already be the best and the actual issue is backlash.

I realize I am doing trial and error here, and poorly (changing two things at once), and that may annoy some of our dear readers: take a breath; read my .signature; move on.

* I am of course assuming that this model, based on perhaps over-simplified physics and regulation tennis balls, has some rough (i.e. within factor of 3) relationship to the trainer.
002_000_008.png 005_000_004.png
050_000_040.png 100_000_020.png
​
The final attachment is the Octave/Matlab script and model that generated these plots.
 
Last edited:
Peter Nachtwey said:
What!? No floating point! I thought I saw a floating point integrator value above.
Click to expand...
Yeah I thought the same thing, but if we look at the description of the PD (PID) data file type of, and read between the lines of, the Micrologix and SLC programming manuals, there are no floating point binary values, only bits, words, and long words; the only place decimal points show up is in some of the values displayed in the PID setup dialog of RSLogix 500. For example,

  • the Loop update time is assigned in multiples of 0.01s.
  • KC, TI, and TD, if non-zero all have available ranges of 0.01 to 327.67 if the PD structure's RG bit is 1,
    • with range limits increased by a factor of 10 for KC and TI if the RG bit is 0.
Thi divil is in thi ditils.
 

Similar Topics

Q
Recommendation for Cheap PID trainer
I have Real PLC but I dont have a real system to have PID Control- any recommendation how can I build such a system- there are some PID trainer...
Replies
6
Views
3,093
Peter Nachtwey
Peter Nachtwey
W
PID Trainer
I've built a little trainer with a Automation Direct DL05, some pilot lights, switches, a ethernet card and some of the new PX remote I\O. The PX...
Replies
7
Views
4,229
Ron Beaufort
Ron Beaufort
J
cheap dual pump water booster simulation build parts PLC VFD PID
Hi, I would like to assemble a simulator/practice booster pump system that uses PID to maintain steady water pressure under various outlet demands...
Replies
0
Views
76
JoeM61
J
C
Limit HP from Torque AI and RPM PID Output
Hello, I have a motor that we are sending a RPM Speed Output from 0-100% to the VFD. However, the Motor HP needs to be limited to 6000 HP and the...
Replies
3
Views
91
Rob...
R
T
The best way to control 48 PID temperature control
I have S7 1512C controler for controlling 48 PID temperature loop, the output is PWM. Please I need the best, most efficient way to write the...
Replies
13
Views
603
tarekrslan
T
Back
Top Bottom