PLC code standards

S
Spot on Bob. Some of the threads above are overly prescriptive - even though we are talking standards. There's nothing wrong with varying approaches to coding. What's missing in most PLC programs that I've come across is careful design & above all structure. Let's face it, our plant engineer has to maintain a variety of systems, each doing a different job function. All the guy needs to do is to get in there quickly & find the route cause. If the programming language does not support encapsulation ( and maybe abstraction & reuse also ) may be he shouldn't be specifying it. Break it down into manageable chuncks !
 
L

Leigh Phillips

There is a standard which can be applied by most PLC vendors it is called IEC1131 if you specify that all code be written to this standard including the use of sequential function charting it makes the subsequent fault finding much easier as it is a standard fomat and can be followed by most people with software experience
 
There is no way to force anyone to program a specific way...that would be like tellng everyone to act the same way...it ain't gonna happen!!

I have been servicing and engineering motion control, cnc and plc control systems since 1972. There are a couple things I think would be of benefit to you based on my experience.

First of all, standardize on a specific brand of controller and then specify that system with your purchase order.

Secondly, generate a spec for documentation and specify that all of it (and I mean all - schematics, plc and parameter listings, manuals, etc.) be included in duplicate with your purchase order.

Last but not least, become intimately familiar with the products you have specified so you know how to service them. It takes some time, but it's not to hard to do when you have a factory full of the same brand of hardware.

Hope this helps.
 
E

Everett Arellano

I am also a controls/electrical engineer, however I work for a systems intergrator where our business is not manufacturing but supplying automated machinery. We program in state logic. It is a standard that we use and I also used it at my previous job. All of our engineers and end users can read each others code with relative ease. It helps when you are dealing with a hundreds of I/O. Weve used this method on multiple platforms. Personally I have used it on Automation Direct and Allen-Bradley PLCs
 
WOW - what a cool thread going on here!
FYI: I'm a software manager at a large system integrator, been doing SI for 16 years. I can see all sides of this thread and each persons viewpoint.

However, to your original point...

If you purchase many machines of the same type, you should make a standardized specification. Just as you probably specify which PLC's, wiring color codes, safety guidelines, spare parts, etc. It may cost you a little more up-front to force your vendor to go that way, but it will save you time on your floor.

Being an SI, probably about 30% of my customers specify a standard architecture. Most of these are semiconductor, aircraft, or large consumables plants. Not so many automotive tier mfg's have this requirement - they mostly just specify AB/RA and IEEE 1131 and leave it at that.

We have many engineers of all disciplines. We are ISO certified and have all our own standards. However, when a customer comes to us, we will quote the machine with our own standards (because we know it best, etc.). A customer may specify via documents how the machine is to coded. We will review that, (usually raise the price accodingly) and provide that as a quote.

We turn MOST code over to the customer for them to maintain. From the time it leaves our hands, it usually remains on the floor (esp automotive) for electricians to deal with.

If any of you reading this and you're an SI, you'd better be flexible. After all, your job is _CUSTOM ENGINEERING TO CUSTOMERS REQUIREMENTS_. Just as you use specific wiring, color codes, recommended parts, etc. Your software should fit the needs of the customer as well. I'm not preaching here, it's tough market conditions right now.

As for some notes about the replies in this thread, this is a great reading thread (maybe best ever). Typical is _ENGINEERING_ vs _PRODUCTION_. ENGINEERING wants well organized and controlled machines, SW and HW maintenance records, scheduled downtimes for fixes, libraries of code, etc.

PRODUCTION is a different food chain. The Prod Mgmt can dynamically change requirements and 'expect' that the floor can accomodate them. Changes must be made on the fly, get the machine up, etc.

Ok, sounds like I'm middle of the road. Well I'm not at all. Just pointing out where both sides are coming from. A few recommendations:

1) If you're ISO, you'd better make changes temporarily on the floor, proper reports should be sent back to engineering for a permanent fix. ISO police will get you.

2) If you automotive, esp ILVS, there can be no excuse for errors in order timing or sequencing. Also, because this is highly network intensive, an engineer should be involved in the work.

