PID Trainer, issue on setup

[drbitboy]

"Living is easy with eyes closed, misunderstanding all you see...." (Lennon)

What is disappointing is that I calculated the controller gains for getting a nice critically damped response and no one is trying them out.

1) Awwww

2) (**sigh**) Maybe we should change that .signature quote to "Living with delusion is easy ..." You say you read, but I am not so sure

2.1) There were a plethora of keystrokes, teeth pulling, and a long string of posts spent attempting to convert your model gains to the actual hardware setup, punctuated by miscellaneous and multiple misdirections, mislabeled graphs, and misread posts, all from from you, @Simon, our @Rock. Yes: three times (at least) you denied them .

2.2) As it turns out, Allen-Bradley seems focused more on "big industry" and less on clever entrepreneurs, and so did not have the wisdom and foresight to implement their PID instruction with floating-point metres for input PV, or floating-point Radians for output CV, or a K_C gain that is not unitless. But in the end, @MaxK and I both came up with essentially the same @geniusintraining's hardware setup-applicable gains that we were reasonably sure were equivalent to your model gains.

3) However, the results were less than satisfying, which, because we all took your model gains as truth, meant that something about the actual trainer must not be in line with the model.

3.1) So we have been exploring that since then. Maybe "The long and winding road ..." would be a better tag line

3.2) Anyway, I assume we are all fairly certain that, once the model and hardware are reconciled, either by improving the characterization* the hardware setup or by modifying the model to match the non-idealities** of the hardware, the model gains will work well.

3.3) * More on that shortly; Loop Update time is still an isssue.

3.4) ** e.g. is friction in the hardware setup significant?

3.4.1) ** We have maxed out the T_D parameter to the limit that the MicroLogix 1400 PID instruction will accept, to the point that it is physically nonsensical, yet there is no discernible phase shift between the PV and the CV, as initially noticed by @MaxK. I would hope you, of all people, would have raised an eyebrow at that. If nothing else, that shows a severe disconnect between the model and the hardware setup. So kvetching about how no one tried your Most Excellent Gains sounds rather ... well ... detached and uninformed.

4) So, bzzzzt! Thanks for playing!

4.1) Maybe go back to popcorn; perhaps the beer has addled your brains .

 

[drbitboy]

once I get caught up

LOL. I have used that phrase. For decades.

We'll wait, but won't hold our breath .

Just to recap your thought was the 0-100 scale did not have enough resolution so this will give the PLC more room to move and be more accurate?

Uhhhh, it may be that, but I'm not really sure. It does not change the arithmetic, just the aliasing and/or roundoff errors.

Also, oh dear, you have made the classic Allen-Bradley PID newbie faux pas, and the only good (or worse ?) thing is that we all gave you the benefit of the doubt: what is PLC programming about? Has no one else looked at your PDF yet? Specifically

• The values of S:22 (18) and S:35 (10), on page 12
• The meaning of the location of the unconditional PID instruction in LAD 2 on page 7
• The value of PD9:0.LUT
  • Cf. an image of the Setup Parameter dialog menu from an earlier post:
  

I have way too much time on my hands. The @Rock is too busy with his model, popcorn, and beer .

 

[MaxK]

If you have nowhere to put your energy, then here's a question for you:
Plant TF: k/s^2
Assuming the actuator speed limits, how do you think how process TF should looks like , at what point and why? (we try to find system TF poles)

 

[drbitboy]

If you have nowhere to put your energy, then here's a question for you:
Plant TF: k/s^2
Assuming the actuator speed limits, how do you think how process TF should looks like , at what point and why? (we try to find system TF poles)

I think the biggest problems are design problems, most of which do not affect the real TF:

• the scaling of the input
• the update period i.e. the actual period, not the PID instruction Loop Update Time parameter

The friction of the V-channel should be in the open-loop TF somewhere, but it's non-continuous and non-linear. I think it's a function of both CV and velocity, with a big jump near zero velocity, and an even bigger jump at zero velocity (static friction).

If it's significant, it's because of both the V i.e. the ball-channel is not a point contact, and that non-point contact creating a moment arm that can exert a torque against rolling, so certainly an obtuse angle in the channel would be a easy improvement to make, as would a surface (e.g. corner) that provided more of a point contact, either of which might get us back to where k s^-2 is a good enough approximation.

I don't know if actuator speed limits will ever be an issue, considering how long the current periods are. Maybe with reduced friction they will need to be modeled.

 

[drbitboy]

It turns out Micro Starter Lite can use the PID instruction with a physical MicroLogix 1100; there's a three year old bubble of ignorance burst and a new playground opened up!

