plc programming standards

georgia boy

Member
Join Date
May 2005
Posts
14
hello everyone

i wanted to get some feed back on general plc programming guidelines from industry professionals . the right ways to write and structure programs . the best techniques etc . i thought it would be a good topic for myself and others since these are tricks and tips you get from experience . i would be nice to have everyones best tips in one thread

thanks

georgia boy
 
If Field Service the standards are as varied as the customers.

I have several customers that do not allow us to us the actual inputs/outputs in the code. We have to transfer all inputs to DBs. Use the DBs in the code, then transfer output DBs to the Outputs.

Another customer won't let us program in STL.

Still another won't take anything but STL.

We don't have a set standard, we have to chameleon to the customers demands. And like I said, each one is different.

Good Luck,
Kevin
 
[ramble]
There aren't any real standards per se because everyone's needs are so different. Nevertheless, one should still practice good program design techniques.
Use top down software design.
Break the operation down into logical zones (eg vacuum pump, cold trap, retort, hotzone, powersupply) or logical sequences of operation (eg close, feed powder, compact, open, eject). Then write a subroutine for each section. My general rule of thumb is that if I dont think I can write it in 30 lines or less, I need to break it down some more. That is just a general rule however, there will be times when it makes more sense to keep all the lines together for that part.

As I usually use AB plcs, I also create data files to match each zone or step (eg B13, T13 for vacuum pump, B23, T24 for cold trap, etc.)

There are some other things as well that will help out anyone who is looking at your program in the future. Early on in my programming career I developed truth tables and karnaugh maps and applied logic reduction techniques and built this nice little compact program. Its still in use today, but no one, not even myself, can read it anymore. Those rules may have applied back in the days when you designed PCBs with discrete gates, but in a PLC it doesn't matter. If it makes sense to include a bit on a rung for the sake of readability, even thought that bit might be covered by combinations of other bits on the rung, then go ahead and do so.
Example:
The RUN bit might have AIR_PRESSURE_OK among its permissives, but if if makes it more readable to do the following

RUN OTHERPERMISSIVE AIR_PRESSURE_OK OUT
------] [-------] [-------------] [-------------( )


then go ahead and do it, someone from maintenance might just be glad you added the extra bit someday because he didn't have to sort through spaghetti code. Don't go overboard on it however.

Memory conservation is not really an issue in most PLC programs, and its not like a mainframe being shared among multiple users - so go ahead and use it where it will make your job or someone elses job easier. The chips are stil there and you paid for them even if you don't use them.

Program tag names and electrical drawing tag names should match.

Above all else document, document, document. And keep a program revision history, a from/to change log, and a description of why.
Do not adopt a kingom-builder attitude and horde your know-how with poor documentation. Someone who is irreplacable for those kinds of reasons is all so unpromotable.

[/ramble]
 
another thing -

at least around here the maintenance guys like it if I group all the Outputs together in the program, preferably in an Output subroutine. When something isnt working and they want to trace down a bad sensor, they usually start with the output and work backwards. Its easier to find if they are all grouped.
 
Here’s a documentation standard that I use with AD programs.

Since AD’s Nickname for elements only takes a set number of characters I was having a hard time creating meaning full names. When I view one of my programs, I only view it with the nickname shown. For certain types of elements I surround them with special characters.

For alarms I put * around the name, *WP1_Hi_Lvl*

For elements from an HMI I put a <> around it, <RP1_Auto>

For elements from another PLC I put = around it, =PLC1_Comm=

This way at a glance I know what type of element it is.
 
This is a personal preference, and a lot of the regulars disagree wth me on it: I avoid one-shots and set/reset if at all possible. That is simply because they are hard to monitor, and in the throes of de-bugging it may not be obvious what is going on.
 
One thing I do insist on during debug is a dedicated DB for toggle/debug bits. They are a lot easier to find when all is done than a whole range of M-bits that, after 8 months of debug, nobody remembers why they were there in the first place.
 
I also prefer to avoid using MCR instructions with a long zone under them.

Inevitably someone will at some future time look at a rung in the MCR zone and see that all the rung conditons appear to be true yet the rung is still false, and not bother to scroll back a few rungs to see if he is in a MCR. They have their place but I use them sparingly.
 

Similar Topics

Hello colleagues, Some time ago I started my adventure with programming. With your help and the courses, things are starting to come together...
Replies
13
Views
594
Dear All, I need a sample PLC program to count the output pulse of a mass flow meter so that a specific amount of mass (for example 100gm)can be...
Replies
2
Views
82
Hi Please I have zeilo smart relay #SR2A201BD but I don't have it's programming cable. Can I use any general usb/rs232 converter? Or need...
Replies
2
Views
80
Hi, Does anyone have thoughts or know of, can point in the right direction any published materials with a plumbing centric point of you explaining...
Replies
1
Views
126
@ All: what is your best guess on a potential range in increase in efficiency in % (i.e. saved programming hours, greater output, etc.) when...
Replies
5
Views
291
Back
Top Bottom