Examples of bad programming

[muusic_man]

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

Yup.

 

[Manglemender]

I'm sure we all have programming skeletons in our pasts!

A personal hate of mine is the use of latch/unlatch in sequence code. Too many times have i visited machines to find a sequence "stuck"; particularly if a sequence is interrupted and then resumes or some other anomally.

I once visited a machine in Italy to add a bit of code to freeze part of the machine operation while an automatic crane did its thing. A message would appear on the computer screen to inform the operator so to test this I linked it to the lamp test button. The machine was half way though an automatic unload sequence when I pressed the lamptest button. it took 4 hours to recover the machine - another missed flight home.

A few months after this I flew to Belgium with only an overnight bag to replace a damaged sensor and had to spend an entire week putting a machine right - it was the same original programmer.

 

[parky]

@Mendlemanger, /i feel your pain with that one
I was called in to a suplier of strapping machines, this was the UK arm of an Italian company, all these machines were made in Italy & in the UK sold via the UK company within the UK, The spec from the purchaser required the pallets to be measured, in length, if the pallet had runners on the bottom (apparently some had a bottom runner & others had just blocks, the idea was to measure the pallet length (encoder), check if runner boards (this will determine if strap feed swords are to be deployed or if no runners feed strap directly underneath( faster operation), depending on the pallet size would determine the number of straps required & if cross strap is required (cross strap only on pallets that are less than a certain length), so in all there were probably 25 strap pattens, checked when in position that the the swords could go through the gaps, if not it would move the pallet forwards & backwards a few times, if swords were blocked then stop & alarm, the original machine the operator had to select the type of pallet i.e. they were pre-defined movements in the strapper), the customer wanted this to be automatic, so the UK company called in the Italian engineer who programmed it, after a couple of weeks I was called in to back him up, even he could not get it right, he had also used hundreds of set/reset bits, it sort of worked but I was not happy, it went to site & the customer was not happy, another Italian engineer was called in & again I went to site with him, we really struggled, everytime we did a mod allsorts happened at one time the strapper started to do a dance the swords were going in & out the ghead going up & down & strap feeding when it shouldn't we did hget it better but still a bit flaky, a few weeks later the customer told the supplier take it out & sort it, I was asked to completely re-write it (could not while it was in production), I just junked the old software & completely re-designed it, went to site & appart from the odd few fiddles had it running.
I have nothing against SET/RESET but in this case did not use any at all, it was done on sequences using values, plenty of spare steps between each step should it be required to add extras, I know it ran from 1994 till 2003 without incident until the company closed, indeed after doing that the customer who purchased the strapper gave me quite a bit of other work, the UK strapping company also gave me projects to convert two other ones they had supplied to another company, slightly different operation but in essence similar
If I do use SET/RESET I will put the reset on the next rung or at least within a couple of rungs of the set so it is easy to find, however, I have not used them much in the last 20 or so years.

 

[arpus4KM]

Since I get the express pleasure of dealing with a lot of older systems I get to see some very professionally built OEM machines that were obviously programmed by someone who had the right mindset. No possible way for the machine to get stuck in a sequence, or stop working randomly. Easy to recover from jamups or breakdowns.

But, I also get the pleasure of dealing with some real stinkers. For instance, an assembly machine that the OEM had built correctly and programmed well. Once the customer had it they decided they wanted 2 of them and had their machineshop spin up to create the machine in duplicate as best they could, but they also tried to just copy the program over. This resulted in the machine not working well at all of course, so they called in a third-party programmer to reprogram the machine and instead of removing the old logic and re-writing as much as possible, he just disabled some rungs and made others true 100% of the time with empty branches. I guess the idea was he didn't want to delete the old logic in-case something didn't work but he never removed any of the changed logic so the program ended up with a lot of dead ends and would frequently get stuck when an OTL would stay on and not have a bit to turn it off anymore.



Another good instance is when I run into sequencing done with OTL and OTU exclusively... But because they are squeemish about how their logic works they end up throwing OTU for every...single...bit... at the top of each ladder.
At this point when everything is OTL and there is an always on OTU at the top of the ladder, it's basically just an OTE. At first I didn't think he understood what he was doing until I looked more and realized he REALLY had no idea what he was doing. It appears he wanted to use OTL and OTU because he realized using OTE meant he couldn't use 20 instances of it, but he found a way around that pesky problem by only using OTL and OTU and having 5-20 of each spread throughout the entire program. This thing was a nightmare to find problems on. In order to manually move something, you may have to press the button on the HMI 2-3-maybe 4 times before it moves, and it was randomly every time because there was so much going on and getting stuck in the program.

 

[Steve Bailey]

so they called in a third-party programmer to reprogram the machine and instead of removing the old logic and re-writing as much as possible, he just disabled some rungs and made others true 100% of the time with empty branches

So many bad programming examples are the result of violating the first rule of holes: "When you find yourself in one, stop digging."

 

[parky]

The one problem I had with the machine above was it was in production at the time they wanted to sort the mess out, we tried re-writing some of the individual operations (the Italian who wrote it & Me) but it caused major downtime, fortunately, the company had it removed from the line & placed 2 operators there to manually strap the pallets (by the way it had a press on the strapper to compress the cardboard flattened boxes, so one operator to sit on them & other to strap lol). The machine was installed in a spare area with conveyors & once I had re-written the code in our offices I went to site to commission it, once customer satisfied it was installed & quite a long watching period to check there was no problems. Nighmare type of thing to do though, wooden pallets are notorius regarding the shape & condition. We did add a few other things like check if the bottom runner boards were broken rather than just not used, check depending on the length if no runner boards that the legs of the pallet were all in place, And then there was another thing there were 3 swords for the strap again depending on the spacing between the Legs it had to select either swords 1 & 2 or 1 & 3.
All in all, many different pallet sizes, & types.
So in reality, to have to re-write on a live system would have been a major task, I had the luxury of an off line system, but in saying that I fully simulated it at our offices & testing became a dream.

 

[I_Automation]

So many bad programming examples are the result of violating the first rule of holes: "When you find yourself in one, stop digging."

In this field it seems that's the time you rent a backhoe for a month

 

[JankyPLC]

One certain OEM we've got machines from had a fetish for oneshots and OTL/OTU to control systems in place of step sequences. The oneshots make troubleshooting anything a nightmare.

Far worse was a packaging machine. Worked great until company changed label suppliers and machine wouldn't work right anymore. Adjusting settings and sensors made no difference. Finally opened up code to find it didn't use any sensor after the first one in line, and the program was all based exclusively on cascading timers. Ended with complete rewrite.

 

[arpus4KM]

One certain OEM we've got machines from had a fetish for oneshots and OTL/OTU to control systems in place of step sequences. The oneshots make troubleshooting anything a nightmare.

Far worse was a packaging machine. Worked great until company changed label suppliers and machine wouldn't work right anymore. Adjusting settings and sensors made no difference. Finally opened up code to find it didn't use any sensor after the first one in line, and the program was all based exclusively on cascading timers. Ended with complete rewrite.

I also ran into an amazing example of a program. Funny enough the person who wrote it had extensive experience written on their linkedin, touting years of experience in automation, project management, and robotics.


This program was a small parts assembly machine and had one Single timer called the "Main_Cycle_Timer" that controlled everything. It was a 2500ms timer that just repeated while in cycle.

All cylinders, valves, air checks, part placements all fired off of a Limit check of the timer. There were no sensors for position checks of each station, no alarms for problems in any station, no way to actually verify anything was working.

The entire program, which was decently long, could have been consolidated to the same functions in 1 Drum instruction inside a Click PLC and had the same effect.

 

[parky]

Yeah, that's a nighmare, many years ago, we were given a job to replace a burnt out relay system with new controls, basically a pick & place, they would not go to the expense of fitting limits on the cylinders, so we had to use timers in the PLC & trim them with the stroke time, trouble was if for some reason the stroke time changed because of a leaky cylinder or low air pressure the timer could time out before the cylinder got to posion, originally, we set the timers to a value just above the required time rerquired to reach position, worked fine & even faster than the original by a margin, however, as cylinder seals wore the could slow down causing the next operation to start before the previous, so that is how it stayed for a number of years, eventually, after many crashes, the company asked us to sort it all it took was a few sensors (had allowed for them in the first place), after that managed to get the system working at least 20% faster than the original & never had a crash, sometimes it's not bad programming or bad design but the customer (or OEM) wanting to save money.

 

[James Mcquade]

where do i start.
#1 not using <= or >= when trying to reach a point with a cylinder.
a can equal b.

#2 using 18 latch points of the same bit and 24 unlatch points of the same bit
everywhere in the program.

#3 Gracet programming logic with NO comments or idea where the fault is.

#4 writing a subroutine in 4 rungs that any normal person would do in 32 so
that maintenance can understand what is going on.

#5 writing a program for job security! maintenance cant fix it, machine
downtime, then your boss !@#@@@I( at you.

#6 writing a 2400 rung program, getting it to run.
then you print it out 1 rung per page, throw it up in the air.
recode the program the way you pick up the papers.
debug it to run, then turn it over to the customer.
YES, it happened to one of my customers, that oem lost his business.
the list goes on and on and on
37 years of programming and i still get surprised at what i see.
james

 

[I_Automation]

#6 writing a 2400 rung program, getting it to run.
then you print it out 1 rung per page, throw it up in the air.
recode the program the way you pick up the papers.
debug it to run, then turn it over to the customer.
YES, it happened to one of my customers....

Going to have to remember that one:beer:

 

[jholm90]

Sequence had 22 steps, with a EQU pointer for what step was active. Incrementing the step took place all on one rung, there was 22 branches, each with an EQU comparing steps and all of the conditions needed to change to the next step (part presence, cylinder positions etc...) end of the rung was one ONS/OTE "Next step". Next rung compared the OTE and added 1 to the step counter

 

[Dale87]

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.

We do the same thing, we do our company name always off. (xxxx always off) makes it easy to find and remove, and we know who to blame if it gets put somewhere it shouldn't.

 

[cardosocea]

I can't quite post an example here, but I have a list of them:

- Not commenting anything...

- Not separating equal logic into blocks or subroutines.

- Not separating blocks of functionality into a larger organization unit (like a Program or OB).

- spaghetti logic when a state machine would make more sense.

- Long tag names rather than UDT style variables. If you're so proud of your 30 year logic, then you should clean it up and not rely on variable names to "organise" it.

Sorry for the rant.