PLC code standards

S

Thread Starter

Stephen Wright

I am a controls engineer working in support of a mid-sized manufacturing plant. At this plant we purchase a variety of special machines from a variety of vendors. Generally these machine controls take care of themselves. However when I need to solve a process problem with one of
these machines I am always forced to understand the programming style of each.

Is there a way I can direct my vendors to a more standard, widely accepted programming style? I myself am guilty of some individual programming idiosyncracies, but is there a way I could point myself and my suppliers to a more universal approach without compromising originality?
 
C

Curt Wuollet

A software spec. and sign off?
If it's reasonable it shouldn't raise costs too much. Making your needs definite up front as part of the sales agreement is usually the best way.

Regards
cww
 
D
Stephen,
I have a document that I wrote some years ago, probably needs updating, but will probably suffice for vendors. E-Mail me at [email protected] and I can forward a copy to you.

Dale
 
M

Michael Griffin

There is no single universally accepted approach to programming PLCs. The fact that when left to themselves every supplier does it a different way
shows that.

What you can do is to write a programming guideline which shows how you would like things done. Send out a copy of the guideliine (preferably in PDF format) with each request for quotation so that each supplier knows you are
asking for this before they submit a quote.

The guideline should be broken down into functional areas such as mode transfers, alarming, sequential control, parameter editing, etc. for whatever it is you are trying to specify. If you would like to block out areas of
memory for particular uses, then describe those as well.

The guideline should be written with actual code examples to illustrate each point. It is important though to include an explanation of why you would like things done that way, rather than just show something and say "do this". The person who is writing a program using your guideline will need to understand your intent in order to comply with your general objective. No guideline can cover all possibilities, so you want people to be able to extrapolate from what you have written.

For your examples, I would suggest using code that you have tested in an actual application to ensure that it works correctly. I would also suggest using examples from a project that you (or one of your co-workers) has written, rather than lifting them from programs written by your suppliers.

Some people would not like code samples from their own work being handed out to all and sundry. You may find it best to write a special program which is very carefully written to show as an "ideal" case. I think it is important
though that if you ask someone to do something a particular way, that you have tested it carefully to make sure it works.

Don't forget to specify internal program documentation requirements as requiring symbols for all addresses used and rung comments. If you have a preferred convention for symbol names and abbreviations, you can state those as well.

Expect to put a considerable amount of work into this document if you want something which is useful. Regardless of how detailed it is though, you will find that no one else will ever do things exactly the way you would have. This particularly applies to the finer details. Your objective should simply be to have the broad approach being similar enough that each machine does not become a major reverse engineering project when it comes time to understand it.

One thing to keep in mind in all this is that a guideline on programming style should not also be a specification on how a machine should work or on what the operator interface should look like. If you wish to deal with those issues as well, they deserve separate documents themselves.

************************
Michael Griffin
London, Ont. Canada
************************
 
I agree with Michael on all points. I would like to repeat that standardized documentation is very important. It allows you to search for items, areas of code, or inputs/outputs very quickly and efficiently. It also allows you to print out and sort lists in an orderly fasion. Segregate memory, document consistantly, and show your vendors as many examples as you can. This should really make a difference. You will also find out which vendors are worth a darn, or just pass on the job to the most inexperienced/cheapest programmer on their staff.

Aloha
 
E

Edward W. Oskam

Your complaint is one i hear a lot. I'm sorry to have to admit that you are right. As a software engineer I often switch to my own style of programming.

The reason for that is simple; it's effective and takes less time. All principals are proven by other projects.

I realize that the customer is not always happy with that end result, but until problems arises, who cares?

The only way to prevent problems is by demanding documentation of every part of the software. A programmer that does not keep it's documentation up-to-date is a menace to its own program.

I hope this helps you (in the future)
Edward
 
B

Bob Peterson

I have seen a fair number of attempts at this. Most of them fail pretty miserably because they usually are oriented around a certain type of
machine/control. To do it well would take a lot of time, and most people don't have the time to do this kind of thing. What I have seen done tends to be one of the following:

1. Samples of code. Sometimes I have gotten samples that are almost undeciperable as to the intent, others don't even work. Some are written OK but don't really address things outside of the things the programmer thought of when writing the code snippet.

