PID Tuning tool

[Peter Nachtwey]

OK, now I see that the engineering units are Hz. I like Hz over RPM too only I usually say revolutions per second or rps.

Another question I have is why does the model start at about 27 Hz instead of zero like the PV?

Also, I can see that the controller is not controlling the speed directly. There must be a drive in between the controller and the motor. In torque or current mode the torque/ angular acceleration is proportional to the current to the motor. Your system appears to be in velocity mode where the velocity is proportional to the voltage to the drive.

When tuning a motor in velocity mode we usually excite the motor with an output that looks like a W or M depending on the direction. When tuning is torque mode we output a pulse that stays on until the motor reaches a desired speed or travels a distance limit and then we must brake by outputting a negative pulse to decelerate. We usually get better performance by skipping the velocity loop inside the drive.

[moistcat]

I'm unsure why the model starts there. I think it was related to the little step in the ramp up. I believe DestinationUnknown is already working on a patch for me :P

This was just a really rushed test last week, i think i chucked the pump in manual from SCADA and hit run but changed the SP halfway or something..
Ill have a more calculated attempt next week.

Pump is being driven by a powerflex 755 with VelocityMode and AccelTime =20s. Slow ramp is so the operators can run it in manual from the drive HIM without sloshing the water around too much. I'm not too concerned about a responsive ramp up, can probably occur over 5 mins if required. I'm only expecting the system to start / stop once a day minimum.

output that looks like a W or M

So this means ramping the motor from stationary to 50Hz and back a few times? Or just between say 30-50Hz?

I come from a robot programming background so have never actually tuned a process PID loop before :P

[destination unknown]

Originally Posted by moistcat

Very interesting. Thanks for letting me know.
I have cleaned up the data but still seem to get a similar outcome:

Just to clarify, this tuner looks for a single step in CV i.e. at a timestamp it is 0 and at the next timestamp it is 30.
It works by calculating the ambient as an average of the PV before the step in CV, and as you can see it doesn't work with Ramps.

So it should work for you but try editing the data so that the CV goes from 0 direct to 30, and make sure you have the latest version of pytunelogix.

As I said this is a specific limited tuner, it's intended purpose is for tuning based on a 0-10% or 0-20% bump test/process reaction curve.

If you want an open loop Ramp Tuner, Closed loop tuner or an Adaptive Tuner you will have to open your wallet.

[destination unknown]

Would probably be best to ramp up manually to minimum flow speed, and then let the PID take over once we are within the vicinity of the pump curve.

Depends on your tolerances but generally the startup sequence is something along the lines of:

run at minimum pump speed for a period (to get stable flow)
ramp manually at a defined ramp rate
switch the PID to Auto when within controllable bounds

[Peter Nachtwey]

Originally Posted by moistcat

It is just knowing physics and the ability to act on it
Pump is being driven by a powerflex 755 with VelocityMode and AccelTime =20s. Slow ramp is so the operators can run it in manual from the drive HIM without sloshing the water around too much. I'm not too concerned about a responsive ramp up, can probably occur over 5 mins if required. I'm only expecting the system to start / stop once a day minimum.

You shouldn't use step jumps if you limit the ramp speed. The ramps will limit the response, not the physics of the motor, load and drive. The motor ramping should be disabled. If not then the excitation shouldn't ramp up any faster than what the motor ramps do. You don't want the motor ramps interfering with the auto tuning.

You need to find out why the model starts at 27 Hz. The model state should be initialized to the actual initial state. I think the 27 is a "left over" from the temperature auto tuning where the initial temperature is 27 degrees C.

The auto tuner should set the estimated state to as close to the actual state as possible. Always. destination unknown should make the initial estimated state equal to the actual initial state. This includes the PV and the rate of change in PV or PV/dt.

[destination unknown]

Originally Posted by Peter Nachtwey

You need to find out why the model starts at 27 Hz. The model state should be initialized to the actual initial state. I think the 27 is a "left over" from the temperature auto tuning where the initial temperature is 27 degrees C.

