Hi all,
I seem to have been tagged as the "PLC guru" in the office here, and I've been asked to give a short seminar on good programming practice. This is not to be a "how to program", but more of a high level "how to plan out and structure your program" sort of thing, as there are a few other people here who know some PLC programming already.
Anyhow, since I only learned ladder logic just over a year ago, I thought I'd ask for some comments and advice, not only on what I am planning on presenting, but also on what constitutes good practice. I've done other types of programming for more than 10 years now, but none of it has been, well, industrial, with all the potential personal danger and expensive equipment that implies. Web apps just don't quite have the same repurcussions when they aren't well designed.
Anyhow, here's some stuff I'd like to cover. (I may have far too much or too little to cover in an hour as I haven't done any timing yet, in which case I'll be asking your help in selecting the essentials!) Apologies for the crude formatting, it's sort of a brainstorm.
Also, I'm using GX Developer, so my terminology will reflect that. Since it's the only PLC I've ever worked with, I'm not sure exactly what's a melsoft term and what's a generic term.
-----------
Why use good programming practice?
* fewer bugs/errors to start with due to clear structure
* easier to find bugs that are there
* easier to maintain a few years down the road
* easier to improve later, with process changes
*** changes have to stick with good practice, or even the best program can become a mess!
It seems so obvious - why don't people do it all the time?
* they don't know how
* reading a good structure is easy - developing a good structure is hard
* more time spent at the start, planning instead of programming
** but not spending 1 hour planning means 10 hours more time spent on the actual programming
So how do we do it?
* Program Map - assign timers and data registers and internal relays for all the desired functions
* Based on the I/O cards and P&IDs
* Much more usable if the memory addresses repeat in an easily predictable order - eg rotation of 5 or 10 per item, so timer xx3 is *always* a start delay for every single output. Makes repeating blocks (below) much easier, too.
* Space for expansion or functions that weren't foreseen at design time - don't need a huge amount, but starting with every slot assigned means there's no room at all for expansion
* General structure
* grouping
* ordering
First, it helps to know how the PLC runs the program. It starts at the top, and runs each rung in sequence. (on the order of 5ms, so fast it looks simultaneous to us, but it's very important that it runs in order - allows multi-step calculations and operation precedence)
* This starts from the completely generic. Read inputs - perform operations - write outputs
* We have alarm conditions - insert after "read inputs" because alarms have priority over all else
* Operations are the bulk of the program, and should be organized in a useful way. (which is better - everything for one pump together, or all overloads together/all LP together/all run rungs together...? This is where I know I'll need the most help)
* Commenting
* block comments - a line or series of lines between lines of code
* device comments - a more descriptive name than X03C, attached to each piece on a rung of ladder
* what makes a useful comment?
(block)
"when X03C is on, Y05C is activated" <-- not useful, that's exactly what the code says.
"Gland water valve must be open whenever pump is running to protect seal" <-- more useful, it explains intent.
(device)
"P200" <-- not useful - what's happening to P200?
"pump run" <-- not useful - which pump?
"P200 running" <-- names equipment and signal description. Should reflect what is happening when the device is energized.
* Repeating blocks
* LL/L/H/HH levels
* pump control logic
Much easier to copy/paste code if the device numbering follows an easy pattern (mentioned above), also, debug only once since it's the same code everywhere.
-----------
Thanks for any suggestions you folks can offer!
-Rhonda
I seem to have been tagged as the "PLC guru" in the office here, and I've been asked to give a short seminar on good programming practice. This is not to be a "how to program", but more of a high level "how to plan out and structure your program" sort of thing, as there are a few other people here who know some PLC programming already.
Anyhow, since I only learned ladder logic just over a year ago, I thought I'd ask for some comments and advice, not only on what I am planning on presenting, but also on what constitutes good practice. I've done other types of programming for more than 10 years now, but none of it has been, well, industrial, with all the potential personal danger and expensive equipment that implies. Web apps just don't quite have the same repurcussions when they aren't well designed.
Anyhow, here's some stuff I'd like to cover. (I may have far too much or too little to cover in an hour as I haven't done any timing yet, in which case I'll be asking your help in selecting the essentials!) Apologies for the crude formatting, it's sort of a brainstorm.
Also, I'm using GX Developer, so my terminology will reflect that. Since it's the only PLC I've ever worked with, I'm not sure exactly what's a melsoft term and what's a generic term.
-----------
Why use good programming practice?
* fewer bugs/errors to start with due to clear structure
* easier to find bugs that are there
* easier to maintain a few years down the road
* easier to improve later, with process changes
*** changes have to stick with good practice, or even the best program can become a mess!
It seems so obvious - why don't people do it all the time?
* they don't know how
* reading a good structure is easy - developing a good structure is hard
* more time spent at the start, planning instead of programming
** but not spending 1 hour planning means 10 hours more time spent on the actual programming
So how do we do it?
* Program Map - assign timers and data registers and internal relays for all the desired functions
* Based on the I/O cards and P&IDs
* Much more usable if the memory addresses repeat in an easily predictable order - eg rotation of 5 or 10 per item, so timer xx3 is *always* a start delay for every single output. Makes repeating blocks (below) much easier, too.
* Space for expansion or functions that weren't foreseen at design time - don't need a huge amount, but starting with every slot assigned means there's no room at all for expansion
* General structure
* grouping
* ordering
First, it helps to know how the PLC runs the program. It starts at the top, and runs each rung in sequence. (on the order of 5ms, so fast it looks simultaneous to us, but it's very important that it runs in order - allows multi-step calculations and operation precedence)
* This starts from the completely generic. Read inputs - perform operations - write outputs
* We have alarm conditions - insert after "read inputs" because alarms have priority over all else
* Operations are the bulk of the program, and should be organized in a useful way. (which is better - everything for one pump together, or all overloads together/all LP together/all run rungs together...? This is where I know I'll need the most help)
* Commenting
* block comments - a line or series of lines between lines of code
* device comments - a more descriptive name than X03C, attached to each piece on a rung of ladder
* what makes a useful comment?
(block)
"when X03C is on, Y05C is activated" <-- not useful, that's exactly what the code says.
"Gland water valve must be open whenever pump is running to protect seal" <-- more useful, it explains intent.
(device)
"P200" <-- not useful - what's happening to P200?
"pump run" <-- not useful - which pump?
"P200 running" <-- names equipment and signal description. Should reflect what is happening when the device is energized.
* Repeating blocks
* LL/L/H/HH levels
* pump control logic
Much easier to copy/paste code if the device numbering follows an easy pattern (mentioned above), also, debug only once since it's the same code everywhere.
-----------
Thanks for any suggestions you folks can offer!
-Rhonda