PID In PLC

Some while since I've done it, things may have moved on. IIRC, the basic control algos themselves are generally fine, in fact they often run faster than the algos on common DCS systems, which can be an advantage for fast processes. Where you tend to come up short is extended configurations such as cascade, ratio and the like, the PLC environment may not handle aspects like balancing through mode switches thoroughly.

You also need to consider operating MMI, the PLC environment itself may not be comprehensive in this regard - but once again that statement may be out of date.

On Mon, 1 Jan 2007 16:28:31 +0800, "Bruce Varley" proclaimed to the world:

Don't you just hate it when your hard earned knowledge becomes just about useless once every two years.

It depends. There are many different types of PID control loops with different bandwidth requirements..

PLC PIDs are fine for processes that have time constants in the minutes. PLC PID are not good for applications that have time constants in the milliseconds as in motion control.

Some PLC PIDs are implemented poorly and shouldn't be used at all. One should write their own if they can do better. In some cases other control techniques can be used. For temperature control I would be tempted to try SMC ( sliding mode control ) first.

Peter Nachtwey

That is why one should concentrate on learning the 'forever knowledge' and not the tools. The tools that man creates change all the time. The laws of physics and math never change. As I have grown older I find that my enthusiam for learning new tools has decreased whereas I find that I will never be out of date if I know the knowledge that will is, and will forever be.

Peter Nachtwey

Hello again,

Building on the correctly said statement that "enthusiasm for learning new tools will decrease with time, whereas one will never be out of date if he knows the knowledge that is and will forever be..".

Just after I posted my question I used the magical search option .... and guess what? there were lots of topics talk about the same good old issue " Using PLC to do PID loops. I'm 100% sure that there are lots of talents here who can easily put together some sort of guidelines that clearly set the general technical criteria, if ever possible, to implement a technical acceptable PID loops using PLC technology.

Thank you for your valuable time.

messagenews: snipped-for-privacy@4ax.com...

learning the 'forever knowledge' and

...

You can implement a PID with a battery of clerks using pencil and paper if the process changes slowly enough.

Jerry

"Peter Nachtwey" schrieb im Newsbeitrag news:pP-dnYBhEbsiagTYnZ2dnUVZ snipped-for-privacy@comcast.com...

The next step is not only using PID but also using e.g. PID^5 controller because processes are always of some order of ODE.

See

That can be accomplished using programs.

Newsbeitragnews:pP-dnYBhEbsiagTYnZ2dnUVZ snipped-for-privacy@comcast.com...

The links don't make sense. The process has only zeros. How does one compute the constants a1..a5? How does one update the constants dynamically in a PLC? How does one compute s^4 and s^5 in a PLC. PLCs do not have a steady time base or the extremely high feedback required to compute the higher derivatives of the PV. One is lucky to be able to compute PV'. PV'' and higher require a another feedback device that measures rates or a very accurate model for an observer.

I don't see how this will work in a real application.

Peter Nachtwey

Hi,

Does this discussion apply to any controller platform, PLC, RTU or DCS controller or only to PLCs'? I guess what I'm a bit confused about is why thid PID implementation is questionable when PLC are the controller platform? second, is there any industry standard implementation methodology where the acceptable PID implementation for different processes is well defined?

The OP was only interesting in PLCs but warnings apply to all.

1. PLC PIDs are often implemented using only 16 bit integers. Scaling and quantizing errors are common.
2. PLC do not sample at regular intervals. There is nothing deterministic about the sampling because it depends on software. Scan time and interrupt latency causes jitter. This makes calculating PV rates of change very error prone. Good implementations sample the inputs using FPGAs where the sampling is very deterministic.
3. PLCs have analog input and output cards with long time constants and usually they don't have 16 bit resolution. Motion controllers have 16 bit resolution with over sampling in the FPGA.
4. There are many types of PID. Some applications will work best with different PIDs. Most processes will work best with I-PD where the proportional and derivative terms should be in the feed back path only. Motion controllers need to have the proportional and derivative terms in the forward path to extend the bandwidth. 5. Most PIDs do not have good implementations for the integrator term. The controller can't come out of saturation without overshooting the SP. I have had so many people tell me that an integrator must overshoot the SP to unwind and that is simply not true. If one has a integrator in a critically damped system it better not overshoot. Period.
5. PLC PID are usually meant for processes with time constants in the minutes. This is not acceptable for application with time constants in the milliseconds.