As I stated, this tuner is specifically for step/bump PRC test tuning. When used with a ramp it takes the max CV as the start of the test and hence you don't get an accurate model.
This is just a basic tuner by design...

Originally Posted by Peter Nachtwey

The auto tuner should set the estimated state to as close to the actual state as possible. Always. destination unknown should make the initial estimated state equal to the actual initial state. This includes the PV and the rate of change in PV or PV/dt.

FOPDT Adaptive:
Adaptive.jpg

SOPDT Adaptive:
SOPDT Adaptive.jpg


I was originally going to just release the Adaptive AutoTuner but most of the commercial PID tuners don't even have that. Nor do they have Live tuning and some don't have closed loop tuning. And I
So depending on interest levels, I may go down the sponsorware route and release it that way instead.

[Peter Nachtwey]

I was originally going to just release the Adaptive AutoTuner but most of the commercial PID tuners don't even have that. Nor do they have Live tuning and some don't have closed loop tuning. And I
So depending on interest levels, I may go down the sponsorware route and release it that way instead.

I think it is an good idea. You should try to get some real examples.

Originally Posted by destination unknown

This is just a basic tuner by design...

If you get some traction with your program, I would add more features or abilities.

BTW, does the program "know" it needs to update or improve the model?
The reason I ask because in one example the program makes a step change and gets to the set point but what if the system changes?
How do you know the new model better than the last?
I have some ideas.
I would keep a sum of the SSE for the last n samples. When the SSE starts to grow its time for another update. The problem is that is the system is slowly changing, then there isn't enough dynamic data to find the new and better gains and time constants.
This is the problem with RLS (recursive least squares).
The program needs to be very careful about auto updating.

[destination unknown]

Originally Posted by Peter Nachtwey

I think it is an good idea. You should try to get some real examples.


If you get some traction with your program, I would add more features or abilities.

BTW, does the program "know" it needs to update or improve the model?
The reason I ask because in one example the program makes a step change and gets to the set point but what if the system changes?
How do you know the new model better than the last?
I have some ideas.
I would keep a sum of the SSE for the last n samples. When the SSE starts to grow its time for another update. The problem is that is the system is slowly changing, then there isn't enough dynamic data to find the new and better gains and time constants.
This is the problem with RLS (recursive least squares).
The program needs to be very careful about auto updating.

Just to be crystal clear, these are completely separate tuners.
First is the pytunelogix, which is a python package for tuning via step response, and this will stay in its current form (bar bug fixes)
Second is the adaptive tuner, which can tune from any response (step, ramp, closed loop etc..)

In the Adaptive tuner, the tuner is triggered by a transition from Manual to Auto or a Setpoint Change.
Also there are constraints on the minimum time and/or minimum number of models found before updating the PID gains.

It has two modes:
passive -> which just records the models and tuning values
active -> which updates the gains on the fly.

Once at steady state the PID should be able to handle any smaller disturbances, or you could use an external trigger to re-model if there is known point of change in the system.

The minimizer handles which model to use but some supervision is required... Any further and you are verging onto MPC territory rather than PID control.

[Peter Nachtwey]

Originally Posted by destination unknown

Once at steady state the PID should be able to handle any smaller disturbances, or you could use an external trigger to re-model if there is known point of change in the system.

Using an external trigger isn't exactly automatic. Why not monitor for abrupt changes in the SSE?

The minimizer handles which model to use but some supervision is required...

If you are only considering SOPDT or FOPDT the SOPDT will always win.
There really isn't a need for the FOPDT unless you truly have a FOPDT, and you know there must be more than one time constant in the system.
You can try many models and use the one with the lowest SSE.

Any further and you are verging onto MPC territory rather than PID control.

No! Why not add feed forwards / bias instead of winding up an integrator?
The bias/feed forward would change after every change in the set point or if the ambient temperature changes. The advantage would be less integator windup or maybe none, a faster response and dead time would be less of an issue. Yes, feed forwards a way of predicting the output based on a model.

MPC is a whole different ball game. There are no controller gains and time constants, but a model is required and even more important.