3) If you're union, the electricians control a lot. They'll make changes on the floor and rarely document. Sometimes changes that are meant to be only temporarily become permanent.

4) If you're a mix (or all of) the above.... well, thats another matter.

Bottom Line. The OME (Overall Machine Effeciency) of a machine should go UP! Engineering and Production both want to see this! If your OME goes down and electricians are working on it, then one way or another, they are not maintaining the machine as good at they can. (Don't let sensors, part availability be an excuse - you'll need to measure OME for a month or two). If engineering maintains the machine and OME goes down, then they are too slow (specialist at 3AM, to much analysis, etc.). Look at the OME and evalueate your needs.

FYI: I've placed many machines in US, Japan, Sing, Europe. Depending on machine complexity and number of stations, the OME will be 90-95% when it leave the SI. In the US, OME will decline (esp automotive), In Japan, it will increase after a machine is delivered. Another topic for another time, many factors. BTW: I'm USA and would love to report that differently.

JR
 
G

Geoffrey Dell

You may want to begin with standardizing the make of PLC's you accept in the machines you purchase. There may be an upcharge if it is not the OEM's preferred PLC but I believe it pays off in the long run
 
I find a compelling argument is made by Alan Cooper (creator of VISUAL BASIC and winner of
a MICROSOFT Genius award) that programmers
should design with the average user in mind.
A great, non-technical argument is in his book,
THE INMATES ARE IN CHARGE OF THE ASYLUM. Try to
get your bosses to read it!
VB goes a great way towards implementing this for ordinary PC's. Wish we had the same for PLC's.
 
Great question, it is a shame that the thread has become a battle ground for different programming styles.

I have been looking for just such a 'style sheet' to guide me in 'standardizing' my new programs and to make life easier when recieving new equipment.
 
B
Thats a lot like specifying it be done in English. There are an infinite number of ways to code the same function. Specifiying a specific brand of PLc or IEC1131 does not ensure that machine A's code looks like machine B's.

Bob Peterson
 
V

Vladimir E. Zyubin

Hello Michael,

On Wednesday, July 24, 2002, 8:49:54 AM, Michael Griffin wrote:
[...]
MG> The ideal for a manufacturer in this business (as well as various others) is
MG> to be as flexible as possible, and to be able to respond to changes as
MG> quickly as possible. Speed of response and flexibility are just as important
MG> as efficiency. There is increasing emphasis on flexibility as product life
MG> cycles are getting shorter, and there is a proliferation of special models
MG> and versions being produced.

Yes. Flexibility is a good characteristic of any system. What we do - we provide special linguistic tools to do it and DB of algorithms. It
permits to change algorithms EVERY day, EVERY technological loop... There are only technologists on the top level of flexibility (they don't know about PID, sensors, accuracy, deviation, nonleniarity, filters, adjustment etc.), they think of their specific problems only.. The other level of flexibility demands programmer-specialists in control algorithms, but they communicate with the technologists in the same language. And only on the lower level of control program they (programmers) deal with the objects (sensors, servos, pumps, valves, etc). The next level is the logical signals level. The next level is the physical signals level (level of I/O cards). There is the most bottom level of programming - OSes. We never correct it. We prefer to migrate or to use the stand alone concept. :)

I think that the multilevel structuring like ours gives suboptimal flexibility. (Really I think that flexibility of our methodology is the best)

MG> You can see that the above is different from being able to buy a standard
MG> machine produced by the hundreds or thousands whose manufacturer has had
MG> years to work all the bugs out and perfect it. We have some machines like
MG> that, and yes, with those machines we seldom make any changes. These machines
MG> tend to be the exception though.

Yes. I see. I just can not catch how do the programmer do the changes in the LD. The programs they correct must be extremely simple. Kinda
physical parallelism on the objects level...

>> But there must be a special department on the plant... department that
>> rules... a special procedure to make the decision... specialist that can
>> make the calculation... Puzzled.

MG> <clip>
MG> If the machine isn't running or runs very poorly, your biggest concern is
MG> going to be that you can't supply your customer. If you don't do something
MG> about that very quickly, you aren't going to have any business to calculate a
MG> return on.

On the other hand lack of estimations can lead us to a wrong direction. On the other hand, Does quality lead to prosperity? Have a look at the MS story. :)

