Too much error control?

So dealing with PLCs primarily as an end user where most of my work is in customizing existing processes, I spend a lot of time analyzing others work.

I was introduced to a new process that kinda shocked me in it's lack of error control. The designer wrote some really slick logic, but didn't spend much time on error control at all. This is totally atypical of what I normally deal with where the programmer builds a ton of error control in. The important point being that the base logic is so well written that things don't go wrong often, but on the rare occassion that they do, it's usually pretty ugly.

The thing is, without the excessive error control, the process just runs and runs... oh yeah, and it runs.

It just brought the question up to me, how much error control is really beneficial? Is it sometimes okay to expect the operator to have to deal with the side effects of problems as a trade-off for a low downtime process?

Sorry if this is another dull general discussion, but I'm interested in all of your takes on this.

I do custom work for the outfit I'm with, and I always include some basic error control. Motor starters that run fans, with a fan switch, etc., to an HMI, with a troublshooting screen.

It doesn't take much effort on my end, but when I turn the machine over to the other groups, manufacturing most of the time, I can almost always wash my hands of it if it has decent diagnostics. If not, I am responsible for it till someone's brought up to speed.

The number of received phone calls is inversely proportional to the amount of logic put in for diagnostics and error trapping reports to the HMI with suggestions on how to solve the problem.

I typically do controls for conveyor systems, some of which are VERY straightforward, others that involve scanners and pushers, Mezzanine levels (inclines, declines, spirals, straights etc.) I am the only PLC type in our Maintenance/Engineering Dept. so if it's a programming error, or thought to be one, I get the call. Therefore...

I use the HMI on the Control Panel as if it were the control panel for a nuke plant. I have the obvious jam points covered and motor overloads. I also will not allow conveyors around a scanner and/or pusher to operate if the scanner or pusher is not ON. I have a layout on my Panelview (of the conveyor) with indicators that light up anywhere there is a fault. The operator can then see exactly where the problem is, going right to the spot to correct the fault, minimizing downtime and phone calls. I use the Panelview for PLC related issues as well, counts per line, record hours/days, low battery, Forces On, etc. My fault screens are the most involved screens on the Panelview--but the time spent up front pays HUGE dividends down the road.

Fix 'em up Monkey, as far as I'm concerned you can't have too much Fault information (TMFI)!

Faults and alarms are fundamental to good code. If they aren't there, then you're not looking at good code however correct the main logic may seem - the finishing touches are not there.

As a minimum I would include simple alarms for common real-world failures like valves that are not switching and welded contactors etc. Depending on the application I will include a greater or lesser amount of interpretive alarms like detecting when a discharge vessel has failed to empty properly or when a gas exchanger has failed to reach an acceptable vacuum. All systems degrade in performance over time, parts break, all you can do is try and prevent excessive mucking around when this happens.

In particular, the less time operators spend in front of your equipment, the more important it is to accurately detect faults and tell the operator when problems exist. That said, making every little alarm stop the process is guaranteed to **** people off. Some alarms should stop the process, many others should not. Good code should embed some of this process knowledge.

My personal opinion is if your going to place an alarm in your code, then it's likely important enough to bring to someones attention. How better to do that then stop the process. If you dont stop the processs, then the alarm will likely just be ignored, possably letting bad product to be manufactured or whatever.

Are you asking what programmers do to handle abnormal situations such as a bad sensor or an operator entering setpoints outside of the recommended process parameters (ie trying to control to 100 degrees and the heater you have only can get you to 90).?

If this is the direction of the question then, from what I have seen in programs, generally not. I have seen and done error checking for setpoints sent down from HMI and OITs and then force the value to the max/min if outside of the range allowed. Most would let their HMI do this in the max/min scale ranges. What is interesting is that with the typical problems that could go wrong nothing ever seems to go wrong. This would not help if entering setpoints and the decimal was wrong. Some HMI/OIT devices have implied decimal places and I have seen operators enter 50 giving 5.0 instead of entering 500 and giving 50.0.

elevmike said:

...if you're going to place an alarm in your code, then it's likely important enough to bring to someones attention. How better to do that then stop the process.

Click to expand...

I would agree in a lot of cases--not all. We obviously stop any conveyors where people could be injured or products or the conveyor system could be damaged. I also stop the conveyor in certain other conditions where a neglected audible alarm could create a non-injurious situation. I think with a machine design the process would have to be machine-specific.

I am in the process of planning to install alarm signalling in the supervisor's offices. That should be popular.

The only way that you can have too much info displayed is if you can't see the forest for the trees.
I have fixed up HMI displays that when you hit an e-stop (killing control power) all failsafe alarms displayed, sometimes a hundred or so. The operator could spend hours before realizing that the guy before him hit the e-stop. The more info the better but keep the big stuff up front and tuck the rest away.
One technique is to have a Fault page that dispays general faults. (Some HMIs can be programmed to display certain pages under PLC control). It may say Primary Fault, Secondary Fault etc. Then each area of the machine is broken down into manageable slices.
Primary Fault, Bucket elevator fault (see page 07).
Direct the operator to the specific page where only status of that part of the process resides. There the bucket elevator is broken down into every conceivable component.
Page 07 is named Process A, Bucket Elevator Status
The fault is
Zero Speed, Start Spin Alarm.

Be organized and be specific.

Brian.