PLCs and Programming Style

Good Evening, All,

Let me first apologize for this becoming something of a rant. I have a sort of a style-related question running around in my head after working today at a pumping station where I am following behind another contractor (who left the job half finished and shall remain nameless in this forum).

Here's the deal: after several days of searching for a problem with "Cooldown Cycle" logic for two diesel powered pumps, I realized that the "cooldown enable" bits for each pump were being commanded from a rung in each pump's file as OTEs, but that another file in the program (Level Control) was commanding the same bits as OTLs/OTUs based on runtime hours. (Yeah, it's an A-B - a Micrologix 1200).

I'm being vague on purpose - here's my question: Should it not be a best practice in PLC programming to use a bit as an output in ONE and ONLY ONE place in a PLC program? Isn't commanding multiple output instructions from multiple rungs addressed to the same bit address just asking for trouble when it comes to maintainability and readability of the overall program (not to mention possible program stability/operability issues this could introduce...)

The more I deal with this particular program, the more I feel like it was designed by committee, or less charitably, that it was not designed at all. I see a lot of "trick" logic that relies on quirks of the hardware to reduce scan time and memory footprint when neither of these is at issue in this application. What I don't see is any indication that the previous programmers had anything resembling a clear vision of what they would be doing with this program in ten or even twenty years.

All that said, I have managed to go through and document this mess, and at least get it doing what the customer wants. It's in my mind, though, that I should probably look at doing a total re-write after the theory of operation is well documented and defined. but part of me leans toward the "if it ain't really broke, don't fix it" direction.

So... am I right about what I think should be a best practice, or just being something of a Luddite? To those of you who managed to read this far, thanks for putting up with my ravings - I needed to rant about this somewhere...

Later On,
D

I'm being vague on purpose - here's my question: Should it not be a best practice in PLC programming to use a bit as an output in ONE and ONLY ONE place in a PLC program? Isn't commanding multiple output instructions from multiple rungs addressed to the same bit address just asking for trouble when it comes to maintainability and readability of the overall program (not to mention possible program stability/operability issues this could introduce...)

Click to expand...

Your absolutely right, its a terrible practice. Some think because they put it in a conditional subroutine they can get away with it, WRONG.

Yeah Horus, you kinda answered your own question there, friend.

For the exact thing you're going through right now, you should never use an OTE on more than one rung in a program. If it's been done once, by the way, it may have been done again elsewhere with other bits. A few minutes with "Find All" may cause you less downtime in the future, depending on your time and the size of the program. Catching those issues NOW while you're up and running can save production time in the future.

Also, I would never really be afraid to start from scratch IF there were time to do it and debug/test safely. I've spent several weekends in my career re-writing a program "my way" and for a variety of reasons.

Rube said:

Yeah Horus, you kinda answered your own question there, friend.

For the exact thing you're going through right now, you should never use an OTE on more than one rung in a program. If it's been done once, by the way, it may have been done again elsewhere with other bits. A few minutes with "Find All" may cause you less downtime in the future, depending on your time and the size of the program. Catching those issues NOW while you're up and running can save production time in the future.

Also, I would never really be afraid to start from scratch IF there were time to do it and debug/test safely. I've spent several weekends in my career re-writing a program "my way" and for a variety of reasons.

Click to expand...

Yeah, I know what you mean. The more I think about it, the more I'm inclined to do this, just for my own peace of mind. This pump station controls level in a man-made lake that acts as a drainage containment for water from storm and rain runoff - it's a part of the flood control and hurricane protection plan for its area of operation.

If the customer is not inclined to allow me the time to do it, I'll probably do it on my own anyway, just to gain a better understanding of what's there. The program isn't really all that big, but it does sprawl out across several "files" for organizational purposes - the original programmer got that much right, at least, before he dragged up and a more junior man from the same company took over the project. I'm the third or fourth guy to be looking at this beastie. It's possible that the second reference in this case was an honest mistake made by one of my predecessors...

And, yeah, I'll be doing a thorough perusal of the cross-reference after it is up to date to make sure this hasn't happened elsewhere. You're quite right about what's happened once could have very well happened more than once.

Is there anything resembling a "style guide" for PLC Programmers anywhere? I've seen some good info here, but don't see any evolving standards that might make it easier on a guy building a system from scratch. I've done a few small jobs on my own (some chicken houses and other agricultural automation stuff) and have made out well on all of those, so I know I'm doing something right... my customers seem happy, anyway. I just wonder if I could maybe be doing better.

Thanks for confirming what I already suspected was true. That it's actually possible to do this in the software when it's such a bad idea is mildly surprising to me, but I guess "with great power comes great responsibility". Heh.

I've seen all kinds of programming and I'm sure there are more kinds out there that I haven't seen. Some are easy to follow and simply elegant and others leave you thinking "WTF".

I subscribe to the KISS and label everything approach. As you well know, you are not the only poor slob that's gonna have to figure the program out. I've seen programs that did in 25 rungs what could've been done in 18. Balance the cute and the elegance out and you're likely on the right track.

And a high percentage of programs are straight-forward. They just get the job done. No bells, whistles etc. You read the program and you instantly know what's going on. Small machine and conveyor programs are usually like this. Other programs are slimmed down as much as possible yet it takes a minute to see what's going on. Batches and data handling programs can be like this.

One place I ususally spend a lot of time is in safety and alarm monitoring. The time I spend on this programming will likely save MORE time down the road. I always have an HMI on my systems now--it makes no sense not to.

Label your wires in a panel (and to field devices) and label your bits in a program. Period. Wanna know how long it takes to weed through a program with little or no labelling? Download a program into any RSLogix (or similar) without the .RSS file...

That'll get your attention.

Rube said:

I've seen all kinds of programming and I'm sure there are more kinds out there that I haven't seen. Some are easy to follow and simply elegant and others leave you thinking "WTF".

I subscribe to the KISS and label everything approach. As you well know, you are not the only poor slob that's gonna have to figure the program out. I've seen programs that did in 25 rungs what could've been done in 18. Balance the cute and the elegance out and you're likely on the right track.

And a high percentage of programs are straight-forward. They just get the job done. No bells, whistles etc. You read the program and you instantly know what's going on. Small machine and conveyor programs are usually like this. Other programs are slimmed down as much as possible yet it takes a minute to see what's going on. Batches and data handling programs can be like this.

One place I ususally spend a lot of time is in safety and alarm monitoring. The time I spend on this programming will likely save MORE time down the road. I always have an HMI on my systems now--it makes no sense not to.

Label your wires in a panel (and to field devices) and label your bits in a program. Period. Wanna know how long it takes to weed through a program with little or no labelling? Download a program into any RSLogix (or similar) without the .RSS file...

That'll get your attention.

Click to expand...

You're definitely preachin' to the choir here, man. I learned early on in my career that labelings and nomenclatures are at least as important as getting the thing working. I guess that's why I've been tapped to do a lot of this kind of work (retrofits, upgrades, debug) as I've gotten older. This particular time was the first one where the mistakes have been of this type, and I thought maybe I was behind the times on some new programming style or something (technology marches on...). It was reassuring to know there are guys out there who think the same way I do.

What HMI software do you favor, if I might ask. I'm not to keen on RSView ME, really. Seems like there ought to be a better way to skin the cat for small projects.

Later On,
D

horus said:

What HMI software do you favor, if I might ask.

Click to expand...

Okay; I'll dive into this pool (which will surely have gators in it soon I expect).

I have worked with only the following: AB Panelview, Red Lion G3, Total Control, Wonderware, and a couple of other smaller units.

For the money, Red Lion has the best comms and abilities. There may be others that have similar bang for the buck but I haven't used them and likely won't. Red Lion has impressed me and I see no need to go anywhere else if the customer doesn't require me to. I have some issues with Crimson software but I can get by with those issues (so I haven't griped about it in the "Make Red Lion better" thread). Also, and this is big, the customer support from Mike and his guys, not to mention Joe Wazoo locally, is best in business as far as I'm concerned.

