Second-Order Control

I have an interesting problem with trying to improve upon an existing control system to control a vehicle throttle (based on speed setting) that is on a dyno that is not under our control.

After tuning the loop we are able to get +/- 0.5MPH control, but there is still some oscillation. Usually the dyno has it's own calculations to create the amount of torque seen by the vehicle based on road load, which usually takes into account the road grade, wheel friction and aero dynamics of the vehicle on the stand. This I believe will create a kind of system that we may be able to model as a spring and mass.

Anyway, has anyone here used the Second-Order Control function block in the ControlLogix to control a process? What was the improvement over the standard PID?

I am also interested in similar information, but related to the enhanced PID (PIDE) function block. Also, for the PIDE has anyone used the auto-tuning and did you find it acceptable (what type of process)?

Thanks,

Darren

OK, maybe a more direct question.

Has anyone ever used the Second-Order Control (SOC) function on a ControlLogix processor and why?

Same for the PIDE.

Darren

I could probably tell you how it works if I had the documentation.

I have RSLogix docs but it only covers ladder. What I found out is that SOC is a FBD or ST function. Why not post a link to it? I could search but why should I when you want the information.

If you want help, make it easy for others to help you.

The link to the manual that contains the instruction is located at http://literature.rockwellautomation.com/idc/groups/literature/documents/rm/1756-rm006_-en-p.pdf

I will print just that section and attach it in a minute.

Thanks,

Darren

See attached PDF

Had to break up the PIDE instruction into two PDF files.

You are breaking new ground.

Are you currently using the derivative gain?
Are you using feed forwards?

If your system is a second order system that oscillates when given a step input then this instruction may work for you. What you need to be able to do is estimate the damping factor and natural frequency of your system and then enter these values into the SOC block. It uses a technique called pole cancellation. The lag term will be necessary to filter out control signal. The SOC block is not much different in what it does than a PID block. It just provides a different, and maybe more intuitive,way of entering the gains. The SOC block will work much better if you have a high resoltion feedback device. Otherwize the output will look 'grainy' or quantized by the lack of feedback resolution. I will look into this further tonight when I get home.

Basically SOC looks not much different than a PID with a low pass filter. You should be able to do adequate velocity control with a standard PID.

There is no point is considering cascaded loops if there is only one feedback device.

Peter Nachtwey said:

Are you currently using the derivative gain?
Are you using feed forwards?

...
You should be able to do adequate velocity control with a standard PID.

Click to expand...

Yes, we are using derivative gain.
No, we are not using feed forward.

Adequate velocity control is in the eye of the beholder.

We are currently holding +/-0.5MPH which I thought was adequate, but that is not so for a particular customer.

Darren

I looked at the SOC for web tension control on a tissue rewinder a couple of years ago. The tissue web is somewhat similar to a spring - it stretches under tension and contracts when tension is released. It definitely oscillates when line speed changes.

However, I couldn't understand how to set it up and fell back on a PI with LP filter arrangement due to commissioning pressures.

It functions, but it's far from perfect. The phase lag introduced by the LP filter is somewhat counter-productive.

Gerry,

Since you used a Low Pass Filter, does that mean you used the PIDE instruction in the function block diagram? Did you attempt the auto tuning or was that even available then?

Just curious,

Darren

No, I used the PI block under the "Drives" group.

I have never used the PIDE.

An under damped second order velocity system requires a PID a OI usually will not work unless the tuning is very conservative. I dont' have the time to analyze now with my Mathcad work sheet. I agree with Gerry about the low pass filter being detrimental. That is why I suggest having higher resolution on the feedback.
I will clear things up more tonight. I have all these situations worked out, but I don't have the SOC form of transfer function. I will use a PID controlling a under dampped second order velocity system and modify it for a SOC controlling a underdamped second order velocity system. Should take about 10 to 15 minutes.

I do not know what you are considering high resolution.

The customer's dyno has 1000 pulse per revolution encoder with a 20inch diameter roll.

I usually recommend 10000.

dash said:

I do not know what you are considering high resolution.

The customer's dyno has 1000 pulse per revolution encoder with a 20inch diameter roll.

Click to expand...

A 1000 pulse encoder can give you 4x or 4000 counts per revolution. Now assume the roll is turning 1 rev per second. That is only 4000 counts per second or 4 counts per millisecond. Now some times the controller will see 4 coutns per revolution, some times 3 and some times 5. Quantizing errors are 1 counts so that is a quantizing error of 25%! That mean my speed estimations will be off by 25%.

.5 MPH is and error of 8.8 inches per second. That is high, but then your roll is 62.832 inches in circumference and at 1 rev per second your 8.8 inches per second error is only 14%.

This .5 mph error is measured over what time? The short the time period the harder is is to meet a speed specification. .5mph error is easy to meet over one second. Instantaneous velocity is hard to measure without fine resolution.

In your case one count is 62.832/4000 = .016 inches. An error of one count over one millisecond is 16 inches per second. Do you get my point? How can you control to speed resolution of 8.8 inches per second when one count gives and error twice that?

How can you use the derivative gain with such coarse resolution?
Every one complains about how difficult it is to use the derivative gain, but don't consider that poor resolution is one that that makes the derivative gain difficult to use.

Correct my assumptions.

The +/-0.5MPH error is based on looking at a graph and you see the oscillation max and min. The graph has a resolution of 50ms.

The encoder is wired into a high speed counter card that we use for determining frequency of the roll.

I'll need to check with the person that performed startup to determine if the encoder was wired to be used in quadrature mode (I do not believe that it was since they complained when I requested that they connect both channels).

I definetly see your point. From this discussion there are a few items I would like to get our programmer to look at and will post if they help out.

Thanks,

Darren

Does the counter card compute velocity or does the PLC compute the velocity based on a time difference and two positions? If the time difference is not known accurately then the compute velocity will not be calculated accurately.

Using a PLC to read high speed counters and the compute the speed is also a shakey practice. I know it is done all the time but that doesn't make it right. The question I have is what guarantees the sample times don't vary. A variation of just a few microseconds can have a large effect on the computed velocity.

Consider a 1756-M02AE. It has feed forwards that would help.