Programming Style

[Tom Jenkins]

Standards can't turn a bad programmer into a good one, and at best reinforce what a good programmer already knows. I see lots of specs with requirements that intend to regulate style and quality, and I haven't seen them do much for me.

Now, you can indicate that the program must be properly structured and fully commented, and that the programming be done in a professional manner. That's a bit of motherhood and the flag, really. You could also dictate that certain functions be used, or require modularity and subroutines, or forbid bit shifts or such, but it won't really be enforceable because it's all a question of interpretation.

Rather than concentrate on trying to control programming style and structure, I suggest you concentrate on making sure you get the tools that will make your subsequent maintenance and upgrading job easier. Require a complete list of I/O, a printout of registers with nicknames, a printout of the logic, a copy of the program on CD (with appropriate protection for the contractor's intellectual property rights if appropriate) and a functional description of the program identifying all the major loops and control functions in text. Screen shots for all the operator interfaces is also helpful, particularly if accompanied by a list of register useage. This is useful to you, and not particular onerous for them. It is also enforceable, because final payment depends on geting documentation that satisfies you.

Beyond that all you can do is take a 2x4 to the purchasing agent and make sure they understand that the selection of contractors cannot be based on low price alone. Create a short list of acceptable contractors, and if a new vendor wants on get a list of references and resumes and check them out.

 

[ndzied1]

Doug:

I think your best bet in writing a spec for subs is to stick to a requirement for clear documentation. Make it a sign off point for payment. Hopefully, the people you are hiring are the "experts" at what they are doing. The key is that you have the knowledge and understanding to support the system after the experts have taken their winfall and flown to Tahiti

Good Luck

Norm Dziedzic
Belden Machine Corp.
Broadview IL

 

[Stephen Luft]

Doug,

Does the programming software for the PLCs you use have a run simulator?

By simulating in software first, you would hopefully catch the majority of your logic and timing function errors. This should reduce the number of modifications.

There are usually timing variables with regards to the devices that are interfaced to the PLC that will require some modification.

With regards to your standards question. If you have many people that program, within the company, the task of creating one method will probably be more of a challenge, but not impossible.

Question regarding the contractors and outside individuals that work with your equipment, do they actually need to work with the program or would they be able to modify the parameters of your equipemnt through an operator interface?

If the contractors are hired to do programming, then you most certainly have a dilema. As stated earlier - 100 individuals, 100 different programs.

I would say the first thing to do is have a library of proven code that you know works, so there is no dispute. (which you have already done).

Regarding the contractors that object, create a "preferred contractor list" of individuals that you are certain will adhere to the standards / guidllines that have been set forth. Use this list as your primary source. Only contract from off the list if you absolutly have to. Let the contractors know that you are doing this and that if they want to continue doing business with your company, they will have to be on the list.

If the contractors are hired to do installations, then the logic that you are creating is tested before it leaves the factory, so I would imagine that when the machine is started up in the field, you are mainly dealing with timing issues. These modifications can be done through an operator interface.

I hope this helps.

God Bless,

Stephen Luft

 

[Steve Bailey]

I agree with the others in that I think your time will be better spent in trying to write specifications that detail what you want the control system to achieve, rather than how you want the contractor to achieve it. I wouldn't go much further than to insist on adequate documentation (whatever your definition of adequate might be), and to encourage (rather than require) the use of subroutines and previously proven code. Keep the specification positive (the contractor shall supply...) rather than negative (the use of ..... is prohibited).

Your company and the contractors need to agree in advance on a set of acceptance criteria. You specify that when the system has performed up to its specifications (line speed, quality levels, runtime without shutdowns, completeness of documentation, etc) you will take ownership of it and the contractor gets paid. The contractor will probably insist that you provide raw materials of adequate quality as well as adequate access to the system for fine-tuning during the acceptance trials.

One point that you might want to make regarding style is in the area of the names that the programmer assigns to inputs and outputs. I once had to convert a hard-wired system to PLC control. I had the schematics for the hard-wired control, so I figured it would be a piece of cake, but I found I couldn't make any sense out of one particular mechanism. What I was seeing in the schematic just wouldn't square with the way I knew the machine really worked.

I finally realized that the problem I was having was in my interpretation of the labels that the person who drew the schematic had used. There were a pair of limit switches labeled 'pusher forward' and 'pusher retract'. I figured 'pusher forward' was the switch that indicated when the pusher had reached the forward position. Nope. The switch labeled 'pusher forward' was at the retracted end of the pusher's stroke. It was so labeled because it was the switch that, when it was actuated, caused the pusher to move forward.

 

[Doug_Adam]

Thanks again everyone,

You've given me a bit to think about.
I'll let you all know about the success or failure of the 'guideline' once it's been used a few times (or been killed off).

Thanks again,

Doug

 

[Mike Williams]

Learn to use all instruction set's with every plc you can get your hands on. Then develop the style of programming that you are comfortable with. A programmer has to adapt to alot of different PEOPLE! The reason I say that is because when you develop your way of writing code, at one time or another you will run across people that will say "I DO NOT WANT ANY OF THAT THERE MOVE **** OR BTR OR BTW etc...... I WANT SIMPLE OLD LADDER THAT MY PEOPLE CAN TROUBLESHOOT WHEN YOU ARE GONE! Just my 2 cents.

 

[Allen Nelson]

Doug:

Can you circulate your Guidelines to the contractors that inhabit this area (i.e., post them here?)

While I agree with Tom that End Users standards can be, at most, little use - at worst, a pain in the posterior, standards for an OEM or Integrator can be highly useful.

At one company where I worked, there was a standard data table layout and style of coding for (almost all) projects. I got a phone call one time from a customer about a project that I knew next to nothing about. The engineers for that project were out of town, and all I had to work with was the ladder that was on the network.

But because I knew how the project was laid out, I was able to pinpoint where the change had to be made, and had the customer back up and running in 10 minutes over the phone.

Although I've never seen a customer guideline that made my job easier (to be useful, it must be specific; to handle every type of project, it must be general. Since it can't be both, it winds up being confusing and hence ignored), I'm always on the lookout for good ideas for proven code. (I'm an equal opportunity plagiarizer).