Wonderware costs too dang much but it has a lot of capabilities.

I like Panelviews and their abilities and if AB would ever get the price down and expand the comms capabilities on these units I would return to using them. AB if expensive--every item that has AB on it costs too much. Run a room full of AB types to me and I'll show them how I know. Having said that, I'll continue to use their PLCs

Go with Red Lion's 10" or 15" units and learn Crimson 3 if you're tired of PV and RSView.

Rube said:

Okay; I'll dive into this pool (which will surely have gators in it soon I expect).

I have worked with only the following: AB Panelview, Red Lion G3, Total Control, Wonderware, and a couple of other smaller units.

For the money, Red Lion has the best comms and abilities. There may be others that have similar bang for the buck but I haven't used them and likely won't. Red Lion has impressed me and I see no need to go anywhere else if the customer doesn't require me to. I have some issues with Crimson software but I can get by with those issues (so I haven't griped about it in the "Make Red Lion better" thread). Also, and this is big, the customer support from Mike and his guys, not to mention Joe Wazoo locally, is best in business as far as I'm concerned.

Wonderware costs too dang much but it has a lot of capabilities.

I like Panelviews and their abilities and if AB would ever get the price down and expand the comms capabilities on these units I would return to using them. AB if expensive--every item that has AB on it costs too much. Run a room full of AB types to me and I'll show them how I know. Having said that, I'll continue to use their PLCs