I am pretty sure the refactored code below cleans up the LUT and input scaling problems, but should otherwise be functionally the same as @geniusintraining's code, with the following caveats: the analog inputs and outputs are different as I have no I/O modules; it will need to be retuned; the setpoint is now in the range 0-16383 (so 22% is 3604); perhaps some other issues.

 

[padees]

When I wreck in the first turn

Put it in track mode, should handle turns quite well.

I just got Mango out of winter storage, buzzed the back roads in track mode to the next town and back. Sure was fun!!!

 

[drbitboy]

Originally Posted by Dr
Did you ever try increasing the loop update time from 0.01s?

Not much of a change either way and the higher I went even the worse it got

Ha, not surprising, because you

1) didn't increase the actual loop update time (LUT) at all, so it was still 1-2ms (continuous scan cycle perid), and a factor of 5-10 smaller than the original PID parameter (P9:0.LUT). Which, by the way, is one of the fundamental misconfiguration issues in the current system. I apologize for not asking about it earlier, because (a) it's misconfiguration explains a log, and (b) it is a very common error for first time users to make (kind of the "duplicate destructive bits" poster child of PIDs).

2) probably did increase the PID parameter "Loop Update" in the dialog menu (PD9:0.LUT), but because you did not change the actual loop update time, all that did was attenuate the derivative action by skewing the calculated error rate (dE/dt) toward 0, which would effect the same change as decreasing T_D, which is why it got worse as you noted: poor rate control became no rate control.

So for anyone who has followed this thread this far (with eyes still in their sockets and not bleeding yet): all of us giving advice here (this includes you, @Rock) have done OP a huge disservice, first by blindly and blithely assuming lolis: - you know what I mean) that they scheduled their PID correctly, and then second by never challenging that assumption for over a month now rolleyes, when correct scheduling of a PID is the first and primary part of setting up PID closed-loop control. PLCs are about time and bookkeeping, and we all failed at both. Badly.

Because we very quickly had an ideal open loop model of how a device like this might respond, and @Peter Nachtwey derived reasonable gains for putting that model into a closed-loop system with a PID, well, PD, controlling the ball position. The problem was that those gains did not work on OP's system in OP's code.

When the model is correct and that happens, it is for but one reason: the chosen model does not adequately match, and instead very significantly mis-matches, the real device. That leaves two paths to follow: make the model more like the real device; make the device more like the model; both paths can be pursued simultaneously.

@MaxK first mentioned the phase shift between PV and CV a month ago, but even so it was not until a week ago, when OP finally ramped up the T_D gain, that @MaxK really brought this issue home that something was seriously wrong with OP's setup.

If you search for PID-related posts in this forum over the past two decades, or ask anyone truly facile with PLC PID instructions, you will see and hear numerous stories where a poorly scheduled PID was at least part, if not all, of the problem. @Peter Nachtwey graciously shares his wisdom here, but in his career he left PLC PID instructions behind decades ago because PLCs are too slow in time and cannot keep up with the processes Peter had to control. My brother loves to see mis-scheduled PIDs when he consults, especially when he is out of the country, because as he says "it is easy to soar like an eagle when you are surrounded by turkeys ."

This is as much to myself as anyone reading this: time; bookkeeping. Never forget the fundamentals. Burn that into your brain.

 

[Peter Nachtwey]

If you have nowhere to put your energy, then here's a question for you:
Plant TF: k/s^2
Assuming the actuator speed limits, how do you think how process TF should looks like , at what point and why? (we try to find system TF poles)

Well there is the problem and it was stated long ago. We have assumed the motor moves very quickly relative the the speed of the ball. We don't know the speed limits of the motor nor are we sure the tilt is linear with respect to the motor rotation.
This is why I suggested.


Yes, the v channel probably has friction, much more that drbitboy's slide rule. A friction term would change the transfer function to K/(s^2+d*s). Now the transfer function look a lot like that of a motor in torque mode. Now K is angular acceleration per amp or similar units. d is the damping or friction that determines how the motor will coast down to a stop.


My symbolic gains are accurate given our initial assumptions.
I can add a damping term if you like. Then it will be like auto tuning a small motor in torque mode.
https://deltamotion.com/peter/Videos/AutoTuneTest2.mp4
The motion controller saves control output and actual position every millisecond in this case. I even have feed forwards. The auto tuning can determine the true transfer function. I have NEVER see anyone calculate a true transfer function.


If the link between the motor and title angle is non-linear, we can correct for that too.
https://deltamotion.com/peter/Videos/Non-Linear-Lab_Medium.mp4
That is a student moving that system from hell. The linkage in non-linear, the mechanical advantage/gains are always changing as function of the the angle. The users specifies the motion in units of degrees, degrees/sec and degrees/sec^2. The cubic splines linearize everything. Instead of gain scheduling we use 7 splines, one each for the integral proportional, derivative, second derivative, velocity feed forward, acceleration feed forward and jerk feed forward so for every angle we know the right set of gains. You can see from the motion it is perfect. It only takes a few minutes to set this up once you know how. This is training for real world applications.
You guys have be fussing with this for how long now? Our students get 1/2 hour.



