Examples of bad programming

[A_G]

This week I ran into a customer program that repeatedly used an XIC bit named Off. There was no destructive OTE or OTL setting this bit to actually be deenergized off. To make it even worse, the bit was actually toggled on, energized. What a mess cleaning all this up. I had to come here to vent lol. Anyway I would be curious to read what bad programming practices everyone else has seen in the field!

 

[A_G]

To fix the example above, I would have a OTU instruction for the Off bit or use an AFI instruction instead. Allen Bradley PLC

 

[I_Automation]

I don't think the forum server could handle everyone posting everything they have come across written by some recent graduate that knew everything or someone that was having a stroke while he was still programming.


I know personally I could list things until I find the limit here about how long a post can be (even though it doesn't seem to be set)

 

[dmroeder]

To fix the example above, I would have a OTU instruction for the Off bit or use an AFI instruction instead. Allen Bradley PLC

Not a fan of AFI's personally, I don't like the fact that they generate warnings. Of course, that can be disabled, since it is a setting per machine, I just create a False bit that can't be toggled.

 

[Ken Roach]

When I add a test feature or temporary workaround to something, I always preface the tag names with my initials, so I can easily take out the logic when I'm done, or remove my initials to leave the good logic in place.

But I wasn't always disciplined about taking it out, or also putting in initialization logic.

A few weeks ago a customer came to me with a problem in a system that had been running well for 5+ years. Sure enough, we found a boolean tag in the True state labeled "KIR_Test_Cycle1". Somebody must have poked a value into it during troubleshooting, because once we toggled it off the machine began normal operation again.

I could have avoided that by putting an OTU into the Initialization routine so that an ordinary power cycle would have un-done that mischief.

 

[JTCat]

Not a fan of AFI's personally.

Same.

Client calls. Motor won't turn on anymore.

Motor is programmed to run using OTL/OTU on the true/false of the run command. No idea why instead of seal-in logic, but hey, it's their machine and their programmer.

Their "engineer" was trying to create a test routine for the PV so people could run the machine through the motions for PM purposes. Noble of him.

His whole test routine turned everything on using the OTE's and not the OTL/OTU for the normal run mode.

He AFI'd the OTE's "because he wasn't finished yet" and didn't understand why his OTL/OTU won't work anymore.

He knows now why they don't. But if he forgets, that service call minimum is just a phone call away.

 

[JaxGTO]

I HATE MONSTER RUNGS!


Oh, and AOI's or Indirect addressing that is unnecessary. Just hammer in the rungs so can find an address!

 

[GaryS]

I would be very careful there, without understanding the full system you could make a big mistake.
I use unlatch without a latch often.
I set the bit from the HMI and after it’s done doing what’s it should in the program I unlatch it in the program. That way I don’t have to be concerned about it in the HMI program. All I need to write to the tag is True
There are other cases where it could be used as well.
Without understanding the full context of the what’s going on you could crash it

 

[parky]

Before PLC's had as standard bits like first scan, always on, allways off I would create them i.e. a oneshot or combination logic on the first lines of code & call them First scan bit, Always on, always off, True on & True off etc.
Only ever use always on or first scan bit in the program as some FBD code requires a TRUE on it (some IDE's have a TRUE statement but in reality it uses the inbuilt always on).
When the program has been tested I remove any True on & True off as if any of these were used to temporarily force or disable bits of code for testing purposes they could easily be found & removed.

 

[Ronnie Sullivan]

Mine was a mattress making machine.
It assembled springs to form a mattress base.
The programmer had completely missed out any error checking.

If a misshapen spring was put in and the binding wire couldn't get through
The machine stopped and the operator put it in manual to wind back the binding wire and replaced the faulty spring.
An encoder kept track of where the binding wire was and would be on its way again.

But! If the operator wound the binding wire completely out - the encoder gave a minus number.
The program had no way of resetting the number to 0 and it had compares that allowed it to run (but not minus numbers)
The machine was now basically dead.
Not a hard problem to fix but it came to light that the original manufacturers had gone bust and they had made 500 of these machines. (all with the same problem)

It was quite rare for the operators to wind the binding wire (called a helical) all the way out but when they did, the machine was dead.

I got calls for years from all over the world as one by one they broke down.

I made a lot of money though so I'm not complaining.

 

[Peter Nachtwey]

I was at a furniture plant near Appomattox VA, As usual, the motion controller was accused of crimes it didn't commit. The motion controller was being controlled by a PLC5. At that time I had little experience with a PLC5 but it was easy to tell why the program wasn't working. The programmer had used just 5 or so one-shots and used those 5 over and over again. Not good. Sometimes it worked and sometimes it didn't. After cleaning up the one-shot problem everything worked well. I just tuned up the motion controller a little and left.

It always p!$$ed me off that the motion controller gets blamed when there are tens of thousands of them out there running fine and their one-of-a-kind kludged machinery and programming are assumed to be perfect.

 

[Corsair]

Good or bad programming is not indicated by how well the machine performs the activity that it is supposed to perform under 'normal' conditions. As hinted by the previous posts - it is indicated by how well the machine handles things when conditions are not normal. Mid-cycle power failures, sluggish mechanical components, low air pressure, failed limit switches, and so on. Sometimes you spend more time programming for the contingencies than programming for the desired process.

An IBM RPG programmer friend of mine used to say that he hated PC serial communications because you had no control over what was coming at you down that line - and you had to allow for anything. That's the nature of the world that PLC programmers live in. Nobody can truly allow for everything but there are several steps that you can take to stabilize your world. A lot requires familiarity with the instrument that you are playing - guarding against mid-scan data changes from IO or from communications, proper handling of power-on and emergency stop situations, and so on. Careful selection of data types and sizes is really important.

Don't beat me up for this - but my PERSONAL opinion is that there tends to be more bad programming in AB PLCs than in other brands.

Reason #1: The biggest reason is their US popularity. More novice programmers are put into the AB world than the other brands. So many that proclaim to be experts because they've had some AB training yet they have no knowledge of the fundamentals of programming. Can't fault AB for this!

(Knowing how to program and knowing how to enter code into Logix are two very different things. Don't assume that my generation is not tech savvy because I don't care to know how to post to Facebook on my cellphone. My generation invented the Internet!)

Reason #2: Company policies and AB hype that push for ladder logic for everything even when it is a bad choice. Obscure brand-specific instructions that were designed to do things in ladder that never should have been done in ladder.

Reason #3: Minimal or non-existent enforcement of data types. There's data size and type conversion warnings in my C compiler that make me think before typing in a data type cast. How come the PLC people think they do not need that?

(My understanding of the ADA programming language is that it required permission from Congress to do a data type conversion. This is a gross exaggeration - but the designers of ADA may have had some valid reasons for hand-cuffing programmers.)

Reason #4: Confusing the quality of a code editor (AB is the best) versus the quality of the programming language implementation (another issue). We could burn up megabytes squabbling about this one.

- - - - - - -

A side note:

Years ago (35+) I was presenting a paper at the ESD - Engineering Society of Detroit - PLC show. The massive AB booth was crowded with people. A little observation showed that a substantial portion of them were AB or distributor people. They were making plastic pyramids.

Not far from the AB booth was a small booth with a guy that had a combination PLC/HMI/Motion controller. Nobody talking to him. He commented that he had a solution that could do really well and do it very economically if properly applied to a situation that suited it. He sadly said that the American market bought on name and not on suitability for the function. Nobody really cared about cost or ease of application. He believed that the European market - at least at that time - was more open to alternatives.

I don't remember if I told him the old saying ' 'You never get fired for speccing IBM'. Still true today with AB, probably more than ever.

Fortunately for all of us in the US AB has done some really good things in many areas, especially communications protocols. They seem to have had the size and clout to push a pretty good mostly open communications standard. I'm glad they did.

 

[geniusintraining]

Examples of bad programming

Just about anything I have ever wrote....

 

[glennz]

Just about anything I have ever wrote....

Just about everything I didn't write....

 

[I_Automation]

Just about anything I have ever wrote....

I've done that. Open programs I wrote 20 years ago and wonder how it worked or how someone didn't get hurt.