Who kows, if your ideas are good enough, they'll make it into my standards, which will get copied to other peoples standards. Eventually, they might become commom usage.

Impossible? It's getting more and more common to run into AB PLC programs where B3/0 is ALWAYS_OFF and B3/1 is ALWAYS_ON. I do the same thing (and use the same data file, B9, as ndzied1 does) with one-shots. Simultaneous evolution, or rampant plagiarism? Don't know - don't care. And with the idea posted here, perhaps others will copy it and spread it.

I can't hurt.

 

[Eric Nelson]

Excellent Idea Allen!...

It's getting more and more common to run into AB PLC programs where B3/0 is ALWAYS_OFF and B3/1 is ALWAYS_ON. I do the same thing (and use the same data file, B9, as ndzied1 does) with one-shots. Simultaneous evolution, or rampant plagiarism? Don't know - don't care. And with the idea posted here, perhaps others will copy it and spread it.

I can't hurt.

For no particular reason, I have always used B3/0 as my "Always ON" bit, and just NOT B3/0 as my "Always OFF" bit...

But, I would LOVE to have a set of "common pratice" guidelines to follow. Sure you don't HAVE TO follow them, but why not? For example, as stated, most programmers like to keep all their one-shots in one location, but that location is up to the programmer. If I had a reference sheet that said "Most programmers use B9: for their one-shots", then I'd most likely say "Hmm, B9?... sounds good to me"...

Sometimes there's even a logical reason to select specific areas. See the third pharagraph in my post from earlier today. I didn't HAVE TO do it that way, but it sure made my life a whole lot easier.

I think we'd ALL like to see your preliminary guidelines, Doug. We can all comment on (and, of course, argue about) the good and bad points. Perhaps we can even come up with set that everyone ('cept maybe Terry ) agrees with?...

Most of these guidelines will probably be "brand specific", but there's no reason that the general idea can't be be applied to other brands.

I am liking this idea a LOT!!! Anyone else?

beerchug

-Eric

 

[Goody]