Yes, but the implementation of the standards can vary.

I don't understand what you are asking.

PLC PIDs are fine for temperature and other application with time constants in the minutes. The problem is that too many people think a PID is a PID and get into trouble when the PLC PID is used on a faster application.

Peter Nachtwey

I will believe you, because you know your stuff here.

Err, no. Perhaps "there is nothing deterministic about the sampling because it depends on poorly written software", or "there is nothing deterministic about the sampling because the author of the software didn't care" or "the level of determinism in the sampling is good for processes with minute-long time constants, but not for most motion control". I suspect that the latter statement is the most accurate, although "it was written by a naive kid and no one noticed" may also apply.

Given that the microprocessor in question has a counter that's accessible from the processor, it is pretty simple to trade off latency in the interrupt for determinism in the ADC sampling, without resorting to glue logic. One schedules one's interrupt enough before the desired sampling time to insure that one hits one's target, then one spins on the value of the counter until the sampling instant is reached, then one samples the ADC. You can sample to within one iteration of the loop that spins on the counter, which in some processors can be pretty darn short.

With the right micro controller you can set up a counter to trigger an ADC, which brings the level of determinism up to the amount of timing jitter in it's clocking circuits which will be at least as good as what you'll get from an FPGA, and more than good enough for motion control. There are plenty of modern micro controllers that can be configured to trigger a start of conversion without software intervention, and to interrupt on the ADC's end-of-conversion signal.

I have implemented sampling in critical systems using all of these methods, and they all work. Indeed, I've also implemented not-too-critical motion control where the sampling instant was determined by when a task fired off in an RTOS and had it work well. The important thing is that you must know what sort of sampling jitter your control rule demands, and either buy or make equipment that meets your requirements.

And as an old prof of mine used to say "if it ain't in the data sheet it's because they're not proud of how it behaves".

Indeed. There's a link here

to an article on the subject, which treats the effects of sampling jitter on differential action in an easy to understand way. The discussion is toward the end of the article IIRC, but the Embedded.com website is down at the moment, so I can't double check. You can also see page 166 of my book, "Applied Control Theory for Embedded Systems" for a more formal discussion (but without pretty pictures).

"Good implementations sample the input in a deterministic manner". With or without FPGAs, or even microprocessors.

An FPGA is just one (not too bad) way to do it.

And you generally need _at least_ 16 bits of resolution for good motion control. I sometimes work on a system that must be accurate to a few milliradians around a full circle, and must be precise to a few microradians. 24 bits is barely enough in that case.

The integrator must overshoot a bit if it is responding to a disturbance, but a properly designed system can easily avoid overshoot in response to a command input, even if the output hits the rail (this requires careful and clever integrator limiting, or careful and clever command scheduling, both of which are also covered in my book).

I doubt it. As Peter mentioned, there are a number of different ways of implementing PID loops, not just in the way that you arrange your feed forward, but in the ways that you compensate for system nonlinearities with nonlinearities in the controller. Given all the different combinations of plant behaviors, system requirements, sensor capabilities, actuators, and controller capabilities, there can be no one best way to do this, although if you worked at it you could probably find half a dozen good starting points.

I the the last two statements are correct.

Yes, but a PLC will not do that.

Yes, but how does a PLC update the I/O. Usually it at the beginning of the scan. In the case of the latest Rockwell controllers the I/O is updated asynchronously to the scan.

Yes, I agree but does a PLC do that? You think in terms of your experiences as an embedded processor software and hardware engineer. I think like a motion controller designer. However, I am also very familiar with PLC motion control applications that didn't work and were replaced by motion controllers..

I''ll second that.

OT. Your analysis is a good start. The effects of quantizing is as bad or worse.

Yes, but again, how does a PLC do it?

Our latest product is a FPGA with a microcontroller attached. The FPGA does the oversampling and more.

Yes .

Good, but do you think the PIDs in PLCs have this worked out? I haven't tried all the PIDs in every PLC but I have found some common PIDs to be sadly lacking.

Peter Nachtwey

-- snip --

I'm not going to refute _anything_ you say about PLCs. All of my PLC experience comes from pushing the little up and down arrows on the PLC on an environmental test chamber (while thinking that they could have done better with the control rule).

One _could_, I suppose, make a PLC that had a consistent sample interval, even using the cheesy 8051 that I assume is in nearly every one. Whether anyone who's making PLCs wants to stop ringing up new orders long enough to improve their products is another question.