PLC code standards

D

David Ferguson

I couldn't agree more with this last post by KEJR, I have been trying to write a code and graphics standard for 20+ years. The best I can do is a standard for our company as any time I try to go beyond that.....too many "experts" get involved and I get nowhere. Most don't have a clue what they are talking about and inflict "opinion". As the customer I can control some of what gets written, as a supplier when trying to implement standards, everyone "thinks" they are experts and think "your standard" stinks......most haven't thought past the first layer of that onion.

As this poster says, shoot for naming conventions, document the he%# out of your code (usually to save you) even though time consuming, try to build a library of code and graphic snippets. I have old ladder chunks of reusable code for motors, valves, sequences, interlock diagnostics etc. And I have code chunks for the same stuff in modern controllers, ie objects for motors, valves etc that I just drop in, assign tags and code done.

But the "magic" is still in process knowledge and problem solving.....as said here, with any processors old code, a bad programmer can write "spaghetti" code. With new object oriented PAC's, nothing changed only now they can create code chunks, I can now write "ravioli" code if I want to.

The software programmers book from the 70's and updated in the 90's, "The Mythical Man Month, essays in software engineering" still has concepts for writing software that apply to control code.....simplicity, reusability, design, documentation etc. This is a must read for anyone doing any code....but that requires reading it.

What is the difference between an Artist and a painter......one does houses.

Dave Ferguson
Control Systems Engineer

Sent from my iPhone
 
Yes, there is a huge gap between writing Automation Software and Writing Modern IT applications. And unfortunately Automation Software is the area that is lagging a long long way behind the rest of the IT world.

Some very excellent programming methodologies do exist - Object Orientation, Agile, SCRUM, to name just a few - and these can be applied to developing Automation Software as well. (And we've had some excellent results doing just that).

At first glance, Object Oriented Design might seem a long way from writing a PLC program. But the reality is that something like a PID function Block is just a software "object" and it is surprisingly easy to use many of the ideas behind object orientation to design your software.

Unfortunately, a few posts on an automation board are not going to be enough - This subject really does require an entire book.

Rob
www[.]lymac.co.nz

http://en.wikipedia.org/wiki/Agile_software_development
http://en.wikipedia.org/wiki/SCRUM
http://en.wikipedia.org/wiki/Object_oriented_design
 
L

Luca Gallina

WOW, resuming a 10 years old thread...

I think there's more need of a "standard programming methodology" rather than simple "standard coding". There's not such a thing as a "standard" application nor a "standard" customer: it's the automation software that must adapt to the specific application, not the application to a "standard" PLC coding.

Standard libraries and functions seldom cover all applications' flavors and, trying to be all-inclusive, they tend to grow huge and difficult to maintain.

My way is to keep everything as light and neat as possible, and this means rewriting most of the code for each different kind of applications. The keys to keep it reasonably cheap are:

- accurate project engineering
- accurate software design
- dexterity with PC HIDs (namely keyboard an mouse) and developing environments shortcuts
- use of programming tools and aids external to the developing environment.

All things no school, no university nor programming courses teach you in any way.
At least as far as I know.
 
Dave,

It is good to know there are like minds out there. I'm starting to realize that without proper support from the top you can't expect to have consistent standards or consistent design patterns or philosophies or whatever you might call them. I think good managers should be checking the code, but then many managers can't read the code. I partly blame the mentor process (or lack thereof). Does this ring true with what others are seeing at their companies?

I like my Ravioli, but I find the code still gets written in spaghetti even with modern Object Oriented IEC 61131 style PLCs. I think it definitely helps and I've written a library of routines that should help to lessen some of the bad code in the future. Lately I've been maintaining old C++ and "traditional" ladder projects since the systems are older and more people have come and gone and left me with their legacy. BTW, I love Italian food, just not in my programs. :eek:)

I will check out that book. I am mostly an automation guy, but I do write some C/C++/C# code and I think I am really a closet Software Engineer. I noticed it is available on the nook.

I have heard the artist analogy before and even to the excuse that "I prefer to do it *my* way", as if Engineering as a career is some kind of grand creative outlet (I am a creative person at heart, but I get paid to do Engineering). In some senses I have an understanding of that viewpoint because I think I would have a hard time if someone dictated to me how to program. On the other hand I do find myself seeking others that are true experts (through books or forums) and solicit their style and philosophies. Maybe that is the difference?

At the end of the day I think it is difficult for all of us Automation Geeks (I use that term with honor) because we are asked to wear so many hats. I can't speak for others but I find myself writing modern ladder, ancient ladder, HMIs in C#, database work, Electrical Schematics, Advice and debug on mechanical design, process troubleshooting, selecting sensors, vision systems, motion control.... It just seems to go on and on these days. No wonder things get butchered.

Still, when your program consists of a 5 step sequence and it is spread out of order over 15 pages of butchered ladder you have to ask why? Did they just not know it could be 5 rungs? More and more I wonder if some of these people get off by over complicating things, which is sad.

KEJR
 
K

Ken Emmons Jr.

Hi Luca,

I felt guilty replying to the more recent posts of this old thread, but I guess that goes to show how glacial progress has been in this field! :eek:)

I encourage you to try developing some Building-Block function blocks that you find yourself coding over and over again. I've done this and it really cuts down on the keyboard/mouse work if you can encapsulate functionality. Its always a trick to try and only develop functions in your library that you think you can re-use. Sometimes you paint yourself into a corner, but other times it can really save your bacon or save you time.

I do agree with your other points. A well designed system that is as lightweight as it needs to be is ideal. I've found that embellishments get in the way when you go back 10 years later.

KEJR
 
IEC 61499 may be something for you to look into. Loytec released a working IEC 61499 system targeting building automation. You could maybe look there or possibly something on a website called holobloc (I think).
 
S
All,

> 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 work for a company that provides automatic PLC static analyzer that reviews PLC programs automatically and alerts and warns if there is any issue with coding styles, complexity, dead codes, etc. You can find more information at http://www.automationsquare.com/plc-checker.html. You can also contact me at [email protected]. I can also send you a PLC programming guideline which you can refer to when setting up your own PLC coding standard.

Thanks
Sangmin
 
Top