I would say that most programmers that have been programming for a long while become statndardized without really knowing it.
The way you group your internal bits, one shots etc. Which bits you use for what.
I reckon I could identify any program I wrote years ago just by how it is laid out.
But we are all ready to plagiarize someone else if we find something in others style that we like.
I recently saw a program where all the statements down the left hand side started and ended with 2 back-slashes eg
\\ This is what this line does \\

It is only a little thing but I liked it.

 

[Allen Nelson]

Re: Excellent Idea Allen!...

For no particular reason, I have always used B3/0 as my "Always ON" bit, and just NOT B3/0 as my "Always OFF" bit...

Eric:

It's true that, while those first two bits in B3 are often used as ALWAYS_OFF and ALWAYS_ON, there is little or no consensus agreement.

The reason I settled on B3/[B)0[/B] as ALWAYS_OFF and B3/[B)1[/B] as ALWAYS_ON is for the mnemonic "0 is OFF; 1 is ON".

I'll do similar mnemonics for other data table assignments. Outputs from the PLC to the HMI/SCADA (or other) will be in data tables ending in '0' (N40, F50, etc). Inputs into the PLC from outside will be in data tables ending in '1' (N41, F51, etc). This way, I can tell, just from the address what's going on with the register. It keeps data packets grouped together (which used to be more important than it seems to today).

An exception to the above is N11. I use that as an INI file (INI = N11 - I use mnemonics wherever I can.)

That's just data table layout (in AB, of course). As far as code goes, we share code all the time on this site, but usually one routine at a time. I'm hoping that Doug Adam has LOTS of code to share.

 

[violin]

My approach