MG> Realistically though, if you make an improvement to the machine which
MG> involves only $100 worth of hardware and it makes a noticable problem go
MG> away, it will be well worth the expenditure. Remember that gathering data and
MG> conducting analyses also costs money. The procedures and calculations should
MG> be proportional to the risks and costs involved.

Agreed.

--
Best regards,
Vladimir mailto:[email protected]
 
V

Vladimir E. Zyubin

Hello List,

On Thursday, July 25, 2002, 8:46:43 AM, Jiri Baum wrote:

JB> Michael Griffin:
>> In addition to the above, there are many improvements which are the
>> result of employee suggestions which are relatively inexpensive to
>> implement. The cost of adding a sensor or valve to help keep a feeder
>> track from jamming are typically very small compared to the down time
>> saved.

JB> Not to mention that implementing employee suggestions will improve
JB> morale, increase ownership of the process by the operators, encourage
JB> further suggestions, and so on, even if the direct economic impact is
JB> frankly nil.

To Mr. Baum:
Jiri,
Inderect effects are considered as well. It is obvious, though it is difficult to calculate.

Another question is "is it right aproach to conside an influence on the stock price?".

And a couple of words to Mr. Griffin:
I see no reason to insist that "adding a sensor or valve [..] are typically very small compared to the down time saved".

So, where is the proof?

Please have a look at this.

The situation: an error happens.

What we must do? - 1. To clarify the cause. 2. To develope a plan to fix the cause. 3. To fix the cause 4. To test the modification/correction...

Did I say we must avoid to modificate the system? If there is a good reason, nobody have objections. Ever two valves and seven sensors...

But if we can solve the problem without additional hardware (! Note: it decreases MTBF and encreases MTTR!)... i.e., if we can fix the error via a correction of the program only, then IMO it is more preferable way.. it is a more economic effective way in most cases...

I believe that just to load a program is a less timeconsuming thing comparing to (to mount a sensor + to load the program)...
(I hope you agree that this new sensor leads to a program correction). Plus: In the second case program becomes more complex (again in most cases).

Or it is just an example? If so, it is a good example of economic effective solution: with a small investment (a cheap sensor) we have the result - a minute per a month of the working plant.

example of calculation (roughly):

1. investment: sensor price - $100, MTTF - 1 year, repairing - $100

2. result : a minute per a month of working plant (a car a month, i.e. the overheads (components, wages, etc.) is $9 500, the selling
value is $10 000, the profit is $500 a month or $6000 a year)

the same in the pure economic terms:
1. investment - $100 a year
2. result - $6000 a year

i.e. we have $60 per a dollar per a year.

The end.

--
Best regards,
Vladimir mailto:zyubin @iae.nsk.su
 
M

Michael Griffin

On July 26, 2002 11:58 am, Thomas Ng wrote:
<clip>
> I find a compelling argument is made by Alan Cooper (creator of VISUAL
> BASIC and winner of a MICROSOFT Genius award) that programmers
> should design with the average user in mind.
<clip>
> VB goes a great way towards implementing this for ordinary PC's. Wish
> we had the same for PLC's.
<clip>

Unfortunately, the "average user" seems to use Visual Basic to write programs which they (or their customers) can't maintain, or even get to run reliably in the first place. If someone wrote a good program in Visual Basic, they did it without any help from the language design.
Any problems I have seen in PLC programs pale to insignificance when compared to those which I have seen in typical Visual Basic programs. Making PLCs more like VB would be a big step *backwards*.

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

Michael Griffin

On July 25, 2002 10:19 am, "Vladimir E. Zyubin" wrote:
<clip>
> And a couple of words to Mr. Griffin:
> I see no reason to insist that "adding a sensor or valve [..] are typically
> very small compared to the down time saved".
>
> So, where is the proof?
>
> Please have a look at this.
>
> The situation: an error happens.
>
> What we must do? - 1. To clarify the cause. 2. To develope a plan
> to fix the cause. 3. To fix the cause 4. To test the
> modification/correction...
<clip>