Go with Red Lion's 10" or 15" units and learn Crimson 3 if you're tired of PV and RSView.

Click to expand...

Huh. I've used Red Lion's hardware for years and didn't realize that they had a line of HMI devices... I'll definitely give them a look. Thanks!

I've played with Wonderware myself a time or two, but not to any real depth - enough to figure out that I pretty much agree with you about it, though. For most of what I'm doing it's too expensive.

I'm looking now at some units put out by EZ Automation which feature self-contained HMI development software in the touchpanel itself (some of them even incorporate a small modular PLC in the touchpanel on the back...) I may even go as far as buying one of these to play around with.

But getting back to Red Lion: sounds like you really like how they work. Thanks again for putting me onto what sounds like yet another great product from a company I already trust.

Speaking of gators, though, we just had to have several removed from that lake I spoke of earlier. The largest was a female some six feet long, and there were several smaller juveniles. That was a fun evolution!

Later On,
D

You'll find it easy to make the move from the PVs to the RL units. My only beef with the Crimson software is the lack of ability to edit tags from ContolLogix in the Crimson itself.

My suggestion is to readdress the OTL/OTU to an auxiliary contact, and wire that to the OTE rung.

I've taken to use only OTE for control, and OTL/OTU for flags. Whatever acts on a set flag resets it.

I've come across programs where the original programmer loved OTL/OTU, sprinkled them all over the place in separate files. Probably for job security since the practice makes the whole thing virtually untraceable without a lot of hard work.

ydtech said:

My suggestion is to readdress the OTL/OTU to an auxiliary contact, and wire that to the OTE rung.

I've taken to use only OTE for control, and OTL/OTU for flags. Whatever acts on a set flag resets it.

I've come across programs where the original programmer loved OTL/OTU, sprinkled them all over the place in separate files. Probably for job security since the practice makes the whole thing virtually untraceable without a lot of hard work.

Click to expand...

I'm not sure I agree with what you are saying about "flags"- are you introducing a layer of abstraction in your programs just to make them easier to follow, or do you actually use the latch "flags" to transmit bit data to an HMI for alarming, messaging or other purposes? (I could kinda see that, but not really.) There's no need to make the program more complex than it needs to be, especially if dealing with a small unit like a MicroLogix or a DL-05/06.

OTL/OTU instructions in and of themselves are not a bad thing - they simulate the operation of old-style latching relays in a ladder. What I agree with you about is this: what is a bad idea, in my opinion, is not programming the latch and unlatch conditions close to each other in the ladder. When the conditions for latch and unlatch are many rungs distant from each other it makes the program less readable and more of a pain to troubleshoot because you wind up having to flip back and forth between them to suss out all the states. I've never seen a program where that is truly necessary, either. (O' course, as soon as I say that someone will prove me wrong!)

These are the kinds of things I was getting at by use of the term "programming style" - those little details that make a program so much more intelligible to the humans who have to figure it out when the manure impacts the rotary ventilating device.

I'll stop for now... or this'll turn into War & Peace... I'm gabby that way.

horus said:

I'm not sure I agree with what you are saying about "flags"- are you introducing a layer of abstraction in your programs just to make them easier to follow, or do you actually use the latch "flags" to transmit bit data to an HMI for alarming, messaging or other purposes? (I could kinda see that, but not really.) There's no need to make the program more complex than it needs to be, especially if dealing with a small unit like a MicroLogix or a DL-05/06.