I would like to add my approach.
Usualy the person or people who is writing a code for a PLC and the one who is impementing the hardware is not the same person if the project is large. As far as I understood you have been in PLC programming for quite a long time. The catch is almost allways that you are implementing, writing a code for the plc based system where the technology is already given. If this is the case the company already has documentation which is absolutely describing the system you are trying to "put under control" using the new way. I have met almost always this situation. Now if you have enough hardware knowledge say had used a screwdriver for a long time, you maintaned equipment, repaired things then you should know the most usable approach.
I want to say that:
-First you must know what are the devices for, how they work and how are they wired. The wireing is very inportant!
-The second thing is that you should have a technician or electricians or tecnhologist "close enough" when taking previous things in account, studying the already known technology.
-The third thing is that you have to, if it is not declaired in advance, find out (I am outlineing that this is the case only if the techical system is already given, existing for say ten years already) if there were any modifications in wireing or measurement devices in the past but not stated in documentation.
-Now comes the most important thing (this is my oppinion and the oppinion of other programmers ,who are by the way quite expirienced I have met. On of them is in PLC programming for 20 years and has maintaning experience the same). You must understand how the system works or if you have nothing of the documentation, for example you should design the entirely new system, how it should work. Now you I hope understand why I outlined the importance of hardware knowledge. Even the knowledge of the technology say chemical you are automating is important but usually not necessary (that's why the technologiests are for).
-Now comes the paper work. What is you should do and take in consideration? You should gruop, if they are not already, the various tasks if this is possible or necessary. For example in a chemical factory's plant there are many tecnologicaly important and classified sub-divisions. This a great help in designing. First when doing paper work outline rough, deliberatley not precisely defined flow charts. If you have some programming experience in at least one of the major programming languages (C,C++,Delphi, Visual Basic etc.) then this should be simple. And then test in on paper (!) in a manner if here a signal then does the following happen? If the process is slow is the PID action correct? If it is quick did I use PI action or I have mistaken and put PID action everywhere? If on level value very high did I put an alarming message visible? If answers are: yes I did, this part is O.K., I didn't take that in consideration but now it is corrected then draw the detailed flow chart where everything is declaired in words understood by everybody. Then take the technologiest by the tye and check this flow chart together or compare your things with the documentation which you previosly asked to be handled to you.
-And now programme your PLC and now take in consideration what should be programmed in PLC and what should be designed, if necessary, in the supprvisory program package.
-Then test it on the field. Everything, every part of the program which doesn't work or works not sufficiently good put on paper, every detail which can not be solved by you in ten seconds.

At the end I want to tell you that it is impossible to write such a good code, programme that would work without modification in whatever programming languge at first testing and being at least moderately complex. I am sure of this. By the way I myself have programming experience on various fields, wrote even games using Turbo Pascal and Delphi, programmed Intel microcontrollers in assembler etc. This is apsolutely the situation at everybody. Don't be sad, shy if you think that when you have 3 years programming experiance in PLC field and see someone that he is more proffesional than you are. 3 years are lot but don't worry.
I after all just wanted to let you know how it works on field. And I hope the oulined concept will help you or anybody who will read this.

 

[tadg]

I believe there are guidelines you can firm up into standards.
I looked after a large plant got fed up with myriads of styles so after a while and too many late calls asked contractors to follow some of the following at a minimum,

English (you'd be surprised at how many blocks, with comments, get copied from the project in germany or wherever)

All blocks or sections to be commented completely
No indirect addressing of outputs or inputs,
All I/O addressing to be unique, direct and bitwise, as most troubleshooting starts with 'sensor I 0.3 not working......'
Only 1 level of indirect addressing (no S5 Do DW0 Do DW 0 L DW 0, only Do Dw 0 L Dw 0)
No indirect calling of blocks
All parameterised calls to have max 6 parameters, gets hard to follow otherwise,
All I/O to be assigned a symbol, or labelled spare. Similarly for all internal memory.
No unused blocks or subroutines to be left in file.

Minimal use of set, reset, try to get all bits as = with unlatch, this forces writing in one area only and is easier to troubleshoot. Try a system where the same bit is set in 5 places, and reset in 10....

use of correct number formats, some clever people load bit patterns in hex formats, you don't even look at it in a trouble shoot until 2 retries later...
All indirect addressing to be carried out in defined routine blocks.

The project manager buying machines/plant must stress to the vendors that your system will have to be followed. They'll ask for more money and this for you to discuss with them. It is your price for getting out at 6 pm instead of 9 pm some evenings....
All contractors will discuss the rules with you and evantually accede, once they know you check their code at installation and rework is their own (prewarned) responsibility.
Don't ever accept - "this is our standard way, it can't be redone"-
all code can be redone in a simpler manner and memory is relatively cheap compared to commissioning and debugging time...

 

[Peter Nachtwey]

Thankfully, I am not so limited.

No indirect calling of blocks

Ouch! you just eliminated object oriented programming! Jump tables in state machines etc.

 

[tadg]

Didn't mean to eliminate object oriented.
Object oriented can be done with direct calling of object handling block with parameters/elements passed in to it and retrieved from it.
more hardware memory and an amount of careful copy/paste/replace work involved but easier to trouble shoot for programmers who have to maintain the system,

Just some ideas for the poster, only meant to help his standards document.

 

[chakorules]

I have standardized our programming "method" as a way to easily share projects with other engineers within our own company.

Let's say I start to write some software and I get sick, engineer #2 can just jump in my seat and finish the software because we have defined a programming "method" or standard. We are about ready to change our standard to something totally different, but as everyone else has said, define what you know, and then stick to it. Keep writting code to that same structure and then those in your company will follow or then it will become easy for your engineers to trade projects or go on field calls to other machines because all of you have a standard you follow.

So what I am trying to say, is that it's not a waste of time to come up with a standard.

We have some standard logic that we save in TEXT files:

Open RS LOGIX, start a new BLANK LINE, double click the line. PASTE the below code into the command line in RS LOGIX, hit enter. "Auto Magically" you just wrote code for one of our standard modules.

Here is a sample:

SOR BST XIC NXB XIC BND XIC XIC XIO OTE EOR SOR BST XIC NXB XIC BND XIO XIC OTE EOR SOR BST XIO NXB XIC BND XIO XIC XIC OTE EOR SOR XIO XIO XIO XIO XIO OTE EOR SOR XIO XIO XIO XIO OTE EOR SOR BST XIC XIC NXB XIC BND XIC OTE EOR SOR BST BST XIC NXB XIC BND XIC S2:4/5 NXB XIC XIO BND OTE EOR


Good Luck.

PS if you want, follow the link in my sig to download some sample code.