Been asked to review some code, looking for a sanity check with pump/valve control

Hey guys,

I've recently been asked to review some code at a water treatment plant that isn't working right; seems like sometimes it'll work, but after a good while of the programmer fiddling with things, he just isn't getting it sorted and I've been asked to come in, review the code, and determine if the code is salvageable or if it would be better to start all over.

I've spent some time with the code at this point, and I've noticed something that I wanted to get a sanity check on. The thing I noticed is how the pumps and valves are being controlled.

There don't appear to be any PID loops at all; instead, the code starts pumps/opens valves to a predetermined starting set point, and then from there starts comparing the PV to the SP. If the PV is too low, the code bumps the pump speed/valve position up 1%. Conversely, if the PV is too high, the code bumps the speed/position down 1%. It does this once per scan until the PV is within a deadband of acceptable value. Once it's there, the code compares the PV to the SP with deadband. If the PV strays outside the deadband, the speed/position is increased/reduced 0.5% until the PV is back within the tolerance. Every pump and valve is controlled in this fashion, including pumps at a remote site that vary their speed based on a flow that is at the WTP, and radio-ed down to the remote site.

On paper the concept seems novel, but I'm thinking this could be the root of the plant's woes. First off, there is nothing controlling the scan time, so these iterative steps are likely varying in timing. Second, this concept doesn't take into account deadtime for the process to respond so I could see how that could induce oscillations with constant chasing (especially with the remote pumps running to maintain flow at the WTP flowmeter which is radio-ed down). Third, and this is more general, if this was a reasonable solution then why would people bother with PID loops at all?

Something just doesn't seem right to me here, but I'd like to be able to intelligently say why. Or heck, maybe this is ok and the issue is with something else, I don't know. Basically wanted to run this by you guys who know more than me, and see what you thought. Thanks!

Very common. PID's can be far more difficult to make work nearly as well as this simple technique.

Is it really 1% per scan? That's basically ON/OFF control. If there is a timer involved in the iterations, that's a little better.

To me, that's a very crude way to control. It's basically integral-only control but always adding the same amount instead of tapering off. That might be "good enough" if the process is incredibly stable, precision is not important, and being way off during start-up is okay.

What problems are they having? Hart to say if this is causing it without knowing what the problem is.

The method of control is not uncommon...I've used it for slow moving processes where the lag is so long a PID isn't viable. However I agree with rupej, I believe you are missing something, as per scan correction on a modern processor with say a 60ms scan time, full CV from 0 to 100% would occur in 6 seconds. I can't believe that's the case, as the PV wouldn't respond that quickly, so the the control would be chattering on/off. Check again to see if the logic is in a periodic task with a set frequency of operation, or the routine doing these calcs is called periodically.

I have seen this before in packaged systems where the manufacturer doesn't send out a programmer for startup to tune the loops but instead relies on a field tech or the end user to 'tune' the loops. The thought is that PIDs are to complicated for the average Joe to understand and tune, so give them a control they can understand and tune themselves.

It sounds like your program is missing 2 or 3 settings. Generally this type of control will have a Time Base setting which determines how often to check the error, an Adjustment setting which is how much to adjust the output if there is an error, and sometimes a Deadband setting. The Deadband setting could be a value that is already set in the program or a user adjusted value. They sometimes put in a Start Position setting as well, which it sounds like the program you're look at already has.

Tark said:

I have seen this before in packaged systems where the manufacturer doesn't send out a programmer for startup to tune the loops but instead relies on a field tech or the end user to 'tune' the loops. The thought is that PIDs are to complicated for the average Joe to understand and tune, so give them a control they can understand and tune themselves.

It sounds like your program is missing 2 or 3 settings. Generally this type of control will have a Time Base setting which determines how often to check the error, an Adjustment setting which is how much to adjust the output if there is an error, and sometimes a Deadband setting. The Deadband setting could be a value that is already set in the program or a user adjusted value. They sometimes put in a Start Position setting as well, which it sounds like the program you're look at already has.

Click to expand...

I've seen this also and I agree on the missing settings. Adjusting every scan seems like chaos to me. We had an adjustable time base that would compare the SP to PV at the end of that time base. Another question is- What is the "problem" they're having? That could help determine if this setup has anything to do with it.

Hey guys,

Thanks to all who weighed in. My take-away is that this approach is reasonable *if* all proper precautions are taken for timing...and the program I'm reviewing may or may not have those precautions. I haven't examined in deep depth at this point, and it would be good for me to really hunker down and confidently understand how often this process is called. My plan now is to take a closer look and verify timing management and then work from there on how the processes are going. So I won't dismiss this approach at face value, but what I need to do is make sure the timing for function call is reasonable, and then work from there.

Thanks!

defcon.klaxon said:

Hey guys,

Thanks to all who weighed in. My take-away is that this approach is reasonable *if* all proper precautions are taken for timing...and the program I'm reviewing may or may not have those precautions. I haven't examined in deep depth at this point, and it would be good for me to really hunker down and confidently understand how often this process is called. My plan now is to take a closer look and verify timing management and then work from there on how the processes are going. So I won't dismiss this approach at face value, but what I need to do is make sure the timing for function call is reasonable, and then work from there.

Thanks!

Click to expand...

Having spent almost my entire working life in process control, in my opinion this "poor-man's" control algorithm is most often done because of a lack of understanding of PID control.

Let's be honest, this "software solution" would not have been available before PLCs emerged, and the control would have to have been executed by a stand-alone controller. Even when PLCs emerged in the 1960's there were very few (if any) that had PID control built-in, that came later, so process control was still handled by stand-alone controllers.

So, now that we have the ability to do PID control in our PLCs, I find it difficult to understand why people revert to "software solutions", that are trying to emulate what a properly tuned PID can do.

PIDs can be challenging, that's a fact, especially at "extremes", such as high speed, high accuracy, long lag times, and many other factors. However, I firmly believe any "roll-your-own" algorithm would be second-best to even a poorly-tuned PID.

Modern PIDs can also be "auto-tuned", or can even have continuous "self-tuning", which serve the vast majority of the control loops.