I think that at this point, we are just repeating ourselves.

However, the identify/plan/fix/test cycle does not always require big meetings and long reports. Not every problem is a difficult one, and not every cure is an expensive one. This in fact describes what a good industrial electrician is expected to be able to do - identify the cause, figure out how to fix it properly and once and for all, fix it, and verify that it works.
The engineering staff do the same, but they typically operate on a larger scale and over longer periods of time.

We are missing the point though. The question was why an electrician would need to change a program. One reason they need to change it is because they need to fix it and if the program was written in a readable format to begin
with (remember the subject of this discussion?), it really won't be that difficult for anything he will typically want to do. We've discussed before
why a program may not be correct to begin with, so I won't repeat myself on this point.

The other reason why an electrician would need to change the program is because he was assigned to make a minor improvement to the machine. Typically in this situation someone else has had a look at it and decided that it is worth doing. Again, if the program was written in an understandable format, there is no reason why the electrician can't make the program change as well.
Most of these sorts of things reallly aren't that difficult. If we need to make an improvement by adding a sensor to tell if a feeder bowl is getting low and then signal this to an operator via a beacon, why can't we give the whole job to an electrician to do in his spare time (between servicing breakdowns)? The most difficult part of the job to do right is probably going to be making the bracket, not programming the PLC. Perhaps the bracket is the
part of this project that engineering should be doing for him.

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

Bouchard, James

Or even that the same function will be coded the same way by different programmers on the same platform.

James Bouchard
 
V

Vladimir E. Zyubin

Hello List,

On Sunday, July 28, 2002, 1:21:20 AM, Michael Griffin wrote:

LM> On July 25, 2002 10:19 am, "Vladimir E. Zyubin" wrote:
LM> <clip>
>> And a couple of words to Mr. Griffin:
>> I see no reason to insist that "adding a sensor or valve [..] are
>> typically very small compared to the down time saved".
>>
>> So, where is the proof?
>>
>> Please have a look at this.
>>
>> The situation: an error happens.
>>
>> What we must do? - 1. To clarify the cause. 2. To develope a plan to
>> fix the cause. 3. To fix the cause 4. To test the
>> modification/correction...
LM> <clip>

LM> I think that at this point, we are just repeating ourselves.

LM> However, the identify/plan/fix/test cycle does not always require
LM> big meetings and long reports. Not every problem is a difficult one,
LM> and not every cure is an expensive one. This in fact describes what a
LM> good industrial electrician is expected to be able to do - identify the
LM> cause, figure out how to fix it properly and once and for all, fix it,
LM> and verify that it works. The engineering staff do the same, but they
LM> typically operate on a larger scale and over longer periods of time.

Did I say "big meeting" or "long report"? I just say there ought to be a discipline. There ought to be a list of the changes. The maintenace
process must be reflected in a doc. Error / cause / action, error / cause / action, error / cause / action... even if every item is just
a sentence. Or a word.

LM> We are missing the point though. The question was why an electrician
LM> would need to change a program. One reason they need to change it is
LM> because they need to fix it and if the program was written in a readable
LM> format to begin with (remember the subject of this discussion?), it really
LM> won't be that difficult for anything he will typically want to do. We've
LM> discussed before why a program may not be correct to begin with, so I
LM> won't repeat myself on this point.

LM> The other reason why an electrician would need to change the
LM> program is
LM> because he was assigned to make a minor improvement to the machine.
LM> Typically in this situation someone else has had a look at it and
LM> decided that it is worth doing. Again, if the program was written in an
LM> understandable format, there is no reason why the electrician can't make
LM> the program change as well.

LM> Most of these sorts of things reallly aren't that difficult. If we
LM> need to make an improvement by adding a sensor to tell if a feeder bowl is
LM> getting low and then signal this to an operator via a beacon, why can't
LM> we give the whole job to an electrician to do in his spare time (between
LM> servicing breakdowns)? The most difficult part of the job to do right is
LM> probably going to be making the bracket, not programming the PLC.
LM> Perhaps the bracket is the part of this project that engineering should
LM> be doing for him.


