Programming Style

Doug_Adam

Member
Join Date
Sep 2002
Location
Perth
Posts
948
G'day,

I've been learking here for a few weeks and it's been highly informative.
I've also been programming PLC for the last three years and so now think I'm pretty good at it.
One problem though has been bugging me.
Are there any sure fire, gaurenteed methods of getting a working PLC program first time, every time?
It may take a bit to gather my thoughts - so please be patient.
When I first started out, I was with a manufacturing company that did all it's own in-house engineering. Their main programmer (and chief electrical engineer) had the following technique:
1, Design the hardware.
2, Have it built.
3, The weekend before commissioning was about to start, furiously begin writing the program.

Now the problems with this technique should be obvious, but with his years of experience and obvious talent he got away with it.

My technique was a bit different. I would begin by planning things out on paper before I began coding. This would take time up front, and was actually less successful than the old guy's method, mainly because of my in-experience.

Both of us ended up with buggy programs that needed months to get to an acceptable level. Since that time, I have been refining my techniques, but they are not there yet.

I am now working for another company that normally employs contractors for this job, and it seems that the contractors seem to be little better than my first experiences. Often I end up doing a fair bit of de-bugging of their code after they are gone.

This seems to be accepted as normal, but I am not happy with how things are going. So, to all the PLC programming gurus out there, is this normal?
Is there a better way?
Are some people able to get good, bug free code working consistanly first time?
Especially one machine is different from any other?
Are there techniques for this?

I may have rambled a bit, but any ideas or comments will be welcome.

Thanks in advance,

Doug
 
I don't think there is a way to get version one to be golden every time. If you start with an operational description that is written very clearly and logically in human language first, you should do well. Flow charts are good too.
When I design a panel, I have to start with specs. They usually have an operational description. From that, I figure out how much and what kind of hardware to include. From there, I design the hardware. Then I have the panel built. Then I program it.
 
We have built a rolling cart with rows and rows of toggle swithes and lights. After the panel is built, we connect the inputs and outputs to them. We connect any operator interfaces or special devices to the panel and set them on a bench. We are able to simulate the entire machine, including some alarm conditions that would be difficult to create on a live machine. I am able to be pretty confident of my code by the time it goes live.

The only other way besides the preparation that you seem to already go through is experience and a libray (physical or mental) of proven code.
 
I used to use those switches and lights setups, and they work OK. But if you've got lots of devices with lots of feedbacks, you often have to work quickly to toggle the feedback when the light comes on.

Nowadays I put simulation logic in the PLC (or sometimes a PLC that can message to the PLC).

The simulation logic is dirt simple and doesn't require much/any debugging, just

RUN MOTOR_1
MOTOR_1 IS ON
O:0/1 I:1/1
----| |----------( )


OPEN VALVE_1
VALVE_1 IS CLOSED
O:0/2 I:1/2
----|/|-----------( )

OPEN VALVE_1
VALVE_1 IS OPEN
O:0/2 I:1/3
---| |------------( )

SIMULATED
E-STOP E-STOP
B200/1 I:1/0
----| |-----------( )


.
Some devices, like photoeyes and prox switches, can be harder, but not unreasonably so.

I write the code while the panel is beign built. By the time the panel ships, I'll have run dozens of batches.

There will still be bugs, but way fewer.

Good annotation and descriptions reduce bugs too. If it's done right, you can sometimes just look at the code, offline, and see that a typo has been made.

Modular design also reduces bugs. The hard part is breaking the process into the right modules. I'm currently rewriting code where the modules were done very badly, and bugs are everywhere. I think only experience can teach how to break things up properly, but Terry may have some thoughts as to how to teach someone to think in a manner that will yeild success.
 
It's time to introduce the forum to the concept of plane(sic) code.

There are two types of plane code.

Type A plane code is that which you write on the plane on the way to the commisioning site.

Type 2 plane code is that which you write so you can get out of the plant to catch your flight home.

Neither type is particularly good.

I wish there were a bulletproof method to write code that worked perfectly the first time. Doug, you're on the right track to getting where you want to be by writing a functional description or a flow chart before you start writing ladder logic. Over the long term, that approach will pay off.

Experience plays a large part in getting your code running properly. When you have a database (whether mental or otherwise) of things that have worked for you in the past, and equally important, things that have not worked, you can apply the right tool to the task at hand.