2. Data structuring techniques. These tend to be a little better thought out but usually are pretty simple An example was a Modicon 984 program where they specified all the digital inputs would be 1xxxx addresses, the digital
outputs would be 0xxxx addresses, and register inputs would be 3xxxx addresses (I kid you not -this was part of a spec I worked on once). For
those with no PLC experience, this is the only I/O addressing scheme allowed in a 984 processor. Why they felt it was necessary to put in their spec was kind of beyond me.

3. I have seen code specs that require ALL logic be done with only coils and contacts. Makes it near impossible to do any analog at all, yet the project had dozens (maybe as many as 100) analog I/o points.

One spec said all code must be in a single program file. I talked them out of this by showing their engineer how to call up the seperate files and explaining why it was important to structure the code this way.

4. Documentation specs. One spec I ran across said all PLC addresses must have descriptors. The programmer that worked on it before me called timer T4:0 "Timer #1", T4:1 was called "Timer #2", etc.

Another spec required ALL rungs must have rung comments. One of the niftier things about RLL is that if you are careful, most rungs are pretty much self documented via the address descriptors so rung comments are not really needed MOST of the time. My theory on rung comments is that if your code is so badly done that you need to explain it, its probably in need of redoing. I
only put rung comments where its not obvious what is going on (such as when setting up analog input points for filtering/ranges/ etc.

The worst thing I see is not so much the code but the fact that there is little or no description on how the machine is supposed to work. The code
becomes the sequence of operation, and the only reference available on how it works.

I would make two suggestions.

1. Insist that a written sequence of operation be supplied, also subject to approval. Make it part of the spec that no code can be written until this document is in your hands and approved. You may have to do this in steps,
but this is well worth it. I don't really care what format this takes, but it should be COMPLETE and UNEQUIVICAL. Often I read sequences where things are missing like:

- how are alarms reset?
- does an alarm have a time delay associated with it?
- does a startup sequence have time delays associated with it? For instance its not uncoomon to start up a series of spindle motors on a dial machine sequentially rather then all at once.

The document should be written such that its completely unequivical. No interpretation allowed. It says what it means and means what it says.

This does not mean the sequence of operation cannot be revised along the way, but only that when it is revised it is documented and the SOO is updated.

2. Make the PLC code an approvable item, just as the schematics are. Make it clear in your spec that if the code is not understandable and consistent, it will not be approved. Check a couple of sections of the code you get against the sequence of operation. make sure it actually does what it says. If it does not, then one of the other is wrong and needs correction. I would
not be all that worried about stylistic differences, but I might put a few requirements into the spec such as:

- sequential items must be controlled via a number in a register that corresponds to the step number. that way you get rid of most logic races, and its obvious where you are. You can only be in one step at a time this way, and its relatively easy to jump out of sequence if you have to without strange looking code.

- limit the use of latches in the logic. You may not be able to eliminate them completely, but use them sparingly.

There are probably other things that are useful you might thinks about. Give it a month or two and I am suree you will come up with a decent document. Try to do it in a few hours and it will be useless.

Bob Peterson
 
M

Michael Griffin

<clip>
> I have seen a fair number of attempts at this. Most of them fail pretty
> miserably because they usually are oriented around a certain type of
> machine/control.
<clip>
This is a good point and raises something I should have mentioned in my earlier reply. I don't think that it is feasible to write a useful single programming guideline that covers all types of machinery. It is inevitable that it will make certain assumptions about the type of machinery or process being controlled. The fact that these machines or processes are broadly similar is what makes the guideline feasible and useful to begin with.
These assumptions should however be stated clearly at the beginning of the document. If a particular application does not fit these assumptions, then the sections of the guideline which cannot be applied to it should be set aside for that project.

> What I have seen done tends to be one of the following:
>
> 1. Samples of code. Sometimes I have gotten samples that are almost
> undeciperable as to the intent, others don't even work. Some are written
> OK but don't really address things outside of the things the programmer
> thought of when writing the code snippet.

I am sure that you will agree that code samples or "example programs" by themselves are not very useful. A set of disjointed "snippets" without accompanying explanation don't tell you how they should relate to one another. Large example programs take an excessive amount of time to read and analyse without any guarranty that the reader will understand what it is you had in mind.

> 2. Data structuring techniques. These tend to be a little better
> thought out but usually are pretty simple An example was a Modicon 984
> program where they specified all the digital inputs would be 1xxxx
> addresses, the digital outputs would be 0xxxx addresses, and register
> inputs would be 3xxxx addresses (I kid you not -this was part of a spec
> I worked on once). For those with no PLC experience, this is the only
> I/O addressing scheme allowed in a 984 processor. Why they felt it was
> necessary to put in their spec was kind of beyond me.
<clip>

On the other hand, I have seen people use output addresses in spare slots as flags (internal coils) because they didn't know what the flag addresses were in that brand or model of PLC. This makes things rather interesting when you are trying to understand a program, or even worse, trying to add an I/O card into that previously unused slot.
It would not be unreasonable to specify something to the effect of using the PLC's addresses and features in a manner corresponding to convention and the manufacturer's recommended practices. Some of the worst programming practices I have seen have arisen from people going to great lengths trying to program a piece of hardware using methods which were derived from something they were more familiar with, but completely unsuited to the hardware in question.

> Another spec required ALL rungs must have rung comments. One of the
> niftier things about RLL is that if you are careful, most rungs are
> pretty much self documented via the address descriptors so rung comments
> are not really needed MOST of the time. My theory on rung comments is
> that if your code is so badly done that you need to explain it, its
> probably in need of redoing.
<clip>

On the other hand, if the code *is* unreadable but works, you are not likely to be able to force the programmer to re-write it. It will come down to an arguement with you saying you don't like it, and the programming saying your objections are unreasonable. You are probably better off as a customer specifying having rung comments, and then over looking their absence if the program is reasonably readable without them.

> The worst thing I see is not so much the code but the fact that there is
> little or no description on how the machine is supposed to work. The
> code becomes the sequence of operation, and the only reference available
> on how it works.
<clip>

This of course, is a separate issue. A good documentation specification is probably more important than a programming guideline. It is easier to figure out how a program works if you understand exactly what the machine does, than the reverse would be.



--

************************
Michael Griffin
London, Ont. Canada
************************
 
B

Bruce Durdle

OK Edward,

So you come to me and say you want a new kitchen designed for your home. I just happen to have a portfolio of standard designs that I have built up over past projects. All have worked successfully for their clients.

You give me a list of your requirements, including colour, preferred appliances, and your required layout.

I give you in return a design cobbled together from my past projects, which uses different hardware, has a different colour scheme, and doesn't quite fit into the space you have available.

But the design process is "effective" - (to me) and has taken "less time" (to me). The design has been "proven".

You, as the customer, are not happy with the end result, but can still cook a meal and wash the dishes. I walk away with my nice fat designer's cheque - who cares?

This is not "software engineering" - it's imposing your notion of what is needed on the end user. Yes, I know it's how Microsoft work and there are a lot of people out there who accept the result, but it is totally unacceptable in an industrial automation environmment. If a client has a site standard to use negative logic for shutdown systems, but your preference is for positive logic, that's your problem. You cannot just go ahead and design using positive logic regardless.

An engineer in any other discipline will insist on a detailed brief and specification before work starts, and the project will not be accepted by the end user unless it meets that specification. This can be done with software as well. But there seems to be something in the mind-set of software jockeys (as opposed to true software engineers) that forces them to do their own thing regardless of the situation.


Bruce.
 
B

Bruce Durdle

One way to get improved readability of a PLC program is to link it very strongly to the Functional Description.

If every clause in the Functional Description is translated as directly as possible into a block of ladder logic or SFC or FBD or whatever, then the
documentation is already done and need only be pasted in. There is direct traceability between the requirements and the final code, and testing (which should be aimed at verifying operation against the FDS) is simplified.

Another useful thing to insist on is that documentation uses standard tags and the same descriptors as other plant documents. Switches etc need to be explicit as to whether they are open on High or open on Low, etc.

One point I have come to accept is that the automation industry has a tradition of accepting things that work, regardless of whetther or not they comply with the "politically correct" view of how things ought to be done. It is particularly evident that theories develoiped in the academic community take a long time to gain acceptance on the shop floor, unless they offer some immediate and obvious benefits. Perhaps that might help to
explain why RLL is still going strong ...

Bruce.
 
B

Brian E Boothe

Our Company Only Keeps Documentation on site In-case of a lose of our software On the Local machine.. so we dont have to retrace our steps. my question is how can there be a standard to Ladder Programming? There isnt THAT Much to it..To Really Impose a Standard.. Except Maybe
Subroutine Usage. can someone give me Some examples. Bit file usage?? Integer file usage.
(EXPLAIN).
 
B
Some items for standardisation -

Positive vs negative logic - does an energised coil mean an active or inactive condition?

Rules for using latches - if the language set has Latch/Reset contacts, are they used? If they are, I prefer to see them once only in a scan, in
adjacent rungs.

Arithmetic format - are analogue values handled in raw form or converted to engineering form?

Allocation of coils to parts of the system.

etc

Bruce.
 
M

Michael Griffin

The reason for a "standard" (i prefer the term "guideline") is to make a program easier for the final customer to understand by making it more consistent with the general usage they are familiar with. This is rather similar to the reason why there are "standards" in most human languages for capitalisation and punctuation. When these standards are ignored, then programs (or messages) become more difficult to understand or decypher.

A PLC or PLC language is intended for universal (or at least very wide) application in automation areas. In any particular industry or application class however, there are common problems which can be solved in a common way. A standard (or "guideline") is intended to specify what this common approach is. When programs are written to a standard, you know what to expect when you read a program you haven't seen before.
Unfortunately, there are no published widely accepted programming practices which can be used, so any company which desires a common standard ends up with their own rather than being able to adopt one.

There are several aspects to a standard. One can be a naming and abreviation convention for symbols (these should hopefully also be similar to what is on the electrical schematics). This would also normally include the human
language you would like program documentation to be in (do you want your rung comments in english, or is french OK?).
Another is a data memory usage standard. For example, you may specify a particular memory area for alarms, and another for parameter storage.
Still another aspect can be programming language representation. You may specify ladder rather than instruction list for general use, but allow instruction list for certain limited applications (e.g. inside function blocks which perform data manipulation rather than direct control).
A further type may be code methods for common problems, such as machine sequence control. There are at least a half a dozen common methods of controlling a multi-step sequence. A "standard" would state which of them to use.
Yet another type may be to specify the general program organisation. For example, mode transfers may be in one subroutine, MMI control in another, alarm decoding in another, machine control functions in a particular range of
subroutines, etc.
A final type may be to specify using certain proven function blocks which the customer has written for particular application problems (e.g. to interface to particular hardware). Using these proven function blocks saves time (and therefore money) and eliminates a source of bugs.

I think the above gives a general idea of what a standard (or guideline) would cover. It is mainly of benefit with larger programs. With small "relay replacement" programs, the benefit may not be as great.

The above discusses the "what". As to "why", the reason is the customer will sooner or later have to read the program to solve a particular problem, and it is likely they will have to do so when they cannot afford to waste any time getting the machine running again. If every machine was programmed using different methods, a great deal of time would be lost understanding each one.

************************
Michael Griffin
London, Ont. Canada
************************
 
B

Brian E Boothe

geesh thats the LAST thing we want is the FINAL: customer getting into our Ladder and screwing around with it..then there Machines screw up and Guess what ITS ALL OUR FAULT.
what Customer Knows Ladder Programming and C/C++ anyway??? Documentation to Installations and scada procedures. YES . BUT NOT the Ladder
Program for even access to the Windows Environment..................
 
B

Bouchard, James \[CPCCA\]"

I am a customer and all our technicians ( 42 of them ) know Ladder logic and other things. In may cases we know the machines better that the builder. That is why we want the programs well done. Remember we run the machines 24 hours a day making real product and have more experience with how they operate than the builder who operates them only a few days and scraps all the production. We do not want machines with C/C++ because it is impossible to follow.

James Bouchard
 
M

Michael Griffin

I don't know what type of machinery you may build or what your customers are like, but normal practice in the industries that I am familiar with is that most machines are custom built for the application and controlled by PLCs. Once the machine has been formally accepted by the customer, they take responsibility for operating and maintaining it, including the software. Warranty for software problems is normally invoked only for problems which are serious and repeated. The customer isn't going to sit with a production line down while waiting to contact the company which built the machine.

As for "what customers know ladder programming", well an industrial electrician would have difficulty finding employment in this area without knowing how to at least read a ladder program. 'C' or 'C++' knowledge is less common, but then I don't believe that was the subject of our discussion.

************************
Michael Griffin
London, Ont. Canada
************************
 
G
I am one of those FINAL: customers that you are referring to and I take great offence to your "Holier Than Thou" attitude. First of all you were paid $$$ to put the code into the plc and that is where it ends. The program may require modifications due to operational changes (3 am).

Are we supposed to call YOU to make the change? You may not know it but there are a lot of plain electricians out there that are EXCELLENT programmers.

Electricians were trained to understand and design ladder since it is a representation of the old world hard wiring. No rocket science to me.
 
P

Pierre Desrochers

I do a lot of work for OEM. I do comissionning and service them machines over modems and Ethernet...

What J. Bouchard said is more than the real thing. When I talk to end-users technical department, I listen. They do know these machine more than I ever will.

We build them, test them in the shop, spend a few days comissionning them but THEY used them 24/7 in the real world. I often see Operators discussing the Ladder diagram when they troubleshoot. These guy are not dumb, they pickup bits and pieces along the way and they look and listen at these machine for more time than me.

Ladder... everybody knows that. If they don't, there nobody. What's the saying about getting out of the kitchen ???

Pierre D.

===========
Quote:
I am a customer and all our technicians (42 of them ) know Ladder logic and other things. In may cases we know the machines better that the builder.

That is why we want the programs well done. Remember we run the machines 24 hours a day making real product and have more experience with how they operate than the builder who operates them only a few days and scraps all the production. We do not want machines with C/C++ because it is impossible to follow.

James Bouchard
 
B
Bruce Durdle wrote:
> Some items for standardisation -
>
> Positive vs negative logic - does an energised coil mean an active or
> inactive condition?

At the very least the descriptor should indicate what logic 0 or 1 means.

> Rules for using latches - if the language set has Latch/Reset
> contacts, are they used? If they are, I prefer to see them once only
> in a scan, in adjacent rungs.

AMEN! Best bet is to avoid them altogether. You can always tell when someone is using too many latches because they end up with a bunch of singleshots in the code to get rid of the scan races. Overuse of latches is probably the best single indicator of low skill or experience level on the part of the programmer.

> Arithmetic format - are analogue values handled in raw form or
> converted to engineering form?

Another thing is that if at all possible the values should be in floating point format so the value is always in engineering units, thus not requiring some kind of implied scaling. That way you can read the value directly. If for some reason you are forced to use integers the descriptor for the value should clearly state any implied scaling. The descriptor should also indicate the units (i.e.-psi, inches, etc.).

Bob Peterson
 
D

Dobrowolski, Jacek

Bob Peterson wrote:
>AMEN! Best bet is to avoid them altogether. You can always tell when someone is using too many latches because they end up with a bunch of
singleshots in the code to get rid of the scan races. Overuse of latches is probably the best single indicator of low skill or experience level on the part of the programmer. <snip>

Dear Sirs,

There're machines to control which is enough to use combinatorial logic approach only - then no need to use the latch/reset instructions. But there are also a little bit more advanced machines to which the automata theory must be applied. As far as I remember to implement this kind of beast in a hardware way, there's required a device called latch (what a coincidence). So usage of the latch/reset or set/reset instructions in a PLC program is one of the most straightforward implementations of the state
machine (remember that not every PLC programming package supports state flow languages nor every customer wants to see other than ladder languages in the PLC program).

And in the end I'd be careful with adopting skill indicators.

AMEN!

Best regards,

Jacek Dobrowolski, M. Sc. E. Eng.
Software Eng.
 
Top