OTL/OTU instructions in and of themselves are not a bad thing - they simulate the operation of old-style latching relays in a ladder. What I agree with you about is this: what is a bad idea, in my opinion, is not programming the latch and unlatch conditions close to each other in the ladder. When the conditions for latch and unlatch are many rungs distant from each other it makes the program less readable and more of a pain to troubleshoot because you wind up having to flip back and forth between them to suss out all the states. I've never seen a program where that is truly necessary, either. (O' course, as soon as I say that someone will prove me wrong!)

These are the kinds of things I was getting at by use of the term "programming style" - those little details that make a program so much more intelligible to the humans who have to figure it out when the manure impacts the rotary ventilating device.

I'll stop for now... or this'll turn into War & Peace... I'm gabby that way.

Click to expand...

I think what ydtech is saying is that you use the OTL/OTU only to pass state info around your program. You use only OTE, however, to run the equipment connected to the PLC. This means... that somebody can turn it off if there's a problem!

Yeah, I used to have a couple of cells that my predecessor programmed using OTL/OTU whenever he couldn't really get the logic to work. Sometimes he'd have two of one, and one of the other just for extra enjoyment! Whenever there was an equipment problem, or sometimes certain combinations of operator actions, the "OTU Moment" would pass and the cell would be in limbo. There was no reset or clear to take the logic back to a zero state. I would take the laptop and spend an hour or so matching the logic to whatever state the cell happened to be in, then eventually get it running. Then, it would usually take a pass through the cell to really synch everything up again.

To be fair to the guy, it did usually work. It was just that troubleshooting was tedious (program documentation was pretty minimal... LOL!) and there was no way to reset anything and restart if there was any kind of a problem. Hell, there was no way to run anything manually and even test the hardware to see if there was a problem!

I use integers as flags, altho I have thought more than once thought that I could use OTU/OTL for that purpose. I like integers though, because I can have a multi-value flag if need be and because I can clear them all with a fill command. I also cheat and even though they're integers, I generally only use 1, 2, 4, etc so that can write it as a number, but then examine it later as a bit. For motion, I sometimes get tricky and use 3, 5, 9, etc. with the LSB indicating that, say, an axis position is valid and the higher bit indicating the actual position the axis is in (for axes that move only to indexed positions).

Yes, mainly for abstraction and messaging between routines and sometimes even rungs in the same routine. A lot of my jobs involve states and transitions and I like to keep that part of the program as clean as possible.

As an example, there may be several operator message flags set by different routines, the message routine sends them one at a time, clears the flag as it's acknowledged and sends the next in case there are any. If not, everyone is happy and life goes on.

I think what ydtech is saying is that you use the OTL/OTU only to pass state info around your program. You use only OTE, however, to run the equipment connected to the PLC. This means... that somebody can turn it off if there's a problem!

Click to expand...

Exactly.

I find that using words like NEVER or ALWAYS when talking about programming can get you into trouble.

I've used OTL/OTU in a program multiple times without problems. There are reasons that this might be done and it doesn't make it wrong.

The real problem is that the tech/engineer should document what is being done and the person troubleshooting should be able to find those commments.

brucechase said:

I find that using words like NEVER or ALWAYS when talking about programming can get you into trouble.

I've used OTL/OTU in a program multiple times without problems. There are reasons that this might be done and it doesn't make it wrong.

The real problem is that the tech/engineer should document what is being done and the person troubleshooting should be able to find those commments.

Click to expand...

Amen, Brother! Lemme hear ya preach it!

As for OTL/OTU: as I said earlier, these instructions simulate the operation of latching relays. Once the programmer understands that for every latch there must be an equal and opposite unlatch, using them for controlling outputs/end devices is certainly not wrong. Now, if you want to use OTL/OTU pairs to convey states only, that's a matter of style and it's not wrong either. Clarity, consistency, and good organizational structure are what's important. (Well... it's also nice if the darned thing works as it's supposed to.)

(I see a lot of OTUs used in this program I am currently debugging that do not have corresponding OTLs - I'm beginning to suspect that these are for the HMI's benefit? They invariably toggle bit addresses or bits sliced out of integer words.)

Gotta go... Turkey Day is gonna start early. Gobble, gobble, y'all!

Later ON,
D