Good programming practice

Rhonda

Member
Join Date
Aug 2005
Location
Vancouver
Posts
27
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
 
Rhonda,

First I like to say for one year programming….Very good, I would like to be there. I’m sure I could learn more then just from your post.

The only thing that I think you could use, besides more detail (I’m sure you are doing that) is consistency, that has been one of the things that would be very beneficial, not just with yours...but throughout the company, try and stay with a similar style, (addressing, description, etc.) a standard would be nice

I do that here, there are several things that I would do different...If it were up to me and we were starting over, but everyone knows and expects it to be that way so I try and keep it that way, especially when it comes to my touch screens

I’m just getting into Mitsubishi so I cant get very specific.

But it looks good.
 
Object Orient your program.
Hoist_N
Hoist_S
Trolley_N
Trolley_S

All operate in basically the same way, so you can use / reuse code to handle the functions, and troubleshoot quickly.
 
geniusintraining: consistency, good point - both within the program and between different programs. We don't have many plants operating yet, so we have some room to work on what we want the programs to look like, but that's definitely something to mention. It will help a lot to have all of the people who know programming able to work on all of the plants!

CroCop: that's definitely something I'd like to mention. I started a bit with it, in terms of repeating blocks of code - I used the pump logic as an example, but more examples of things that work the same way and can have the same logic would be good to have.

I'm not sure if "object orient" in ladder means quite the same thing as in other types of programming, however... I haven't even figured out how to do a function, so I can write the logic once then pass in parameters and have it do the same operation on a different piece of equipment. Always in other programming I had been taught that copy & paste programming is bad, and to refactor the code so it has functions & procedures, but in ladder copy & paste programming seems to be the way to go.

I'm not planning on getting into how to work with ladder, as this isn't a PLC programming tutorial, although I will probably use some in examples. I only mentioned Mitsubishi conventions because I don't know what's a specific term and what's common to all PLCs.

Thanks for the comments!

-Rhonda
 
Rhonda...

I should think that you would want to stress "modularity". For any given process, that process can be broken down to a number of sub-processes. In some cases, depending on the extent of the process, the sub-processes might be broken down to sub-sub-processes... and maybe further.

Each sub-process is a module. Any sub-process module might contain a number of sub-sub-process modules. Each module is generally a stand-alone piece of code. That is, that section of code might very well be able to run simply based on physical Input conditions... however, that is NOT a good idea.

Imagine this... somewhere in the middle of the physical process there is a limit switch. What should happen if you reach out and trip that switch? Should anything happen at all?

If the module associated with that switch is truly stand-alone, then the particular code associated with that limit switch will execute and any number of activities will occur.

Should it be that way??? I think not.

Modules should NOT be totally independent! Any given module should be "dependent" upon at least one other module. The first module in the process should be dependent upon the second module.

This "dependency" should be in the form of "flags" or "messages" between modules (actually, they are nothing more than "bits").

The first module might process a part, however, it should NOT pass the part to the second module unless the second module indicates, through flag or message, that it is waiting for a part. Only then should the first module pass the part. At the same time... the first module sends a flag to the second module indicating that the part is coming!

If the limit switch we talked about is associated with the second module... then, being forewarned that a part is coming... the second module can and should respond to the activity at the limit switch.

However, without first receiving a message indicating that a part is coming... any activity at the limit switch should be ignored! And of course, without receiving a message indicating that the second module is waiting for a part the first module should not have sent a part in the first place.

As time goes on and the program is modified for various other functions, then the modules associated with those new functions are inserted at the appropriate place. Then the "messages" have to be modified to meet the current situation. Generally, messages should only exist between subsequent modules.

The main idea in this is to eliminate any module from having to monitor any number of input conditions that are normally associated with other modules. Once receiving a message indicating that it is OK to do such-n-such... that should be enough!

All of that was based on normal activity in a particular process. This is not a rigid scheme... there are many different application dependent versions. However, in general, the concept is the same.

In many cases there are conditions that require a message to be "broadcasted" to a number of modules at the same time... perhaps a fault, or E-Stop condition... as always... it depends.
 
Terry, thank you! Those are some excellent points.

I'm working with a chemical plant, so movement of our product through the process is continuous instead of discrete, but I'm sure there are some suitable examples for this concept.
 
One standard I would have loved to have implemented would be the alarm bit on or off.
Most programs I see use an alarm coil on to indicate an alarm, but many use a coil off to indicate an alarm.
I know of a few reasons to do it each way but I have even found it used both ways in the same program. (ugghhh!!)
I generally try to redocument the 'Notalarms' to try to help make sense of it. Pick one way and make it the plant/company standard if you have the power.