Which minimizer do you use? I use Nelder-Mead for its simplicity and its ability to work without finding derivatives. My second choice is Levenberg-Marquardt. L-M works well on real data. Next comes Powell's. Others that you see mentioned are congruent gradient and BFGS. Both don't work well with real data.

When I use Nelder-Mead on the hotrod.txt data the minimum SSE is found after 764 evaluations and 452 iterations. Some iterations require 2 evaluations.

[MaxK]

Originally Posted by Peter Nachtwey

That doesn't' look right because there is no dead time. What is the SSE ( sum of squared errors ) between the actual data and your estimated data? I always print that because it tells me how good my model is.

You're right. Let's compare the numbers.

Here the models, SSE and models results for hotrod

Model:
W(s) = 3,77142857142857/ ((170,2864769*s+1)* (36,0195267*s+1)* (14,57362541*s+1)* (11,51468826*s+1))
SSE = 299,679587391752
File: HR_4OL.xls

Model:
877377,03521654*y’’’’ + 192258,238321364*y’’’ + 11483,3455339285*y’’ + 233,022931851044 *y’ + y = 3,78047288925465 * u + 76,0996287592855

Or

172,853900269076 y3’+y3 = 3,78047288925465 * u + 76,0996287592855
27,5507588534603 y2’+y2 = y3
25,3508367317336 y1’+y1 = y2
7,26743599677449 y’+y = y1

SSE = 226,249328593724
File: HR_4OL_plus_C.xls

