Good programming practice

[Rhonda]

jrwb4gbm: yes, good idea... simulations, even mental simulations, of how the ladder will act in abnormal conditions. I can think of a few bugs I've had to fix that were there due to me not thinking even the common abnormal cases through.

 

[Tark]

Here are a few things I have come to realized during my time of programming.

1. Think in objects. You might have a pump and this pump will have many attributes. Running, Auto Switch, Hand Switch, Failed To Start, Overload Tripped, Common Alarm.

2. Determine a naming convention and be consistent and stick to it. Nothing is worse than having multiple processors in a plant that have different naming conventions, let alone different naming conventions in the same PLC program. Also if you have HMIs in the system, think about how the naming convention will work in their programs? Will your naming convention carryover to the HMI, or vise versa?

3. Create a programming structure, again be consistent with it. Break your program up into logical blocks. I do a lot of systems for water plants so I break my programs into blocks like – Pump Logic, Valve Logic, Chemical Logic, Pump Alarms, Valve Alarms, Analog Scaling, Data Mapping, Communications, etc.

4. Document, document, document. Not only do you want to document the logic but think about documenting important information about the physical devices which are connected to the system. For instance, if you have a high pressure switch you might want to include in the program’s documentation what pressure actually trips the switch.


Terry – Modules should really be independent. If a module is independent then you can freely use that module in another program without modification. Generally what you have is a State Machine that interacts with the modules. The State Machine handles the flow control, requesting modules to perform their actions and receiving updates on those actions.

 

[Rhonda]

Oh, absolutely - I was just saying an example from a continuous process would be better for my purpose. I can see some people protesting that we aren't dealing with individual parts, and not seeing past the example to the concept presented. (I hope that's not the type I'll be presenting to, but from experience I've learned to consider that type of reaction when coming up with examples...)

If I understand your description of modularity correctly, an example of a continuous process module could be a pump, with code that monitors what's happening both upstream and downstream (via signals from those upstream and downstream modules) to determine things like the speed settings based on a tank level, pH, or some other process measurement, all provided the process upstream and downstream are also running...

 

[Terry Woods]

Forrest Gump says...

"Simple is as simple does."

I absolutely HATE the concept of KISS... especially when it really means...

"Keep It Stupid, Simple!"

My philosophy is... make ALL of your code every bit as complicated, BUT... Only As Complicated... as it really needs to be to produce the most efficient results!

After all, isn't that the real name-of-the-game? Efficiency?

Otherwise... what the hell are we being paid for??? Perhaps for nothing more than providing a fine hat-rack???

Of course, complicating the code just for the sake of complicating the code is ridiculous... and counter-productive.

However, if you need to use a complicated scheme to get the performance you need... then, by all means, do so... and then, document the living-hell out of it! And be sure to use "names" that are truely indicative of conditions IN TERMS OF THE PROCESS!

For example... There is no way in hell that "LS-1" is gonna cut it.

In terms of the process, what is the meaning of LS-1 being ON? What does it mean if LS-1 is OFF?

And... boy-oh-boy... that is only the very tip of the iceberg! What about all of the other "conceptual-conditions"?

But then again... if one is a poor programmer... and then, perhaps... that "one" is the best programmer on-site... then by all means, that "one" should... "Keep It Stupid, Simple"... for himself, and for his lessers.

I wonder how long the "Bottom-Line" can buy that attitude?

 

[Terry Woods]

Tark...

Regarding your comment about thinking in terms of "objects"... yeah, that is fine... however, isn't the particulart object you are thinking of simply a lesser part of a greater conceptual-object?

