PLC programming standards for efficiency and ease of use

[OEMsparky]

My company makes several lines of equipment for use in the pharma industry. We use mainly AB logix5000 processor and have employed a modular style of programming for several years now which allows us to plug and play different modules depending on what options the individual machines have. We have an increasing number of complaints both internal and external customers that the code is too complex. At this time, I believe this to mean any or all of the following:
- too long overall
- too many rungs in a routine
- long/confusing tag names
- too many steps to follow when trying to trace back through a function (get lost when trying to follow the code)
- code unnecessarily blocked into several levels of add on instructions
and there are probably other complaints that don't come to mind right now.

So, I am interested in improving our code to be more efficient, easier to navigate, and perhaps to fall more inline with standards used by others. I'm looking for any references that any of you have to published standards, internal company standards that have been successful, good sets of guidelines, etc for high quality, efficient, easy to navigate PLC code.

Thanks in advance.

 

[ceac]

Have you considered that the customers do not have the qualifications to understand the code?

 

[IRstuff]

What is the purpose of the code? Was it intended to be modified by the customer?

First and foremost is DOCUMENTATION. Obviously, ample commenting for non-original programmer usage is mandatory. One possibly useful thing is an algorithm description document (ADD), which describes in mathematical or boolean terms, what the code is trying to do. Computer flow diagrams have tended to fall out of fashion, but can be useful for someone to figure out someone else's code. Alternately, Unified Modeling Language (UML) documentation can be useful if the code is particularly object oriented.

Typically, presumbably applicable to PLC code as well, modularity is a way to break up complex code into smaller, easier to digest modules.

TTFN
faq731-376

Need help writing a question or understanding a reply? forum1529

 

[tygerdawg]

What you have is a tough row to hoe. There are a couple of axioms of developing-code-for-customers that have helped me manage my customer's frustrations:
[ul]
[li]Programming power usually arrives from programming complexity.[/li]
[li]Most end-users simply aren't trained in the advanced stuff that is used to produce the complexity needed to be powerful.[/li]
[li]Most end-users are too busy getting the product out the door and are never given the time to learn deeply a particular machine's programming language or construction.[/li]
[li]Documentation is key. As my Journalist-parents taught me well at an early age, "Good writing is hard to do." The same applies to code documentation and machine function descriptions. In 35 years of machinery work, I feel confident in saying that the majority of engineers suck at it. And the majority of companies that employ and pay those same engineers to develop and ship the equipment won't give them sufficient time or training to be good at it. That's a lose-lose proposition.[/li]
[/ul]

Personally, I have been successful with short, understandable modules of code that are documented out the wazoo. It requires a lot of code-planning effort, adoption of an internal philosophy of "supportable & sustainable code for the customer" versus "elegant & efficient code for the programmer", hours punching keys and writing good 4th-Grade level descriptions, and the courage to give the Project Manager some hefty push-back if required. Couple that with patient training and setting the clear expectation that the customer must learn the content. THAT is what keeps disgruntled folks from calling me in the middle of the night. Well...mostly. But done well, they will keep coming back for more.

Good luck hoeing that row.

TygerDawg
Blue Technik LLC
Virtuoso Robotics Engineering

http://www.bluetechnik.com

 

[ceac]

One thing I consistently see in some PLC software (I am mostly using Simatic PLCs) is the hard coding of tolerances and limits in the code instead of keeping everything nice and tidy in an aptly named "XXXX CONFIGURATION" DB.

We have one of our suppliers that has a coding standard (showed to us) and after going through their standard, it becomes easy to know where to look for things next. There are no hardcoded values inside function blocks, everything is inside DBs and the names are not abbreviated to extinction and actually mean something a human can relate to.
On the other hand, another company we deal with, barely uses DBs to save configuration data and everything is hard coded inside function blocks. This makes it extremely hard to find anything as we can't cross reference for DB addresses to find the relevant code.

Just another important point to increase the readability (at least on Simatic) of code. Normally, if the development of the system is well structured, the documents mentioned by TygerDawg will already exist.
Also, alarm lists, communication tables, etc... are all pluses as a lot of the times, the customer is not interested in the software itself but from where the signals and values will be coming from.

Finally, there is a reason why you are making and selling machines... and it is the capability of making said complex code and complex functionality or complex code in "weak" hardware.

 

[djs]

Try looking at ANSI/ISA 88. It says that it pertains to batch processing, but in reality is a very good all around programming standard.