When you have a good understanding of how the machine or process works, you make better decisions about which functions should be grouped together.

When you've scratched your head for a couple of hours over what a series of rungs is supposed to be doing, you learn the value of clear documentation.

Time spent doing simulations is not wasted, but be careful that you don't get bogged down trying to make it too detailed. I sometimes carry Allen's approach a step further by putting in timers for each rung. The output starts a timer, and when the timer's 'done' bit comes on, change the state of the input. You can then play with the timer presets to simulate a wide range of operating conditions.

If you're designing an operator interface along with the PLC ladder logic, you should have someone who is not familiar with the program push the buttons and change the settings. You'll be surprised at how many bugs you can uncover that way. When you're testing it, you know the correct sequence to do things and the proper range of values to enter. An unfamiliar operator will do things in more random order, and there may be some sequences that your ladder doesn't handle properly.
 
I heartily endorse the "rigorous" approach of defining I/O, describing functions, identifying alarms and tuning, and outlining major sections (modules) of the program before you start typing the logic. Unless you are a genuine genius (and maybe even if you are!) the "sit down and start typing" approach leads to real spaghetti code.

I am also a big advocate of Steve's technique of having someone else test the operator interface. We usually do the same thing with testing the logic as well. One of the most common problems with novice programmers is that the logic works great when everything outside the PLC behaves as intended, but if things fail or operate out of sequence all heck breaks loose.

We have fairly repeatable processes and equipment so we can do hardware simulation readily, but whether in hardware or software test before you ship. We have gotten involved in projects where other suppliers shipped panels without even a "smoke test" or I/O check. This way lies madness!
 
Tom Jenkins said:
We have gotten involved in projects where other suppliers shipped panels without even a "smoke test" or I/O check

Reminds me of a customer supplied panel we got once that has the E-Stop switch wired across the power supply. Pushing it created a dead short. Funny thing was that the guy who wired the panel was not the culprit, he was just following the schematic, which specified that it be wired this way!... :rolleyes:

beerchug

-Eric
 
Let it rest a while

Hello programmers,

My way is like this:
1-I write code for project A and leave it for a while.
2-I write code for project B and leave it for a while.

While writing code for B I will forget most about project A.

After finishing B, I will doublecheck project A.
I don't think it makes a lot of sense to check a project right after writing it: you are not objective enough for your own writings.


So sometimes while checking, I could come up with: Hell who wrote this!

Like people above:
-Planning
-Flow charts (Even for the most stupid logic): Programming in steps from the Flow charts can make your HMI very easy to monitor things.



In AB I also use the search function a lot when I check programs.
(eg OSR only once, ote only once, otl must have an otu, timers only once, specific bits should only be found locally in a subroutine).



Kind regards,
Birdy
 
Doug (and anyone else interested in this),

I use different designing techniques, mostly grafcet. Most of the time it works almost correctly the first time around, but I have to make little corrections. This is mostly because humans don't think very logically and I, like most of you, are only human.

As far as I know (who am I ;) ) there's no foolproof way to design a program. There are only techniques to make live easier for us: grafcet (not only for PLC, but also useable for electronics, relay circuits and pneumatics/hydraulics), state diagrams, flowcharts, Nassi-Schneidermann charts and even something as simple as a timing chart. My old mentor used to say that programming was done for 80% on paper and in your head and only for 20% at the programming device (or PC). I still use this rule with good results and I try to convince my trainees to do the same. But that last task is a bit of a burden :( .

There's plenty of info on these techniques around on the Internet, but you'll have to use your search engine to find it. I always do the same, I don't keep records of these links.

Kind regards,

Jean Pierre Vandecandelaere
Instructor PLC - SCADA
VDAB
plc.freehosting.net (Dutch only - sorry, no time to translate)
 
I don't think I can claim to ever have a finished program right out of the box first time. My required debug time usually depends heavily on the size and complexity of the application. It can go from an hour or so for a very small job with less than a dozen I/O to weeks/months for large systems w/ hundreds of I/O points, multiple remote I/O drops, multiple operator panels and more complex communications requirements.

First of all, I second what everyone else has said about defining the application up front before coding. Everything needs to be driven from your physical outputs. These are the only part of the application that can actually "do" something.

I also think programming style depends a lot on the size of the applicaiton.