Brian.
 
Rhonda,

I have had the opportunity to work behind, and with some very talented programmers. They all have a few things in common.



1. Documentation.

2. Organization.

3. Communication.

4. Consistency.

5. Instruction vocabulary and programming skill.



Individual style varies widely, but the good ones stand out. I have refused to change programs that I knew were well written. I have also completely rewritten programs that were hopeless and haphazard.

 
I see a lot of programs come across my desk. Some are extremely well written and documented, others well...

I'd like to stress PLCHackers post. I'd move Consistancy to the # 3 spot or perhaps higher, but he is right on. The first four things are the key to being able to pick up a program and instantly troubleshoot it vs spending hours trying to decipher what that timer is actually doing being triggered by a rising edge contact.

Number 5 is important, but it tends to come along with experience. The inverse of this is using programming skills that are too far advanced for the folks that will come along and troubleshoot it later. Using indirect addressing and a For/Next loop when a simple series of comparisons would suffice is an example of being too elegant in your style.

I have always used the KISS principle in my programming and HMI design. When possible I program and design for a typical high school graduate. If I can give my program to someone who only understands the basics and they can follow it, I know that almost anyone can. It makes it a bit harder on me sometimes, butI only have to do program it once. I can guarantee that it will be looked at many more times in the future and anything I can do to make it easier on the person coming along behind me, the better off it is for all of us.
 
I have found that most programming that is necessary to perform an action (enable) is fairly easy to visualise and write the ladder logic for. What has always been a problem for me is to visualise and write the ladder logic for preventing an unwanted action (inhibit) when abnormal inputs or combinations of abnormal inputs are present. Good practice would be to try to simulate these abnormal conditions and to include the code necessary to avoid unwanted outputs as well.
 
Icky is right on.

I see stuff out there that no one can understand and the programmer is proud that he wrote it in such few lines.
People forget or don't care that these machines are repaired by folks that have minimal program skills.
 
Silver: I see what you mean! I've also seen it done both ways. I've even done it both ways, based on what made sense at the time... not very consistent I'm afraid. (I never claimed to know good practice!)

Most alarm inputs (motor overload, etc) that I've seen were NC, so when they go out something's wrong - broken signal wires included. I've also programmed a few things that way, although most weren't called alarms, they were called "limits proven" - if it's lit up, we're good to go. About the same as an NC alarm, I realised just now, but "NOT" logic is harder to wrap your head around, so we call it LP instead of alarm.

I may see how to make other alarm signals NC without confusing things. We don't have a company standard yet, so I suspect that if I can defend a technique's utility I can get it in the future standard, if ever one is written. :)
 
plchacker & icky... consistency is definitely one of the things I'm going to try and push in this little workshop. I've learned that lesson in my other programming... sometimes being too clever in the code is a bad thing. Now I try to program so that I will be able to read & understand it 5 years down the road, after having not looked at it in all that time.
 
Rhonda...

It was only the example that I showed that was for "discrete parts" as opposed to a continuous process (in the sense that you are speaking).

The concept behind modularity is for ANY and ALL Processes. The "modularity concept" resides in the program. It matters not whether you are incrementally passing parts, or continuously passing processed fluids (hmmm... there's a picture)... the modularity concept corresponds primarily to the coding used to control the various devices in the process.

Even if you choose to control your process with sub-routines... which I generally stay away from... you still need to organize those sub-routines in a modular manner... unless your sub-routines (more likely, sub-sub-sub-sub-routines) happen to describe the specific device. While that is do-able, and it is not unheard of, it's not very practical.

Program-Modularity exists for human-benefit. It is totally process independent. The particular process doesn't matter... not one whit.
 

Similar Topics

I'm looking for some starter kits but there aren't so many on the market, so I'm thinking about buying individual components for my needs. I just...
Replies
15
Views
2,370
Good Day Friends! I really want to advance in PLC Programming like our guys here in this forum, and I'm Pleading to all friends here to help by...
Replies
5
Views
2,719
hi al.. i am a bigginer to plc programming..ladder logic can anybody pls suggest the best programming practices using in industries..
Replies
21
Views
5,156
Morning folks--I have been programming in RS 5 and 500 for quite a few years. I need to get proficient in navigating in 5000 and I would like to...
Replies
3
Views
1,785
Hi, Following a large project our company recently finished, I would like to ask what is the best method for object oriented programming. We...
Replies
10
Views
12,376
Back
Top Bottom