My method of calculating gains works and you can see there is no overshoot.

3) However, the results were less than satisfying, which, because we all took your model gains as truth, meant that something about the actual trainer must not be in line with the model.

The basic model of K/s^2 is correct. We agree on K. Obviously there are some design problems as you stated.

You guys aren't even sure about how to scale the system. My gains have units like (m/s^2)/rad. There are no counts. That is hidden the the back ground at setup time.

2) (**sigh**) Maybe we should change that .signature quote to "Living with delusion is easy ..." You say you read, but I am not so sure

You guys are playing around. You are flailing and failing.
We have has over 40 years of doing this for real.

2.2) As it turns out, Allen-Bradley seems focused more on "big industry" and less on clever entrepreneurs, and so did not have the wisdom and foresight to implement their PID instruction with floating-point metres for input PV, or floating-point Radians for output CV, or a KC gain that is not unitless. But in the end, @MaxK and I both came up with essentially the same @geniusintraining's hardware setup-applicable gains that we were reasonably sure were equivalent to your model gains.

Big industry has nothing to do with it. The lack of floating point has nothing to do with it. Our old RMC100 didn't have floating point. I often had to use 2 16bit words to make a long so I would have enough resolution. I had 32 bits of resolution and floating point only had a 24 bit mantissa. Sometime skill can over come. I didn't call it optimizing software. I called it agonizing software.



What is really different is that we design our trainers and everyone can they cost a lot.


This brings be back to an earlier rant. In over 40 year I have NEVER seen a mechanical system that was really designed that had a transfer function.


So now I have a question for GIT.
Can you control the angle of the beam to a precise angle?
Can you measure the acceleration of the ball for each angle?
If GIT can angle the beam to 0.1 radians then put the ball on beam at one end and measure the acceleration we might get some where. We calculated that the gain should be 4.2 (m/s^2)/rad with a 90 degree v-channel. Is it? At 0.1 radians the ball should be acceleration a 0.42 m/s^2. Is it?



We might see that the ball doesn't move at all if the v-channel is tilted only 0.01. Now we can get an idea if there is static friction and now much. Also we can get an idea of the dynamic friction if the ball does acceleration at exactly (4.2m/s^2/rad)


We design our test systems and they aren't cheap. I think we have easily over $200K may $300K in test systems. I don't know where you will find that in a lab outside of a university like MSOE but then they have our controllers.



You guys are just screwing around.

 

[drbitboy]

You guys aren't even sure about how to scale the system.

You are completely wrong and blowing smoke; check your valve cover gasket or you may start a fire (I did that. Once ).

I scaled your gains by eye to @GIT's system weeks ago; @MaxK used the trend data and got similar values to mine; the results are what convinced us summat is wrong with the device and I stopped pursuing your easy problem to actually help OP instead of kvetching from the sidelines offering nought.

I have been scaling numbers since you and I were both in short pants. I will put up my ability to multiply by unity up against anybody and everybody and I'll bet I'll be in the top 2-3% if not better (so Dunning-Krueger says I'm actually either around bottom 30% or top 0.001% ); I may not beat you at it but it will be close.

You picked the wrong !@#$ topic to ^&*+ someone off about.

 

[drbitboy]

You guys blah blah blah

1) Darn right. Do you think that is not obvious? Do you have a problem with that? It's the chase that is interesting.

1.1) For @GIT this is but a side hustle that may or may not pan out, but either way he has a business to run. Part of why it takes so long is that, while in an ideal world he would be the one posting the most with data and answering question, instead he is too busy running the business. So the rest of us ne'er-do-wells spend the spare time between theorizing, posting questions, debating and pontificating (you are the best at that last one, btw, but I suspect I'm a close second). If you can't stand the heat get the heck out of the kitchen.

2) Nothing you said is anything that I and many others here have not been thinking about for weeks as well. I doubt I thought about it before you, but I neither did we need you to bring it down the mountain on those three ... (whoops!) ... two, two tablets.

2.1) You, as well as the rest of us, failed to ask the key question that has been holding us up and that would have cracked this a month ago: how was @GIT's PID scheduled? That should have been asked in Post #2. Have a little contrition; it's good for the soul.

3) I don't need experience; this is Physics 101 and I did that nearly five decades ago. I looked up the formula for angular inertia of a shell, but I also derived it.