When I have a simple job with a single function and maybe a dozen I/O, I usually use only two program files (I'm strictly AB SLC/500 and MicroLogix here... pardons to other's brands who may not use this terminalogy). One file contains a rung for each physical output point. The other file for the logic of the system (auto/manual switching, auto sequence, etc.).

As jobs gets larger, they usually can be broken down into logical sub-stations. For instance, now I have a dial machine with a 6 station index table. At each station, the workpiece gets a different operation done to it (i.e. Spotface two holes at station 3, debur at station 4, gauge at station 6 etc.). In this case, I use a program file for each station and then organize all the files in the same way. For me, I put interface logic at the top (interface to the rest of the program), then the operating sequence, then physical outputs, then operator display stuff. I also try to modularize data files at this point. (Again, this probably applies to AB more than other types...) For instance, if I'm using program file 6, then all bits related to this file will be from the B63 file, timers from the T64 file, counters from the C65 file, ints from N67 and floats from F68. Notice the least significant digit of the file numbers are the same as the pre-defined first 8 data files that AB dictates. This isn't mandatory by any means but at least it's a scheme that can add some consistancy to things. I also need to credit/blame a customer of mine Don Crawford from Wes-Tech. Corp. who I stole this idea from.

While we're on files, I reserve one date file (B9 for me) strictly for one shots. I use B9's for nothing else and I don't create any one shots that are not B9's. In RSLogix 500 I turn on Tools/Options/Xref: Enable Cross Reference and Display Next Unused Element or Bit. When I need a new one shot, I start typing B9/ and the software plunks in the next unused address from my file. The only time I've had a problem using the same one shot in two places is with cut/paste... be careful. In any case, now I can simply look at the cross ref. for file B9 and check for double use addresses.

If I have a panelview in the system, I always use one data file (B13 for me) for panelview pushbuttons, another (B14) for panelview indicators and another (B15) for panelview alarms... and you might have guessed it, N17 for panelview ints and F18 for panelview floats.

In any case, I always start making an excel file with symbols & comments for all of the physical I/O points, used and unused, on the machine (Unused points get the comment SPARE). If there is an operator interface on the machine, I also try to add all the required bits/register tags in this spreadsheet w/ comments. This helps standardize tag/symbol and comment names between software and documentation packages.

I subscribe to the mantra that no element should be left un-commented. Using spreadsheets with comment import/export features is a lifesaver here especially for large numbers of similar elements. But even beyond that, I've somehow adopted the habit of ALWAYS typing in a comment at the time I create a new address. I don't even think of it; it just happens. Even if you just quickly type in a couple words, at least when you go back to the code, you or more importantly... someone else has a fighting chace of knowing what you were trying to do.

I don't proclaim any of this to be the best way to do anything. It's just some things that I have found help me after doing this for 6 or 7 years.... as they say in the commercials, Your milage may varry :) I'm constantly trying new ways of doing things to see if they are better. Some are, and some aren't. This group and the AB one (rslogixforums.com) have been tremendously helpful in opening up my eyes to new ways of doing things I thought I had mastered!

Nor does a good programming scheme guarantee a stable program. Pretty garbage is still garbage. There is no substitute for experience (learned the hard way or gleened from online forums)!!! When safe, and time permits, try several different ways to do the same thing to find out what works for you and your application. If there was one answer to everything, you'd just read it in Phil's book and this forum wouldn't exist ;-) And..........when you do find something neat or conversly, particularly dangerous, by all means, report it back here to the masses for digestion!

I hope this helps.

Norm Dziedzic
Belden Machine Corp.
Broadview, IL
 
Thanks everyone, I appreciate your replys.

Some of the replys confirmed things I had found, and I found a few new helpful tips.

Now the next question.

