What's the most annoying PLC problem?

[JordanCClark]

Customers with unrealistic deadlines, with minimal information. At project completion is when information I should have had at the beginning of the project, flows from mouths.

I hear ya. And now I have the distinct displeasure of being the customer with minimal information because the product design stays in flux or tooling gets kicked off late because our customer kicks things off late but, heaven forbid, they should push back their due dates.

Then we have to hold to the crappy due dates with OEMs like yourselves, and run off machinery with prototype parts, instead of production-ready parts.

After that, there's only so much that can be done, and I gotta cut you guys loose so you can go back to making money, and I spend the next several months picking up the pieces.

 

[willxfmr]

In defense of Bubba. *Mostly OT*

I understand your sentiment, and there is certainly some truth to what you say. However, in my experience many of the 2 AM phone calls could be eliminated with a little effort. You mention reading the rung comments. Where I work, rung comments are VERY rare. We use a lot of indirect/indexed addressing, and are given no clue how or where the changes being made. When we ask for decent comments, Engineering says that comments take too long to write, and they don't have time. . The same is true for getting prints updated. We have machines that have been upgraded running for over a year, but we still can't get updated prints. Around here, and other places I have worked, P&ID, is called Phht&WeDon't. And the one that will almost guarantee the engineers phone will ring at 2 AM is the 4 PM change that they assume is going to work just fine but it's too late in the day to test, so we'll just let it go and deal with any problems tomorrow morning!
I don't like, but I have to forgive, the use STL and FBD in the programming. Most of us in the USA get very little if any training or education on these languages, but they are there, and as professionals it is up to us to learn enough about them so we can be effective at our jobs.
Most of us Bubba's try very hard to keep things running so the night sleepers can get their beauty rest, but there are times when the only recourse we have is to shake people out of their racks and remind them that we run 24/7, and we don't like surprises. And even though we live in the dark, we don't much care for being kept in the dark.


Bubba.

My biggest complaint, BUBBA !!!

He looks at the code and doesn't even take the time to understand what's going on, let alone even read the rung comments, and modifies the code to the point that the machine doesn't even work correctly and he's happy with it!!

he's also notorius for calling at 2 am with a problem that he created and wanting you to fix it, then it's your fault for what happened.

james

 

[Epy]

Don't get me wrong, I'm all for documentation. However, no documentation can save bad programming.

I agree with what you're getting at -- preventing people from doing "tricks" that end up complicating things -- but I meant the basics. One such example was having to contact support to find out how to programmatically set the clock on an HMI.

 

[kwade]

Bubba, I'm keeping your OT theme

Where I work, rung comments are VERY rare. We use a lot of indirect/indexed addressing, and are given no clue how or where the changes being made. When we ask for decent comments, Engineering says that comments take too long to write, and they don't have time.

Bubba.

But then, these engineers can stand in hall for 30 minutes talking about inane garbage such as sports stats from 1995.

 

[PLC Pie Guy]

Not a PLC Issue but an Issue none the less

How bout the Bubba who couldn't figure out that a guard switch was not made, even though there was an alarm on the HMI stating such conditions, even though there was an indication on the HMI as to what guard switch was open and even though the guard was visibly ajar . Still he manages to butcher the guard system safety wiring in the panel, blow the safety system fuse and put the processor in program mode having no clue what he had done.

And all at my expense at 2:10 am in the morning.

The same Bubba who thought that a 525 was fried because a photoeye was blocked by debris and proceeded to replace the power module of the drive, with the wrong replacement, and ending up with mismatch errors he couldn't clear, taking the whole plant down. Again at 3:00am.

Now in Bubbas defense, he is a mechanic that got thrown to the flames to burn by management simply by not having any experience on the floor after I go to sleep at night. """Call in the Pie Guy, he's on vacation but he will come anyway! Hell get us going again!!"""" They shout. Only to walk in to a mess like that, or something blocking a photo eye.. (LOL,, I like this one, always easy)

That's my pet peeve!

Big Wigs thinking that one guy can fire fight 2 plants electrical, control and automation issues, and try to convince them that some issues are mechanical or related to equipment housekeeping in nature and not electrical. All the while running 6 days/nights a week, leaving the seventh day of course for quick maintenance and project changes.

It tires one out!

 

[kwade]

Did anyone mention 'management insisting on mechatronics techs?'
The concept of mechatronics is great from a management view.
Probably ok for the 12.3456789% of the time that there are no fires to fight.
But, as Pie Guy relates, 3 a.m. is not the time to test the electron-pixie wrangling aptitude (or the ones and zeroes herding skills) of the mechatronics tech.

 

[SysIntegrator]