For example... how about a High-Pressure Pump (an "object", I agree) being only part of a High-Pressure System (a higher "conceptual-object", don't you see?).

The High-Pressure System is a Module in itself. The High-Pressure Pump is a Module within the High-Pressure System Module... that is... the High-Pressure Pump is nothing more than a Sub-Module within the High-Pressure System Module.

And, of course, the High-Pressure System Module is nothing more than a Module within the greater Module... perhaps the process.

"Naming Conventions"...

Maintaining a "naming convention" across any number of systems, just for the sake of maintaining a "naming convention"... might be ludicrous.

If you happen to have the same type of controller in all of your systems, with the same type of software in all of those systems, then you can get away with it... IF your convention is reasonable... that is... RATIONAL!

However, not all controllers, and not all controller softwares, are created the same.

The reason I raise this point is because, all too often, I've seen "names" that were NON-PROCESS-SPECIFIC! They simply followed the... convention, as it were. Did the names really indicate the true meaning? More often than not... no. Because they were NOT Process-Oriented... they were Convention-Oriented.

If you are gonna work on Process-A... then by God, you had better KNOW the nature of Process-A! Otherwise, what the hell are you doing at the keyboard at all???

Your comment about "Logical Blocks"... hmmm...

You are implying that ALL of your Pump Logic is in one block...
You are implying that ALL of your Valve Logic is in one block...
You are implying that ALL of your Chemical Logic is in one block...
You are implying that ALL of your Pump Alarm Logic is in one block...
You are implying that ALL of your Valve Alarm Logic is in one block...
...etc...

That is NOT Modularity in terms of the Process. That is "Grouping by Functionality".

Then you say...
"Terry – Modules should really be independent. If a module is independent then you can freely use that module in another program without modification. Generally what you have is a State Machine that interacts with the modules. The State Machine handles the flow control, requesting modules to perform their actions and receiving updates on those actions."

First of all, apparently, when YOU say module, you are really speaking about sub-routines... that would be a device-oriented routine as opposed to a process-oriented module. Unless...

Do you not understand that ALL PLCs are... ultimately... State-Machines???

That is the BASIC NATURE of PLCs! The PLC IS, BY DESIGN A STATE MACHINE!

Clearly... there is a definition problem between those newbies that are just starting their trip around the block... and those of us that have been around the block much more than a few times.

What the hell are they teaching you guys in college these days???

I think we're gonna have to try to find a way to bounce some of those teachers!

Believe me, short-cutting ain't the way to efficient programming!

 

[GIT]

My philosophy is... make ALL of your code every bit as complicated, BUT... Only As Complicated... as it really needs to be to produce the most efficient results!

After all, isn't that the real name-of-the-game? Efficiency?

The K.I.S.S. concept is a viable concept, even in your world Terry you will not be the only one that maintains your programs…Yes you should go out of you way and create a program that anyone can trouble shoot (maintain) and change (process improvements) to think that your code is the word almighty…well that’s just absurd and obnoxious

I will go out of my way and Yes even waist processor speed/memory to make the program easier to trouble shoot, I can buy a lot of RAM or get the biggest and bad-est Q06 blazing speed for 3k USD and that will be made up in the first time there is trouble and a maintenance guy opens up the program…he’s a maintenance guy…not a programmer

When you speak of efficiency and speed, look todays processors they are 100 times more efficient then they were 10 years ago…so we should be looking at stability in our programs more then efficiency.

Not trying to argue with Terry, but I just disagree with you on this.

 

[jtn]

The K.I.S.S. concept is a viable concept, even in your world Terry you will not be the only one that maintains your programs…Yes you should go out of you way and create a program that anyone can trouble shoot (maintain) and change (process improvements) to think that your code is the word almighty…well that’s just absurd and obnoxious

I will go out of my way and Yes even waist processor speed/memory to make the program easier to trouble shoot, I can buy a lot of RAM or get the biggest and bad-est Q06 blazing speed for 3k USD and that will be made up in the first time there is trouble and a maintenance guy opens up the program…he’s a maintenance guy…not a programmer

When you speak of efficiency and speed, look todays processors they are 100 times more efficient then they were 10 years ago…so we should be looking at stability in our programs more then efficiency.

Not trying to argue with Terry, but I just disagree with you on this.

I'll walk the fence on this and say that I agree with both sides. A system doesn't need to be as efficient as possible, a plant needs to make as much money as possible. There is a curve (that people above my head decide the equation for) that involves efficiency, the hourly wage of people able to to repair complicated things, prices of raw materials and energy, and a whole bunch of other stuff. Once you reach a certain efficiency it isn't cost effective to be more effecient if the extra parts made won't pay off the project within the allotted amount of time. Also, if you have to hire more expensive techs to maintain your system then there is a curve where it is worth the more expensive tech because the extra parts made are worth the payroll expense, and once you pass the peak of the curve you are paying for overkill on the payroll. The curve varies greatly from one product to another. If the raw materials are cheap and the energy consumption of the process is low there can be a fair amount waste due to a poorly tuned but cheap to maintain machine in order to maximize profits. If the raw materials are expensive or energy costs are high great pains will be made to minimize waste and the process equipment will be finely tuned in order to keep the raw material/energy cost down.

My job is to provide a system that falls properly in the curve of the particular companies operating scheme (this can be tough to do, it is much easier with a steady customer who you have a history with). If I sell them a system that requires them to call me every time it faults and has a lot of down time due to this, I won't be selling them anything else in the future! You can say that if all the bugs are worked out then there will be no need for them to call, but then the engineering time/programming time/startup time will cause the project to be too expensive and they will not get the return on their investment in their allotted amount of time - again ticking off the person that wrote the P.O. and you don't get work from them again.

The other side of the coin. You sell something to a company that needs a flexible highly tuneable system in order to minimize raw material/energy costs and your system is too simple and won't perform as needed. You won't be selling this guy anything else either.

The KISS principle applies and it doesn't. It all boils down to knowing what the customer wants and needs and when to apply how much technology. Just in the last 5 years or so have I made it a point to ask about technical abilities when scoping out a plant I am going to do work at - it's a question I should have learned to ask a long time ago.

Sorry to get off the topic of the original thread. Maybe this topic could use it's own thread? It's a highly subjective area and I would like to hear other comments on when to draw the line on technology and go with the KISS principle. I build some fairly complex machines and I also build hardwired timer/relay panels. I'll start up a thread on this soon if someone else doesn't run with it.

 

[Tark]

Terry -

Yea, maintaining naming conventions is ludicrous, that’s why millions of programmers use them, why Microsoft publishes standards, why ISA has standards. Boy how fun it would be to read a P&IDs if there were no “naming conventions”.

I’m not sure where you think I said a logical block was a module.

I understand what a state machine is, it’s a design model, it is not a piece of hardware.

As far as what I’ve been taught in school? Well, I’ve learned that there are other types of programs besides PLC programs. I’ve learned that there are other programming practices that can be applied to PLC programs. I have learned that some people have been programming PLCs for so long (or only know how to program PLCs) that they think, ‘my way is the best way’. And I also learned (back in 3rd grade) that, ain’t ain’t a word. Try using “isn’t”, then you might at least appear to be intelligent.

 

[rsdoran]

ain’t ain’t a word.

It is in the dictionary; therefore must be a word. Is it an accepted word to use, no. Facts are facts.

I will argue with Terry, been doing it for years so he is use to it.

Terry, you are just plain wrong. KISS does not imply you are stupid or that what you are doing has to be stupid, the concept is to keep it simple...a better statement would be to make it where it could be understood.

I may be the exception to the rule when it comes to the good ol boy, tobacco chewing, overall wearing, maintenance man but I do not care how godlike you think you are, how good you think you program(s) are or how you add code to an HMI for troubleshooting etc. The time may come when we have to look at the code.

I ask ya, if us good ol boys have to go to college to read your code, if/when it is necessary, then why are we maintenance men?

I knows we be undeveloped people, we just have to know how to weld/cut using torches etc, we jes have ta know numatics, hydraulics, and electricity. We gots ta be able ta paint, drywall, capenter,....

I almost left out maintaining HVAC so y'all desk jockeys can be comfortable.

On top of that weuns good ol boys gotta be able to troublehoot machines sometimes using the code the engineer created when developing that machine.

Y'all tell me what is right, use whatever code/style you want OR take the time to make the code where others, less educated but skilled, may have to read it?

 

[DDV]

Tark...

Clearly... there is a definition problem between those newbies that are just starting their trip around the block... and those of us that have been around the block much more than a few times.

What the hell are they teaching you guys in college these days???

I think we're gonna have to try to find a way to bounce some of those teachers!

Believe me, short-cutting ain't the way to efficient programming!

I also do not agree with Terry, sorry man. This would undoubtedly not concern Terry in the least, as I am what he will consider a “newbie”, not only have I not been around the block a few times, I sometimes have trouble finding the blocks, lately it was fb40 and fb41…….

But I am also a electrician who knows how irritating it is to struggle to understand a piece of code at 4 o clock in the morning.



I do not agree that code must be written for the sake of writing code as small and as complicated as possible. I think the real challenge here would be to not use the easy way out (STL, indirect addressing…etc), but rather to find a way to write the code efficiently and as user friendly as possible. I find your superior attitude regarding this matter a bit insulting. Not every one has the same abilities as you obviously do, and I think you should keep that in mind when you program as well.

 

[icky812]

Thank you to those who interpreted my meaning of KISS correctly.

Simple ≠ Stupid

Never has and never will in this context. It means making something easy to understand to the intended audience.

Definition (there are other definitions, these are the appropriate ones):

sim·ple

1. Having or composed of only one thing, element, or part. See Synonyms at pure.
2. Not involved or complicated; easy: a simple task. See Synonyms at easy.
3. Being without additions or modifications; mere: a simple “yes” or “no.”
4. Having little or no ornamentation; not embellished or adorned: a simple dress.
5. Not elaborate, elegant, or luxurious. See Synonyms at plain.
6. Unassuming or unpretentious; not affected.

Just because it is simple or easy to understand does not make it less efficient. It just means making it where that someone who doesn't have a 160 IQ can understand it.

Side story:

I wrote a good portion of ISO 9001 specs for a final testing department at a place I used to work. When I finished a procedure, I always took it to... let's call him Al. Al by his own admission wasn't the brightest match in the book, but he was great at testing and making sure the product went out the dor correct. He had trouble comprehending what he read. Again by his own addmission, if he could understand what was written, anyone who worked in the department would be able to. Consequently I ran all of the documents by him for readability. He would make notes and I would rewrite it until he understood it completely. Then I would take it to a couple of other people for proofreading. By the time the document was done I had spent more time on it than if I had just whipped it out and published it, but the benefit was anyone could understand and follow it even if they had no knowledge of the procedure beforehand.

Yes, it was a lengthier procedure. Yes, it took me longer to publish. But most importantly no one had to go find someone to ask how the procedure should be done correctly. The extra work in the beginning more than made up for all of the questions that would have come up if I had just banged it out and called it good.

 

[TimothyMoulder]

Looking over the posts, there is one fundamental element I've not seen here:

Design your program so you never have to get out a computer to troubleshoot it.

Sure, there will always be occasions you have to break out the PC (kaizen! there's one for the word-origins thread) but compose your logic with enough self-checking and clearly-written alarms to make this the great exception, not the rule.

As many have pointed out here over the years, if your cylinder has two switches, you actually have 12 faults :

Moving to forward in manual
1. Forward limit not ON
2. Return limit STUCK ON

Moving to return in manual
3. Forward limit STUCK ON
4. Return limit not ON

Moving to forward while homing
5. Forward limit not ON
6. Return limit STUCK ON

Moving to return while homing
7. Forward limit STUCK ON
8. Return limit not ON

Moving to forward while cycling
9. Forward limit not ON
10. Return limit STUCK ON

Moving to return while cycling
11. Forward limit STUCK ON
12. Return limit not ON

Each message should be distinct, and UNIQUE! Tell them not only what happened, but WHEN!

Now, in some instances this is overkill. But when a machine suddenly rips itself to pieces, and all you have is one fault indicator as a hint to what happened, do you really want to have to guess where it did it, if the same fault is re-used at 12 points in the program?

Rule of thumb - if you're not spending as much time programming faults as you are programming movements, you're not doing it right.

Somebody here said recently "Whenever my guys go out to the machine to troubleshoot it, their report must also include a plan to make sure they do not have to gou out and troubleshoot that problem again."

I love that. Whoever you are, take a bow.

TM

 

[TimothyMoulder]

As for KISS, I have a tendency to tackle programming issues by adding additional levels of complexity. My mentor recently pointed out that I was overcomplicating by a sizable margin. So, for my latest programming task, I've taken the opposite approach - instead of dealing with the issue, engineer the issue out.

My code has changed dramatically, and is much simpler and easier to follow - and write! Overall, I'm very happy with this result.

My point: Don't get too caught up in complexity OR consistency. Evaluate and adjust with every project. Don't keep bad practices simply because "that's how we've always done it". You cringe when you hear that from others - you should be embarrassed to say it yourself.

Sometimes the best way to change your arrival point is to change where you started from.

TM

 

[Rhonda]

TM: ah, yes, error handling code. I forget that sometimes - most of the programming I do (non-PLC stuff) I have the option of simply throwing a fault and ending the program, or returning an error message and not processing whatever was requested. Not so much in PLCs, I imagine...

Coming up with the faults to report, I can probably draw a parallel with the HAZOP process we have to do on our designs. Your 12 errors with two limit switches looks like it was done in a very systematic way, much like a HAZOP is supposed to be. That also ties in nicely with jrwb4gbm's comment about abnormal inputs, and with the desired plant behaviour under abnormal inputs or error/alarm conditions.

And that's a good point regarding simplicity. I'll have to think about how that can be presented in the workshop. Especially regarding maintenance - I've been told about huge complicated workarounds for issues at one of our plants, which really didn't need all that complication to be fixed properly, when looked at in a different way.

Thank you for your suggestions!

-Rhonda

 

[jtn]

One of the biggest problems I have seen with keeping documentation current is when everyone has a copy of the program on their laptop hard drive and they make changes and document. A week later someone connects up to the same processor and uploads the latest code, makes changes and documents their code but now the latest copy of the program doesn't have the documentation from the previous change. I have seen where this gets compounded over the years to become a huge problem.

One plant I work at frequently made a standard where every panel with a PLC in it was required to have an ethernet drop so that everyone could work off of the same program on the server. This helped greatly with the documentation issues.

If that is not an option then a rule of putting your changes on the server immediately after making them and also getting the latest version of the program off of the server before connecting to the PLC must be enforced. A very well documented program can go downhill quickly if everyone doesn't work off of the same copy of the program.

I would suggest bringing this up in the class. We have a standard as to where on the server the programs are, how they are named, and how to name prior versions of the program so that no one confuses an old version with the one in the processor currently.