Programming best practices

[plc noob]

I am looking for Ladder programming Best Practices and Tips.

My Background is mostly AB and AD some Omron. Just looking for things to use in ladder programs that would decrease Design time and help with troubleshooting.

 

[bara_hence]

The book by Hugh Jack is a good place to start.. Like the chapter about state based design.. Really got some ahas first time I read that..

http://sites.google.com/site/automatedmanufacturingsystems/

 

[mrtweaver]

One of the things that I know has been covered in previous topics in regards to best practices, that would be COMMENT, COMMENT, COMMENT. This is in my opinion one of the best things to do, this way anytime you need to review your code for problems you can know what you did and when.

Another good thing is to continue education, you can always learn as new things come to market.

One thing that I do when writting PLC code is I first off draw up what I want using flow charts. Start with what I have, what I know, what is required, etc.. Then i start penciling in code to do what I need. And this is where the flowchart comes into play, lets say you know you need these registers, these bits, etc.. for this segment of the program. Then lets say in the line of bits you need 8, so now when I proceed to the net section of code I might start the bits at 20 this way I have unused bits in between for furture epansion and additional features that might not have been covered in the initial version.

and finally if this can and might be used in a scada or dcs setting, keep all items that can be logged grouped together.

Hope this is clear and hope it helps.

I am looking for Ladder programming Best Practices and Tips.

My Background is mostly AB and AD some Omron. Just looking for things to use in ladder programs that would decrease Design time and help with troubleshooting.

 

[(8{)} ( .)]

I agree with mrtweaver when he says COMMENT, COMMENT, COMMENT but I use a different approach when it comes to coding.

My secret is to write my comments 1st. I use either (depending on the PLC) coils that I've designated for comments or NOP instructions on what I call "Comment Rungs".

I then comment the code using pseudo code or maybe just statements like "Turn on the motor when condition x exists".
In addition, I label the comments with references from the Sequence of operation document (the doc which tells me what the code should do).

The great part of this is that once I get to the actual coding part I've done quite a bit of de-bugging on the pseudo code.

Good luck

(8{)} .)
(Yosi)

 

[plc noob]

Adding detailed comments to a program is something i learned to do the hard way.

I have been slammed by a poorly documented program on a few occasions.

I setup test bits in the program try to divide things into sensible subroutines by machine function and such.But there is always room for improvement.

Just trying to learn every trick i can

 

[TheStarr]

If you are using a tag based system, i.e. RSLogix5000, then be very discriptive with your tags. Don't just call them, bit1, bit2, etc. Never know when you might lose the copy that has the comments in it!

And always ask "What if?". Never assume that something "Can't" happen. As soon as you do, it will happen, and you will look bad.

It is easy to write a working program. Now writing a program that can handle sensor failures and odd operator inputs, that is a different story!

Also, don't try to cram everything into one rung. Break it up and write it out "long hand". Makes troubleshooting later easy and gives you more rungs to add comments on.

 

[Paullys50]

If you are using a tag based system, i.e. RSLogix5000, then be very discriptive with your tags. Don't just call them, bit1, bit2, etc. Never know when you might lose the copy that has the comments in it!

I absolutely HATE it when I see long descriptive tag names used in a program. I've seen a few programs like this and it makes the logic very "unclean", hard on the eyes and harder to find in the tag database. I've found that programmers are not always consistent when they do this, example:

Heat_Skid1_Upper_Temp => Heat_Skid02_Up_Temp

The inconstancy annoys me. I'm all for using UDTs, makes it uniform as well retains some of the descriptor.

 

[ATU]

One thing that I see is that many programmers don't get the concept of Local and Global variables. They either put all the variables in the Global area or they don't take advantage of setting up individual modules and reuse local variables and code. I have seen nearly identical stations and they keep all the code in the same module, renaming the same variables when they could have just about reused the same code and local variables by copying the code and variables into a different module. This also makes the tag names longer because they have to differentiate the same functions in the same module. If you recognize the idea of separated modules or tasks and use local variables, it can be a big time saver.

 

[plc noob]

Atu

Are these functions in contrologix? Can you provide more info.

I have never used this but sounds like a real timesaver .

Thanks

 

[ATU]

Yes RS5000 and I am sure the same applies to other systems, especially those that are tag based. In RS5000 they refer to them as routines.

I was just looking at a RS5000 program that had 8 stations done by another machine builder. They had 8 routines in one task, which is fine. But in the local tags, they had each tag prefixed with the station number. Every tag in Station 1 had (Station1_xxx..). This defeats the entire purpose of having local tags. If you wanted to copy a section of code to another module , say Station 2 that may be identical, then you would have to change all those tag names with the Station1 prefix to remove the confustion. Sure you can do Search/Replace, but why do it in the first place? It just makes the tag longer than needed and you are more likely to make a mistake doing that then just leaving it named something that reflects what it is.
Lets say you had written a routine that controlled a pick and place unit. You can create a routine to do that and set up alias for your I/O. After you get it working, you should be able to copy the entire module and local tags to another routine ,change the alias's and have about 90% of the work done.
I've never been to a Rockwell class and maybe I have it wrong, but to me it's such a simple concept, but I don't see people taking advantage of it.

 

[Andybr]