To play devil's advocate, there are some definite plus sides to the mechatronics tech. Mainly, the age old argument of mechanical vs electrical ceases. In my last job every electrician said a problem was mechanical and every mechanic said a problem was electrical and I always had to be dragged into it (spoiler alert, 80% of the time it was mechanical). Truth is, if you have to fix it regardless if it's mechanical or electrical, then you don't stand there and argue with yourself.

Furthermore, most troubleshooting, even of mechanical problems, begins on the software/electrical side. You have to figure out what switch isn't making before you go investigate and find a bad mechanical component. Therefore having the electrical knowledge in the hands of the mechanics is very useful.

Not that I'm 100% for it, but in my last job electricians were so bad and this was such a problem they would have only benefited from mechatronic technicians. But of course it depends on the plant and equipment, and there's always got to be both a proficient mechanical and electrical SME to clean-up band-aids and solve more technical problems.

 

[thebuj]

Besides customers, I'd say electrical noise in your PLC, very hard to find the source and eleminate.

Communication problems when they occur can sometimes be hard to resolve also.

 

[SysIntegrator]

Noise can be a pain. I had a customer that had one specific 4-20mA transducer, I think it was a pH meter in a waste treatment plant, that twice a year it would all of a sudden become erradic and I'd get called to it. That went on for 3 years and I never figured it out. I rung out every wire, walked the cable route several times looking for anything that could induce noise, replaced every card and device, never figured it out. All I remember is I learned that when it had a problem, I removed the linking between 24VDC common and ground if it was there, and if it wasn't there, I put it back. Pretty sure I did that x2 a year. I am still stumped to this day.

 

[John Morris]

Easy on the mechatronics.......

I did it for 27 yrs. Bachelors in E.E. and a Associates in Automated manufacturing. I turned wrenches, ran lathes, mill-write, installations, and just like ya'll, got called out at 2 am (and on vacation) ALOT.

Granted, 80% of applicants will outright LIE about electrical experience, but you find the rare few who apply common sense to familiarity, put a meter in their hands and you'll have a half way decent tech.

And whoever coined the term "COMMON sense" should be slapped.....twice. There is absolutely nothing common about it. It's actually rare to find someone who was raised correctly these days.

But I digress.

 

[fredz0003]

Since I deal with software on the regular basis.
1. Code should be simple to read for EVERYONE.
2. If the code is not so simple, then try to comment it as much as you possibly can.
3. Variables naming should be carefully designed.
4. Structure of the project, should also be carefully designed.
What I mean by that is have all functions alike together.
5. Customers not understanding what a parameter change is, as opposed to a logic change.
6. There should be some type of Software QA.
7 Software design document should catch any over-engineering issues.

Issues with maintenance personnel:
1. Not knowing how to check inputs and outputs, but blaming software.
2. Not knowing how to check logic, when an alarm is given on the operator screen.
3. Not keeping up with mech/hyd maintenance, and when a valve or hyd is giving issues, they blame the software.
4. Not taking the time to study the PLC software for your machines. You don't need to know the whole program bit by bit, but at least know the main functions.

 

[geniusintraining]

I know its not really a "PLC" problem... but mine is just customers not paying, you spend time making up a quote, then spends hours/days/weeks working on the project writing code and a lot of it is not even billed and you gave them net60, but you still feel like they are doing you such a big favor in giving you your damn money.... im not a bank and if I was I would have negative interest rates so pay me my money, yes I also have bills that I need to pay and food I need to eat

 

[fredz0003]

I agree that going online and monitoring is a relatively low rsk activity, and few customers would object to it.

The trick is when it comes time to testing the changes. I've had plenty of times where I sat on the plant floor for hours waiting for a break in production that never came. More and more plants (at least in my neck of the woods) are running 24/7, and finding ways to work through breaks. If you're lucky, you can charge for that waiting by the hour.

Yeah I agree sometimes is hard to test new code changes. As far as charging time for waiting, well for me is no issue. My company charges a flat day rate. If they ask for a service engineer and they don't give us time, is on their time. However if they give us time to do the changes, and code don't work then they could also get a break. I don't get too much involved in the billing department though. My job is to keep customers happy when it comes to their PLC issues.

 

[kwade]

I didnt mean to pick on the mechatronic techs themselves, just management's insistence that mechatronics is a silver-bullet to automation.

 

[FactoryTalktotheHand]

The most annoying problem is a system with mechanical or basic process problems combined with a customer that wants you to "fix it in the code".

Recently had a customer that wanted me to fix their tube measurement machine. The track that the tubes slide down has been worn out of some time and is in dire need of replacement. The problem is, the tubes were physically hanging up on the track and not dropping like they should. They wanted me to fix it in the program.

I told them in no uncertain terms that the PLC has no control over the gravitational constant of the universe, nor can it repair a mechanical issue.