>From the parallel thread "ENGR: PLC code standards" Mussel wrote:

"FYI: I've placed many machines in US, Japan, Sing, Europe. Depending on machine complexity and number of stations, the OME will be 90-95% when it leave the SI. In the US, OME will decline (esp automotive), In Japan, it will increase after a machine is delivered. Another topic for another time, many factors. BTW: I'm USA and would love to report that differently."

I must confess:
After Mr.Peterson stories about automotive industry in the USA, there is no wonder in the facts about the OME (Overall Machine Effeciency).

My personal point is simple:
Lack of discipline during maintenance leads to chaos. Lack of competence during maintenence leads to chaos. The language topic is less valuable in the case (though I see an influence as well). The main problem of the automative industry Mr. Peterson speak about is on the other level: Standardisation of the maintenace procedure.

The strategy of "continous improvments" lead to
decline of OME. I.e. the strategy is not an economic effective one.

BTW, the personel that is liable for soft can be called even "dustmen", but maintenace process must be properly organized.

--
Best regards,
Vladimir mailto:zyubin @iae.nsk.su
 
M

Mohammed Moosa

Dear Stephan,

A standard way of programming and a very user friendly one, which we have been using for so long is the Ladder Logic. This is a PLC programming structure. From my point of view I think this is the easiest and simplist way of programming.

regards,
 
W

Walter Swietlik

Hello,

I totally agree there should be a rule or guide. However there is not any coding standard in place of any kind. However if you are interested in knowing how I do it email me back and I will share it with you for free.
 
B
It has occurred to me that maybe a generic PLC code standard would be something that the people on this list could create for use by anyone that wanted it.

I wonder if anyone(s) with sufficient experience in actually writing PLC code might be willing to take on guiding such a task.

Personally, I would like to see not only a standard but maybe an appendix that explains why.

--
Bob
 
I think there should be documented standards, or more likely "design patterns" that people can fall back on. Most of the code I inherit needs to be partially or completely rewritten to be logical, predictable, and well designed code. Good programmers know what I'm talking about. Engineering vs. Hacking. It is bad when you have to tell your machine operators or your boss that you can't really fix the problem with the "other guys" code without upending tons of new bugs. It seems that many people don't understand the problem with spaghetti code, they just spackle on a new layer of ladder over the previous 3 layers. Some managers seem to only care about the immediate end result and the true problem of a code base that is unmaintainable is not apparent until much later after the "expert" has left to go to greener pastures.

I know it is not always possible with deadlines and people breathing down your back to fix things, but always strive to make your code consistent and easy to maintain, both for yourself and for others. Try to deal with your fault handlers consistently. Use data structures where you can, Name things consistently, and try to write your code so that it is self documenting (and only document the things that need documenting, like the reason you have that funky time delay at the end of the cycle where it shouldn't be necessary.....etc).

I was just yesterday dealing with a program someone else had written with an older PLC (predating the IEC and tag database style PLCs). Some faults where acknowledged/cleared by hitting the stop button when the machine was already stopped (The panel had limited buttons). Some other faults got cleared when they hit the run button. In the code the reset of all of the faults was dealt with in different areas of the program, and not in any logical manner. Relay assignments of the functions weren't in any consistent order and their comments were named inconsistently. There were about a dozen rungs of conditions just to start and stop the machine. There were relays setting relays that then set other relays making me have to juggle many complex rungs just to see how something simple was done like what happens when the operator hits the run button. I deleted most of it and will replace it with one or two simple rungs that will be documented and consecutive. A good programmer can take a complicated looking program and make it appear simple. Any idiot can make a complicated looking program. If anyone is starting out and reads this do yourself a favor and don't fool yourself into thinking complex=genius. Always strive to make your programs simple because one day your or your colleague will have to troubleshoot it and I can guarantee you that you won't remember that tricky tangled spaghetti mess of ladder in 5-10 years time.

Honestly, from what I've seen so far in this field I don't think any two people will agree on any standard way to do things. Maybe if there was a perceived "guru" or expert people would follow their advice, but I don't know if it would really happen. PLCs are just so very different from brand to brand the programming styles are just night and day.

KEJR
 
Top