ATU
I work for a large multinational company and our standards for CLX specifically forbid the use of programme soped tags. This is not because we do not understand the concept or even see the benefits of this functionality. The reason we do not allow them is because our software standards are used by many different suppliers and historically this type of scoping has led to confusion and poor integration with our standardised SCADA systems. Good programming practice from our perspective (as end users) means following standards so that we get the same thing in every plant wherever it happens to be sited. This is something which SI's seem to have a great deal of difficulty with and the only way we seem to be able to get what we want is to specify every little detail. We do not want to stifle creativity but we have procedures for assessing and implementing changes and do not leave it up to individual programmers.

 

[ATU]

I see your point, working on projects where you have multiple programmers working together, you have to have uniformity and standards. Especially bridging across countries, I see that in some integrators. Howerver, it may also be the case that because the majority of my business is going behind programmers that don't do such a great job., that I see an unproportional amount of poor programming practices.

 

[Plastic]

I absolutely HATE it when I see long descriptive tag names used in a program. I've seen a few programs like this and it makes the logic very "unclean", hard on the eyes and harder to find in the tag database. I've found that programmers are not always consistent when they do this, example:

Heat_Skid1_Upper_Temp => Heat_Skid02_Up_Temp

The inconstancy annoys me. I'm all for using UDTs, makes it uniform as well retains some of the descriptor.

I agree Paully. I recently opened up someone elses program, and saw:
1. Long and inconsistent tag names
2. Some tags in ALL_CAPITAL_LETTERS
3. Some tage in all_lower_case_letter
4. Some tags in Mixture_of_Upper_AND_lower_case_Letter
5. No arrays used where it would be prudent
6. No UDTS where it would be prudent
This was not hard on my eyes, but hurt them, and I got a headache. I was reminded of an analogy-- If you put 20 monkeys in a room hammering away at ladder code, eventually they could come up with a ladder program that controls something.

Second issue about Controller Scoped Tags and Program Scoped Tags; There is no right or wrong way, it depends on the controlled equipment, If there are 20 like stations doing the same task, then Program Scoped tags may be the optimal choice. However, if the machine(s) is/(are) not homogenous in nature, and has a very intricate, or various selectable options, and operating conditions, there may be no merit achieve with program scoped tags. There may be no harm using program scoped tags for the latter instance, but no merit either.

There is one caveat to using program scoped tags, in the past we found that certain DDE/OPC connectivity had a hard time drilling down to program scoped tags. Admittedly, I do not know the exact cause of this anomaly, it may just have been our lack of knowledge in getting it to work, or may have been an older installation, and this may be a resolved or moot issue. We just found a quick and easy fix at that time was to make convert the tag(s) to controller scope, and got connectivity instantly.


Also, I use alot of leading zeros, when not using arrays, but discreet tags, do not use a numbering scheme like 1-99, or 1-99, or 1-999.... but instead use numbering scemes like 01-99, 001-999. Example Heat_Zone_01 and Heat_Zone_99.
RE: tag monitors are sorted alpha-numerically, and get confused and display Heat_Zone_1, Heat_Zone_10 out of logical order,, but using the leading zeros stomps on that issues.

 

[godfrey]

I think an operational description is necessary at the start. You should be able to first describe what you want to accomplish in a narrative form. In other words, tell yourself on paper what you want it to do.
A flow chart can easily be extracted and developed from that document.
All of this happens before you even open your programming software.

 

[Binaural]

I prefer to see code with the following features. Note that I come from a largely Siemens background and should be read with this bias in mind!

1. Concise variable names written in CamelCase (xxxVariableName) with a meaningful prefix that indicates the function or location of a variable. For example, inpVarname for variables connecte to a physical input, pibVarName might refer to a permit into the block from external.
2. Also where possible, I like to ensure that variable names when considered in the context of where they are located in a DB or UDT have minimal redundancy. I hate reading things like Heater002.HeatingElements.TurnOnHeatingElement1.
3. Good encapsulation of objects. For example, I like to see device blocks for processing analogue inputs include simulation and test features that don't have to be programmed specially for each project. A library of these sort of things makes implementing future projects that much easier. Device blocks in general should be capable of being "wired" to the rest of your code with minimal hassle and external logic.
4. Above the device level, I like to see standardized integer based state machine layout (there was a good thread on this a few weeks ago) written with clarity and robustness in mind,and with appropriate troubleshooting features built into the code (inhibit transitions, skip to step, minmum state time).
4. "symbol has priority" style is my preference in S7. I don't much like seeing code with loads of manual buffering placed all over the place.
5. Minimal tag interface to interface panel or SCADA. The number of tags influences the processing load the PLC must bear and also influences the cost of some packages. A well defined standard interface for tags can, depending on package, reduce development time as well.
6. Searchable links to functional specification. Where possible the functional spec should be linked to the code
7. Comments for physical inputs and ouputs should make finding them in the electrical drawings easy.
8. I can't believe nobody else has said it yet - try and use a standardized languge where possible (Ladder, FBD). Writing code in less common languages like STL, SFC or any other graphical/text language is likely to reduce the chance of being able to reuse the logic on another project, the more so since clients don't often like to buy new packages and retrain their maintenance people to troubleshoot problems late at night when support is far away.