Standards of PLC program design

Do anyone know if there exist standards for PLC program design. For example if I want to design a program to control water flow into a tank, are there steps to take to program, not the logic but the flow of the program.
Basically are there any standards or guideline to dictates how programs are to be laid out. Otherwise if you know of guidelines I can use please help.
Thanks in advance for your response.

Sincerely,

Having spent 20 years pumping water into and taking it back out of tanks, varying in size from 9,000 gallons to 16 million gallons, I can tell you that in California, there are no "standards". Every situation is somewat unique, so it is up to the programmer to design logic that accomplishes what is needed.

The most common way to do what you are asking USED to be bypass valves. You would vary the amount of water that get "bypassed" back to the souce, thereby controlling how much goes to the tank.

Today, Variable Speed Drives (also known as Variable Frequency Drives) are the most common. They are much more energy efficient and provide soft start for the motor to prolong equipment life and eliminate the normal high inrush current.

The only standards at this time are all company derived. But there is actually a panel in the IEEE that is trying to work out not only a plc programming standard, but an HMI standard as well, so you might want to look into it. Myself, after doing it for 30 years will ignore anything they come up with and continue as I always have. (if it works, don't fix it!)

assuming - the flow of the program is what you are refering to and not the control of the pumps.
there are limitations for the actual programming, esentially it is dependant on the PLC type, capacity and software ability.
an input say 0.00 means nothing to another programmer
so give it a name 'STOP_SYSTEM_RUNNING'
some PLC's can not handle that so it may be 'ST SYS' for example.
Usually you write a program to make it easy to find things.
Inputs together - (link to internal relays)
Outputs together - (fed by internal Relays)
Manual control
automatic control
HMI inputs
HMI outputs
timer section - (for easy setting or presetting)
At the end of the day think of the fault tracing of a program.

Thank you all for informative and quick replies, however I am more looking for program structures and layouts. Do I need to have fault and power up handler?
I have seen programs with attribute to first scan, with lots of latch and unlatch instructions. Are these required in every program?
If I am designing a program from scratch, are there any guide lines that can help me effectively design a good program?
Your responses are highly appreciated.

this depends on how the system needs to run
they may not be needed
but if you want to ensure that the system will reset to a particular state then you will have a number of values that you either want on or off.
some values may also need to be reset.
one method to sequence start and run systems is to set a value in a register then increment it for the next process.
to start the process you need to set this value back to a known value.
the 'first scan' is used to do this and sometimes an additional timed contact might be used so a 'RESET' button can be held to achieve the same result.

yes there is a standard in using blocks OpenPLC

and no no standard on how to program. but have a look at www.oscat.de for a lot of functions, some of them real complicated.

dabanani said:

Thank you all for informative and quick replies, however I am more looking for program structures and layouts. Do I need to have fault and power up handler?
I have seen programs with attribute to first scan, with lots of latch and unlatch instructions. Are these required in every program?
If I am designing a program from scratch, are there any guide lines that can help me effectively design a good program?
Your responses are highly appreciated.

Click to expand...

The answer to your first question is no, there are no standards.
The answer to the above questions are no, you don't have to do any of those things.

See link below for a good read about programming, read the entire thread.

http://forums.mrplc.com/index.php?showtopic=15680&st=0&p=77274&#entry77274

Standards do exist but they have to be driven by the client

My entire job is defining and verifying the standards for our public water/wastewater utility. We have a section in our standards that specifically deal with PLC programming HMI development, drawings, etc. I can help you with this if you like.

I prefer Buffering my I/O rather than using Aliasing. I realize the point of Aliasing is so you don't have to do that, but I like it because A) it removes the possibility of asynchronous I/O screwing with your logic if an input changes states between scans, and B) It makes it really easy to "break" sections of your actual logic away from the program and use them elsewhere. When I'm writing programs, I like to write completely with internal bits and then test out the code using Softlogix or an RS Logix Emulator if I'm writing in 500. When I've vetted the functionality, it's a simple task to map the real world I/O and I'm done. I generally have very short install times because there's very little (if at all) debugging in the field. What little there is is usually just adjusting to the way the real-world devices behave.

The only standards at this time are all company derived. But there is actually a panel in the IEEE that is trying to work out not only a plc programming standard, but an HMI standard as well, so you might want to look into it.

Click to expand...

Good luck!

Myself, after doing it for 30 years will ignore anything they come up with and continue as I always have. (if it works, don't fix it!)

Click to expand...

Yup.
I often get thrown at me 'prepare a flow chart showing the planned software writing process' - and 'prepare a flow chart showing the process control'. Fortunately very rarely this requirement is in the specification and that is my response.
I do all my planning in my head and implement what I require to accomplish the task in the design stage - when doing drawing of the control system.
Then when I get to writing software it just flows.
I would suggest you have a look at breaking the program down into sections though. Typically for me
Shut Down Alarms
Urgent Alarms
Non Urgent Alarms
Alarm Handling (buzzers, flashing lights, indicating lights)
Signals To Other Systems
Network Communications
Local Communications (Modbus comms to various devices for example)
Fuel Control (I do a lot of diesel generator work)
Auxiliaries Control (fans, water pumps etc)
Operational Program
You get the picture.

Section the program into manageable parts. Alarms, I/O, motor and valve management are the standard blocks that can usually be copied from one program to another.

Section the plant and make a subroutine for each section. Be liberal with subsections if needed.

Do not make conditional calls. Set a flag for some other routine to take an action and reset it when finished.

All routines must fetch and set their own values (I/O excepted). No routine can be dependent on another having set some critical value before it. Some idiot is certain to come along and switch the calling order.

Sketch out the program graphically or textually beforehand. That will let you see any tricky parts and detail them. It's much easier than fixing it up later on in the ladder.

I use a kind of textual pseudo-language that can be very detailed in the final phase, complete with all the logic equations for outputs and state changes. After all that it's almost a transcription to ladder.