Writing good code.....what constitutes good code to you?

I'm fairly new to this PLC stuff but I have taken some university level programming courses. I've only used AB so I can only comment wrt AB.I see such a wide variation of programming styles and approaches. Of course they all work. Some have little to no comments. Others have no rhyme or rhythm. I have seen rather large programs that have had their MSG files create with no logic whatsoever. Just random data tables with no logical connection to the data. On the flip side I have seen programs that have had their data tables very well organized. For example, all the data being sent to node 6 is sent to data table N:60 and all the data being sent from node 6 is being sent from data table N:66. Anyone care to share what they believe is good programming practices?

Imagine you are the maint. man, it's midnight on New Years Eve and there are about 40 managers/supervisors standing behind you asking why dosn't it work ? Good Code to me is whatever it takes to make downtime a minimum.

Good code=it works!=it is simple to troubleshoot the equipment or system with=it works all the time without hidden bomb conditions(takes good de-bugging on start-up)=it works!=you get to keep your job for a little while longer! LOL had to put that one in there

Several companies have programming standards. There are different programming methods that are commonly used such as counting step by step, sequencer, etc.. Many times the programming method is dependent on the PLC you are using. Sometimes multiple instructions can accomplish the same objective but there are advantages in which instruction is used (memory, execution time, etc..) I know one company that invested a lot of time in developing a standard using A-B processors that was aimed at developing a structure that could be used on most applications. A-B actually participated in developing this standard. It also focused on efficiency of the given processor to minimize memory usage and scan time. Different PLC's give you different tools but all previous threads are true. No one wants to be going through a pile of spaghetti logic when the machine is down. If the program has some basic organization and is well commented, then you have a decent chance in deciphering the code.

Having a state diagram is important to me. A main program that keeps track of the mode of the given machine or process such as STOPPED, AUTO, MANUAL, ESTOP, FAULT, etc.. There can be many more operating modes depending on the application. The rest of the program is controlled by these states so you have a base structure by which to build the rest of it. There may be multiple auto cycles. Fault handling routines are important. What you don't want is a jumble of combinational logic that has no documented reasoning behind it.

What I am trying to coax out of the more experienced programmers is the little things that they incorporate into their programs that make it more user friendly for the fellow who comes behind them and has to troubleshoot the program. Where I work several different individuals have written certain programs or added to the original program and sometimes I find the logic rather confusing. For example, at work we have parts of the program where the description for an instruction is true when the instruction parameters (if you will) are true. However we also have the opposite throughout the program. I can get rather frustrated when I try to trace a problem when we are down. I have come to realize that it is essential to maintain a consistent standard throughout the entire program (obviously). I am assuming that the professional programmers in this forum probably don't even understand what I am asking because it is so automatic for them. Come on guys dig deep and share whatever litle "tricks" you have acquired over the years with us noobs. PLEASE!!!

Most "structure" a program into sections or blocks if you like. Some PLCs make this easier than others.

Even when these sections were unavailable, I used to structure 1 long ladder into sections. I fact, I preferred to have one long ladder as I knew where everthing was in the program due to the structure. Sections or program blocks are an absolute pain sometimes because one has to dive from one section or block to another to find something. One long ladder was easier for me but certainly not for the maintenance people.

I might add that from time to time I still go into a program for the controlling PLC for a power station and happily down and up arrow through the program when trouble shooting. I did the job in 1997 and it is not well documented - my boss at the time would not let me "waste time" on documentation. There was always another job there to make another buck!

Documentation ad nauseum. I had to work with a program last week that had no rung comments and no address descriptions...almost impossible to figure out what's going on. There are many ways to write programs that work (aka creativity) but there is no substitute for adequate documentation for someone who didn't write the program. I personally like to create separate ladders for analog I/O, SCADA communications, HMI tagging and alarms. The first rung in the alarms ladder always contains all the alarms in the system on one rung for quick reference. The last system I did had over 100 alarms so I put them on 3 rungs but it comes in handy since you can see "alarms at a glance".

I like to write my code so that I never have to see it again (after a good debug of course).
PLC code should be self explainatory, heavily documented, and easy to troubleshoot/alter.
Good training of maintenance staff during installation/debug is another part of the jigsaw that seems to be overlooked by many, but I find this is one of the most important factors in making sure that I never look at that code again. Make sure that those people on site that will be looking at the code can understand it's structure and are comfortable with it, the rest is then eaasy for them.

Use Indirect addressing wherever possible, just to help out the field techs.
JMP's and RET's also used whenever possible.
Keep it simple and short.
Map all I/O to Integers. (And Comment)
( I get a lot of the time people calling about " I:0/1 isn;t used anywhere in the program.......what gives?"
Comment everything.
Use a STRUCTURE to your comments. Don't just use arbitrary labels. Use something that means something, and stick with CONSISTENCY.
Try to utilize the TAG-ARRAY format.
Good luck.

I like to be able to read the logic using the element descriptions in the documentation.
ie. IF A and not B then C.

If B is actually a negative condition the description should include the negative. like "Not alarming".

Then I can still read it as If A and not (Not alarming) then C.

We all can recognize a double negative cancels. Makes my life easier.

If you have the ability to set a standard I would try to avoid negative or not logic if posssible. Usually seems to affect faults.

Brian.

I did not see it mentioned here, but one important thing when programming is to organize the program from beginning to end, in the sequence the machine operates. When the parts go in, this is at the beginning of the program. The end result of the operation the machine performs is towards the end of the program. After that, the alarms and programming for the HMI are used. I know all machines can not use this, but for those that can, it makes life easier when there is a problem. I have seen too many instances where somebody makes a change and added it at the end of the program, instead of where it should be. If we have any special i/o cards that have to be set up (we use AD), those are at the very beginning, with documentation as to what they are set up for.

Program to make de-bugging simple. This includes the above mentioned documentation and distinct nicknames. I also personally include in this category:

Organize your bits and registers in a logical format. Group similar functions in a repeatable pattern, for example. If P1 run is C100 and Fault is C101, then P2 could be C110 and C111.

Use standard abbreviations in nicknames. For example, don't call the same device P1 and Pump-1 and Motor-1. Don't call the overload aux contact MCC Fail for one device and OL Trip for another device and Thermal OK on another device.

Avoid one-shots and latch / unlatch instructions, since they can be hard to detect if you are monitoring from a PC. (A lot of guys here disagree with me on this one, though.)

Use lots of intermediate "flag" bits to break down operation into recognizable and manageable groups. If you have lube system and cooling system and motor monitoring bits in series for a single alarm rung you can have ten or twenty contacts to try to look at. However, if you have a "Lube fault" and a "Cooling Fault" and a "Motor Fault" alarm bit, you only need to look at a few bits at at time. This not only makes debugging simpler, it makes diagnostics faster as well.

This thread reminds me of the last thread like this except......................



Where's Terry Woods?

To produce professional industrial software, your time should be spent 90% on the design (specifying, planning, structuring, documentation etc.) and 10% on the typing.....


...OK - maybe a little less typing.....

This thread reminds me of the last thread like this except......................



Where's Terry Woods?

Que pasa com Terry Woods?