4) P.S. I was in Utah skiing a couple of weeks ago; that is NW-ish so I should have checked to see if you were nearby. I definitely owe you a beer or a dinner or a day skiing. You would have loved my brother; he thinks we're all a bunch of yahoos (he's been successful in engineering for five decades, and in PLCs and IA for Fortune500 companies for most of that).

 

[drbitboy]

So now I have a question for GIT.
Can ...?
Can ...?
If... Is it? At ... Is it?

That's four questions.

Man, but that bogus "you guys aren't even sure how to scale ..." malarkey really ticked me off . My gorgeous wife in the other room asked "who are you saying @#$%# to?"

 

[MaxK]

drbitboy, I won't quote you (I'm too lazy).
But please answer the question for yourself: why do you write so many letters? (How do these hundreds of letters help the topic starter?)
Are you ready to come to terms with the following definition (you indirectly gave this definition yourself):
"We're all losers, forum ranter."?
And yes, what does your brother think of us("bunch of yahoos")?
PS: I DO KNOW (realise) I will be never at Fortune500

 

[drbitboy]

But please answer the question for yourself: why do you write so many letters? (How do these hundreds of letters help the topic starter?)

The first query is something I have been thinking about a lot lately. I suppose the answers for me are "The quest for knowledge" and "Social interaction around an interesting topic."

You'll have to talk to OP about the second; I don't presume that I am any help at all, and given the breadth of my ignorance, I would not be surprised if I made things worse. But at least OP can find out how to schedule a PID now.

Why do you post?

The best thing about the internet is that it lowers the cost to publish. The worst thing about the internet is that it lowers the cost to publish. Given those boundaries (or lack thereof), does it matter what we write?

 

[drbitboy]

.RSS and PDF are in the attached .ZIP.

I added a frictionless model to the PLC program. Assign a value of 1 to B3:0/15.

Caveats

• The PID runs at 100Hz per the Loop Update parameter, not 1kHz.
• The model uses 32-bit floats, so the modeled ball may stop as much as 0.05-0.01% of scale from the SP. I could fix this, but will not as this would be too small to be visibly noticed in the physical device anyway.
• PD9:0.RG must be 1 to enter a K_C with two decimal places
• The model is uses analytical integration
• A finite speed for the servo is modeled, the default value is probably too high to have any effect, but it is adjustable.

Scaling and tuning went like this:

• sin(tilt) => CV
  • PID CV limits are 40-80% => 60% ± 20%
  • By eye estimate: the servo moves ±3/4" up or down about 6" along beam the from the pivot; (3/4) / 6 ≈ 0.125radian
  • so if 20% of 16383_CV = 0.125rad,
  • then 100% of 16383_CV = 0.625rad
• Position => PV
  • By eye estimate: the beam is about 1ft long = 0.3048m
  • Position Input Channel = IC
    • Input channel scaling is [5650:29500]_IC ≈ [0m:0.3048m]
      • 23850_IC ≈ 0.3048m
    • PV scaling is [0:16383]_PV ≈ [3000:29500]_IC
      • 16383_PV ≈ 26500_IC
• Differential equation => Open-loop transfer function
  • d²Position/dt² = 4.2 sin(tilt)
  • Multiply by various value of unity to convert Position to PID PV and sin(tilt) to PID CV, so we can calculate PID gains suitable for MicroLogix PID instruction
    • d²PV/dt² = 4.2*0.625*23850*16383/(26500*0.3048*16383) CV
  • d²PV/dt² = 7.751 CV
  • Open Loop TF: G(s) = 7.751 / s²
• CLTF
  • Cf. @Peter's PDF
• K_P, K_D
  • Try λ ~ 1:
    • K_P = 0.13
    • K_D = 0.26
• PID instruction K_C, T_D
  • K_C = K_P = 0.13
    • N.B the PID RG bit needs to be 1 (on) to assign this value in the PID Setup Screen
  • T_D = K_D / (60 K_C) = 0.03
• Performance
  • it takes maybe a handful of few seconds for the ball to move to a new setpoint
  • I don't have trending, but it does not seem to oscillate, so it's either critically- or over-damped
  • There may be some overshoot; I suspect that is due to numerical issues and limitations of the 32-bit floats (only 24 bits of mantissa).

 

[Peter Nachtwey]

I am with MaxK on this. There is to much trial and error. This thread is way too long. I can find videos on YouTube that can do this 2 dimensions easily.


I stand by my warning post #8. I know this can be done but it isn't easy and the equipment can't be cheap.
An integer only PLC is not the controller you want to use on an application like this. I have searched YouTube. Most use an Arduino. The math is not simple which disqualifies this application as a PID trainer. This warning was made in post #8. Yet drbitboy and GIT persist
I can do the math that will control the ball. So far we haven't seen that on this forum.