Model:
W(s) = 3,77143 e^(- 20,2327017093169*s) / ((168,718641620594*s+1)* (43,2951553813117*s+1)
SSE = 328,620727080502
File: HR_SOPDT.xls

destination unknown post 48 model

Model:
W(s) = 3,78 e^(- 20,73*s) / ((170,861144225725*s+1)* (40,5430557742748*s+1)
SSE = 539,305857016416
File: HR_SOPDT_DU.xls


Peter, can I ask you to show the result of your model?

[MaxK]

Originally Posted by Peter Nachtwey

In reality EVERYTHING HAS A DEAD TIME!!!!
In most cases the dead time is so small it can be ignored.

When I was a student, I many times heard the same about lag

Any way All our models are approximate, nor of them are exact. The most common model mismatch is “forgetting” about the actuator.

[MaxK]

Originally Posted by destination unknown

The FOPDT and SOPDT models are used as an approximation, and in general fit a lot of systems.

The reason I show the possibility of approximation by another "type" of the model is to prevent mechanical data analysis without examining the plant.
For example: if plant include transport devices you have to know if it can change it speed, i.e. dead time, so you should make decision about your system design: to find “safest” PI parameters, or find several groups of parameters and apply them according to conditions, or something else.

Originally Posted by destination unknown

Also there are a lot of tuning rules that are based on FOPDT and SOPDT models, less so for higher order systems.

I was 99.9999% sure that I would find such an answer.
So I've got the question:
How to determine which PI controller settings are best? Or what is the PI-controller settings selection criteria?

To make it more funny, I'll attach the curves of your model with the PI settings from post 48 http://www.plctalk.net/qanda/showpos...2&postcount=48.
The response to setpoint change is pretty good(but it is not exactly) ... but what about the response to the step disturbance?

[Peter Nachtwey]

Assuming you want the SSE for the hotrod.txt data.

RMS error          =   0.436
 final_simplex: (array([[ 3.75741204,  0.68461421,  2.84927027, 77.84024028,  0.35401924],
       [ 3.75741276,  0.68461511,  2.84926905, 77.84016508,  0.35401852],
       [ 3.75741085,  0.68461181,  2.84927089, 77.84033032,  0.35402135],
       [ 3.75741199,  0.68461453,  2.84926966, 77.84023678,  0.35401922],
       [ 3.75741296,  0.68461419,  2.84927032, 77.8401676 ,  0.35401904],
       [ 3.75741189,  0.68461419,  2.84927023, 77.84025638,  0.35401937]]), array([250.31414491, 250.3141476 , 250.31414762, 250.3141638 ,
       250.31416494, 250.31416562]))
           fun: 250.31414490854445
       message: 'Optimization terminated successfully.'
          nfev: 764
           nit: 452
        status: 0
       success: True
             x: array([ 3.75741204,  0.68461421,  2.84927027, 77.84024028,  0.35401924])
The open loop gain =   3.757 PV/%CO
Time constant 0    =   0.685 minutes
Time constant 1    =   2.849 minutes
Ambient PV         =  77.840 in PV units
Dead time          =   0.354
Time units are the same as provided in input file
The closed loop time constant =   0.285
The controller gain           =   1.472 %CO/unit of error
The integrator time constant  =   3.534 minutes
The derivative time constant  =   0.552 minutes

I was using the Nelder-Mead optimizer. The "fun" is the SSE or 250.

Model:
877377,03521654*y’’’’ + 192258,238321364*y’’’ + 11483,3455339285*y’’ + 233,022931851044 *y’ + y = 3,78047288925465 * u + 76,0996287592855

Or

172,853900269076 y3’+y3 = 3,78047288925465 * u + 76,0996287592855
27,5507588534603 y2’+y2 = y3
25,3508367317336 y1’+y1 = y2
7,26743599677449 y’+y = y1

SSE = 226,249328593724
File: HR_4OL_plus_C.xls

This doesn't surprise me. You will almost always get a lower SSE if you add more derivatives. In this case you have added two so you have a forth order model. Now, what are the formulas for tuning a fourth order model? A SOPDT requires two gains. One for each poles. So there must be a P and a D gain. The integrator doesn't count because it has is own pole. Your fourth order model would require 4 gains in addition to the integrator. The derivative gains acts on the derivative of the error. You would need to have a gain that acts on the second derivative and the third derivative of the error. Calculating the third derivative accurately is a challenge. Most on this forum are lucky to calculate the first derivative without using an excess of filtering.


So how do you make use of a model that uses the fourth derivative? PLCs only have a PID so the fourth order model is useless IF USING A PLC.

I have provided the answer in a previous post on this topic.


JRW once called me arrogant. No, I can really derive the tuning equations for just about anything. I have posted the derivation for the controller gains for SOPDT many times.


What people need to realize is that everything responds as a function of exponents, sins and cosines. What gets trick is that time constants are not always constant ( I wrote and articles about that ) and gains are not constant in non-linear systems. Sometimes the models get to be more complex and linear Laplace functions are not good enough. I prefer differential equations because they can be used for almost anything.

[destination unknown]

Originally Posted by Peter Nachtwey

Using an external trigger isn't exactly automatic. Why not monitor for abrupt changes in the SSE?


If you are only considering SOPDT or FOPDT the SOPDT will always win.
There really isn't a need for the FOPDT unless you truly have a FOPDT, and you know there must be more than one time constant in the system.
You can try many models and use the one with the lowest SSE.


No! Why not add feed forwards / bias instead of winding up an integrator?
The bias/feed forward would change after every change in the set point or if the ambient temperature changes. The advantage would be less integator windup or maybe none, a faster response and dead time would be less of an issue. Yes, feed forwards a way of predicting the output based on a model.

MPC is a whole different ball game. There are no controller gains and time constants, but a model is required and even more important.

Which minimizer do you use? I use Nelder-Mead for its simplicity and its ability to work without finding derivatives. My second choice is Levenberg-Marquardt. L-M works well on real data. Next comes Powell's. Others that you see mentioned are congruent gradient and BFGS. Both don't work well with real data.

When I use Nelder-Mead on the hotrod.txt data the minimum SSE is found after 764 evaluations and 452 iterations. Some iterations require 2 evaluations.

For external trigger I mean a valve opening etc. where it is a known change in system dynamics.

If you are constantly updating the model and subsequently the gains, it's almost a sudo MPC.

There are plenty of options for future features. Nelder-Mead, it has been the most consistent.

[destination unknown]

Originally Posted by MaxK

To make it more funny, I'll attach the curves of your model with the PI settings from post 48 http://www.plctalk.net/qanda/showpos...2&postcount=48.
The response to setpoint change is pretty good(but it is not exactly) ... but what about the response to the step disturbance?

Looks like you forgot the D part of the PID tune...