Programmers (Hey Moe)

I saw another post and this got me thinking.
Who is the worst programmer you knew?

I worked with this one guy, the program was all finished and his job was to start the machine up. There was a NO contact that was not making. He couldn't figure it out so he removed the contact. Well this caused another problem and and he kept bumbling through the program, removing contacts or reversing contacts here and there till he finally had the whole program screwed up. He called me over after working on it for a day or so and I was somewhat shocked when I looked at what he had done. We finally re-downloaded the original and then I saw the problem with the NO contact, the limit switch needed to be adjusted.
The sad thing is that he had been programming for a few years going from job to job.

I can tell you some traits of a bad programmer.

Of 1000 memory bits used, only 40 are labelled

Comments are in German, or extremely poor English

Inconsistencies between similiar machines (One machine coast to
a stop on a drive fault while another fast stops)

Have FBD, Ladder and Statement in the same code block..

I sure there are some more traits

We have a production line that I have yet to find anything positive about. Poor documentation, convoluted logic, non-robust communication with other processors, values not reset (after e-stop, etc), flip-flops that aren't triggered with a one-shot (good luck releasing the button at exactly the right time . . . ).

We don't do business with that OEM anymore (nor will we ever reconsider!).

Marc

The bad programmers are the ones who dont have any field experience with the mechanics of the machine. The dont understand concepts such as contact bounce, voltage surges, regeneration, wear on the machine, and other enviromental conditions that will effect the way you need to program the unit. Rember that your machine will be running in the field, and not on the bench.

Addmission: We found a bug on two units (same program) that was installed for 6 years! The bug didnt show up due to the fact that the set of circumstances for it to effect operation was a very rare occurance. The techs just would reset the unit and let it run. Finally the customer told me about it, and I investigated, and fixed the problem.

Lesson 1: Read your techs service reports.

I have seen most of the problems with guys who are just
not organized (no comments, messy drawings, no up to
date files for anything, no documentation, use gazilion
of oneshots of the same bit, use aliases without comments,
don't do I/O check or calibration of analogs in hope it will
work somehow...).

Mark Buskell said:

The sad thing is that he had been programming for a few years going from job to job.

Click to expand...

He hasn't ever programmed traffic lights, has he?

Seriously, we all make dumb mistakes once in a while. But, you should always check your I/O first. Especially when a working program stops working.

AK

The company I currently work for used to farm all programming out to a man who wired the Line E-stops to the PLC which in turn, turned on the MCR. Also, the wiring to e-stop switches were spliced in the conduit. He installed Pendant Stations with Stop buttons and E-stop buttons wired in series so that both buttons acted like stops, not e-stops. And I could go on and on about his actual programming. We actually rewrote a program on on of our lines. When I finished, the line ran better than before with one third the programming.

I know how the "first job" is, but when you bill customers for your work it should not be as poorly done as what I described above.

My pet peeves are poor file naming conventions and poor revision control. We've had a few rouge programmers who don't follow the file naming convention established by the company. We can't tell which rev is the latest. Sometimes we can't find the latest because it's still on the programmer's laptop and others need it!

My pet peeves are poor file naming conventions and poor revision control. We've had a few rouge programmers who don't follow the file naming convention established by the company. We can't tell which rev is the latest. Sometimes we can't find the latest because it's still on the programmer's laptop and others need it!

Temptation to slander....

Okay, I'm going to be nice about this and just tell the story of a plywood stack edge-paint booth I once had to start up. It had a standalone SLC-5/04 inside, and was supposed to be delivered by the OEM all programmed and ready to be interlocked to the other plywood stack conveyors. They demonstrated it running back at their factory, and we signed off and had it shipped to site.

It really did fire up and work; all of the manual jog buttons functioned and all the cylinders and motors worked with them.

Nothing worked in AUTO mode, though. I found that branched around every single manual function rung was a single XIO contact addressed to B3:0/0 and named "USER LOGIC".

The worst programmers are the ones with double jointed shoulders and elbows who go around patting themselves on the back after finding someones mistake!

On a personal note, I've mever nade one.

Hard Wear said:

The worst programmers are the ones with double jointed shoulders and elbows who go around patting themselves on the back after finding someones mistake!

Click to expand...

Well said.

I am as guilty as anyone (maybe more so) when it comes to b**ching about someone else’s "brain-dead" code. And of course, I’ve never sent out any crappy code myself

But what I will say is that common sense is an uncommon thing.

On a personal note, I've mever nade one.

Click to expand...

Ne meither.


John

And I have made even fewer mistakes than both of you guys.
Don't even argue.

Be careful about slandering other people, especially in writing.
If you put in a report that "the downtime was caused by an error in the program made by 'X'" and the report arrives on 'X' table, then you have made yourself an enemy for life. Not good if you have to work with that person in the future.
I find many errors (SOME of them not from my own doing), but I take care to present it to the person responsible for it in the most friendly an collaborative manner that I can muster. And I never put specific personal critique in writing.

I think I've told this story before, but anyway...

Back in '97 we were building a high-speed labeling system for mascara tubes. The customer specified that we use a GE 90-30, which I hadn't used before. I designed the control system as I normally do, with all the necessary feedback from every actuator (i.e cylinder extended, cylinder retracted, etc.). IOW, the PLC could always know where everything was.

I was extremely busy on other projects, and didn't really have time to learn the GE software, so we hired a programmer, well versed in GE, to write the program for the machine. I left him alone with the machine and all the necessary documentation he would need.

It took him a while, but eventually he claimed to be 'done'. The machine DID function as expected, but I noticed that if I altered the speed of a cylinder, the cycle time didn't change. I questioned this, and his response was "Oh, I'll have to readjust the timer for that cylinder". I asked him why reaching the cylinder's end of stroke sensor sooner didn't cause the next operation to start earlier. He replies, "Oh, I didn't need that sensor in the program".

Upon further investigation, I quickly realized that he didn't use ANY of the feedback signals I provided. His ENTIRE program was based on time alone! Wait x seconds, do this. Wait x more seconds, do that. And not even sequentially! All timers began timing from the same point, so if you changed one timer, you had to adjust a dozen or so others by the same amount!

Nevermind the fact that if a cylinder or valve failed, the machine would continue right along, because he wasn't looking for confirmation that the cylinder had finished its move! In fact, removing the connector from a 32-point input module had ZERO effect on the machine. He "didn't need" any of those 2 dozen or so feedback signals!...

After tossing this guy out on his ***, I modified his program enough that the machine couldn't destroy itself. We had a deadline to meet. Thankfully, the customer needed more of these machines, and agreed to let us build a second machine, with a REAL program this time. I was then able to repair the previous 'mess' with this new program.

beerchug

-Eric