I have been tasked to write a standard or guideline on PLC programming for my company.
One of the target audiences are the numerous contractors that we use. This has been a bit of an on again/off again affair.
One of the big problems I have getting this through is a bit political.
We continually get problems with our code, documentation, testing and basic dis-satisfaction that things are not how we want them.
By writing a standard or guideline we hope to improve things somewhat.
However, a common argument that always seems to pop up is that if we add these requirements,
all that would happen is that the contractors will use these to shift the blame onto us if the machine doesn't work.
Primarily, the guideline (I've stopped calling it a standard) is based on having a library of tried and true functions,
and a series of documentation requirements. I have tried to make it as minimal as possible, and to have it assist rather than impede good coding practices.
Also, it addresses only the most common problems that we have, mainly documentation and structure.
The problem is that objections are now being raised that it will restrict the freedom of the contractors and will result in them raising their prices (and blaming us for any faults).

So the questions are:
Has anyone had any experience with PLC coding standards?
Have they been good/bad/indifferent?
Do you think I am completely wasting my time?
Any suggestions of good things to include or leave out would also be helpful.

Thanks in advance,
Doug
 
Well Doug, that's gonna be a tough nut to crack... banghead

I'm sorry to say, but creating your own "standard" for programming will only be followed if YOU do all the programming. There are so many different ways to accomplish the same end result, that "forcing" someone to follow your standard (er, I mean guideline) will severly limit your choice of contractors. Most won't agree, and the ones who do will, as you say, blame you for any problems. If you gave 100 "very good" programmers an identical machine (with the same PLC) to program, you would wind up with 100 different programs, but all would be functionally identical. Everyone has their own method of programming, usually based on how they see it in their head. What you're asking them to do is change their way of thinking. Good luck!... :rolleyes:

I understand your dissatisfaction with the contractors to-date, but the problem is that you only discover the problems after the fact. IOW, you can't see what you're getting until after it's done. A better approach might be to research the contractors more before choosing one. Ask for an example of their programming style, and more importantly, their documentation, so you can decide if it fits your guidelines.

There's no standard way to skin a cat... Speaking of cats, where'd burger-flippin' Pierre disappear to?... :confused:

beerchug

-Eric
 
Actually Eric,

This is mainly why I cut the standard down to cover only code that has already been well proven (in the library, to use it by preference) plus guidelines for our level of documentation and what it should include.

We will also be passing it around our contractors for their comments.

Unfortunately, in my local area it is easy to quickly run out of contractors.
Strangely enough, I was taken to task before for doing the programming for a project myself. The main reason being that if anything went wrong, there would be no one to point the finger at....

Doug
 
Eric's last reply was very true. Give 100 programmers a project and you will definately see 100 different programs.
I do all the design work and the programming for our company so I get to design the systems around what I want to do in code. Lucky that. zzzzz
A small project with 1 or 2 PLCs has the I/O determined when the drawings are done. The I/O cards are drawn with the addresses on the drawings. Generally the code is then just written without much planning.
When multiple PLCs are involved, commonly 8+, a lot of planning is involved. I do all my I/O lists in Excel and then just copy and paste them in to the PLC symbol editor. The most work, where you have to be really organised, is transfer of data on the network.
A lot of planning also has to go into a job the likes of which you have never seen before. Doing a job at the moment on cranes. Using Omron CS1 and Pepperl & Fuchs Device Net rotary encoders. Whole new ball game, sleepless nights, hair going whiter by the minute, note pad by the bed so that when I wake up in the middle of the night with an idea or a "You stupid dope. Don't do it that way" I can write it down and go back to sleep. No pen and paper - no sleep.
Unfortunately, we are all human with as many different ways to do things. I think putting a guide together is bigger than Ben Hur.
Good luck :eek:
 
As an OEM, I have to deal with hardware standards all the time. Only once did I have a standard HMI template that I had to work with.

You are correct in the blame game.
These standards are in some ways a relief for us because we don't get any negative feedback along the lines of "Why did you choose that POS XXX sensor?" because now the response is "You spec'd it." Not that we won't bring up the issue if we feel the spec is inadequate, but it is the customer's decision, not ours.

Another trade-off with standards is that the OEM or contractor may have their own, and you may increase your up-front cost because they will be less efficient and take more time integrating your standard into their program. Of course, you may be lowering your cost of ownership.
Just a few points to consider.
 

Similar Topics

Dear Engineers, I think you can help me with understanding old style PLC code from ABB Prokontik. (DIN 19239) Please see attached photo from...
Replies
2
Views
1,535
Dear all, I was told by my new boss that I need to use state type programming style in the RSLogix5000. I was not have any experience with any...
Replies
20
Views
7,367
Hi I have a question about programming style. What I know is it is better to have a few sub routines grouping the functions together, like...
Replies
19
Views
6,697
Good Evening, All, Let me first apologize for this becoming something of a rant. I have a sort of a style-related question running around in my...
Replies
18
Views
9,160
Hi all, I've been reading up on latches vs seals. I am working with SLC500's. From what I understand, the only thing to be aware of regarding...
Replies
11
Views
5,579
Back
Top Bottom