What's the most annoying PLC problem?

I think we can all agree that some customers "engineering ethics" are a bit low, and in some occasions non-existent. I would never make any code changes to alleviate a hardware issue. I've been on this road more than once, and engineering and my boss always backs me up. I get some screenshots of the logic, and do some serviceLab trending with enough data to point out the mech/hyd issue. The issue is that even some of our remote support have this wrong mentality of patching up software here and there temporarily, until the issue is "fixed" the issue with that is that if it looks like is working the customer won't bother of fixing the actual hydraulic issue then when the machine stops working completely, they will complain again that the software is messed up.

While we're ranting... lately it's been integrating with I.T. They have been one of my most valuable resources I've had over the past 5 years, bar none. Yet, they seem to insist, without doubt or forethought, that they need me to update to Windows 10 by Thursday and I say, "That's gonna be a bit tough, I don't think we're quite ready for that." Yet, I'll work with you. Doesn't seem to matter to them, they've gotta close that ticket by Friday. I say Ok, to make this easier I may need a couple of licensed versions of vmware, They say "What, this multi-million operation can't afford VmWare on a whopping "2" laptops, maybe we could put them on the cloud? Fine, I'll dredge through the sludge and make it work." But, I tend to find myself, trying to be the better man and all, and frequently running into situations where I'm REALLY trying hard NOT to say "What's that? The Circuit Breaker on your server UPS is tripped, and nobody in I.T. knows where it's located... I don't seem to have a work ticket generated for that!" Ugh.

fredz0003 said:

I think we can all agree that some customers "engineering ethics" are a bit low, and in some occasions non-existent. I would never make any code changes to alleviate a hardware issue. I've been on this road more than once, and engineering and my boss always backs me up. I get some screenshots of the logic, and do some serviceLab trending with enough data to point out the mech/hyd issue. The issue is that even some of our remote support have this wrong mentality of patching up software here and there temporarily, until the issue is "fixed" the issue with that is that if it looks like is working the customer won't bother of fixing the actual hydraulic issue then when the machine stops working completely, they will complain again that the software is messed up.

Click to expand...

That is pretty annoying, always lowering tolerances, and a month later you're like "Have you guys found anything?", "what do you mean? you fixed it last time..." EEEEEURG

Companies that don't understand the value of documentation on the plant floor. They will keep meticulous accounting records, and know exactly how much they spent on jelly doughnuts in January 1972, but when it comes to keeping documentation on the controls systems that literally keep their plants running and putting product out? Somehow that's unimportant. They'll let their maintenance electricians cobble panels together until they're an absolute nightmare but it's nobody's job to maintain the documentation.

And then they'll want my company to come in and "clean it up." So we'll come in, and see how they have 120volt I/O everywhere in a Class I Div 1 environment with no IS barriers and no XP enclosures anywhere to be found. They'll wave vaguely at panels as they take us through the plant at a million miles per hour, barely able to explain anything because it's such a mess and they have so much turnaround that not even *they* know what does what because Billy Bob screwed this machine up back in 1997 and it's never worked since, and Bubba did something to this machine 5 years ago but he got fired so they have no idea what's going on there. And then they'll be offended when we send them a quote for $150,000 because nobody has any idea what the scope really is. I mean, it's literally,

"We need to consolidate these three panels."

"OK. What do they do?"

"We don't know. So figure in some time for your guys to figure that out."

In this particular case it was something like one machine's function being split up between two PLCs in three cabinets. Like literally they just threw some I/O in a different PLC rack because reasons.

And then comes the re-quoting. They'll come back in a few months with requests to add this, subtract that. So we re-quote, and re-quote. You have one job several months in the making, thousands of dollars in man-hours spent just on quoting. And then, you don't hear from them for a while. Turns out they just took your quote with your carefully and painstakingly-crafted scope of work to your competitor, who gladly knocked $10,000 off the price and got the job.

We no longer quote jobs for that customer.

Plus, a bit of a rant/cautionary tale.

Automation is a game of hot potato. Whoever touches it last is responsible for the system until someone else does. It doesn't matter how much or little you did. It doesn't matter how unrelated the problem's they're having now are to the changes you made. You touched it last, you're getting called.

A few weeks ago I was called in on a Saturday because a press I had worked on two weeks prior adding some sensors suddenly stopped going up and down. After driving an hour, I walk in, hook up, and notice a Flex I/O was not responding. Lo and behold it just happened to be the module that controlled the analog outputs to the proportional valves on top of the press. After climbing over the railing of the scissor lift 20 ft in the air onto an oily platform at the ceiling of a metal stamping plant in the middle of August, I pushed the module back into it's socket and it took right off. Had absolutely nothing to do with what I had done, but I touched it last, so I was the one who got called.

FactoryTalktotheHand said:

R
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.

Click to expand...

They must have needed therapy after you dropped THAT bomb on them.

sprucebruce said:

I'm a PhD student and for my research I need to do some short interviews with people who use PLCs on a daily basis to determine the most common problems, software issues, etc. Any ideas for conferences, trade shows, websites, etc. where I could find some friendly folks willing to complain for 15 minutes about their biggest problems on the job?

Click to expand...

omg, best offer ever. music to my ears. I could rant for hours.

Tom Jenkins said:

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".

Click to expand...

well said

Automation is a game of hot potato. Whoever touches it last is responsible for the system until someone else does. It doesn't matter how much or little you did. It doesn't matter how unrelated the problem's they're having now are to the changes you made. You touched it last, you're getting called.

Click to expand...

You don't even have to make any changes, as long as you are hooked to the network switch or PLC. Anything that happens is on YOU.

I read the op as software complaints et al.
software complaints:
1) software crashes and you lose your work. Seriously wonderware? all I did was right click.
2) no line numbers in the structured text code Schneider?
3) can't rename a tag Phoenix
4) can't make the code window bigger Indusoft
5) whoops, I attempted to print before compiling so crash
6) tag properties in a gazillion dif. locations thanks Indusoft
7) the list is endless

customers:
I don't know how to do it so it must be easy

the fact that if I EVER have a bug in my software I fix it immediately.
I could write pages to the vendors of the software I use daily and nothing.
Can't even talk to a programmer.
But bubba can call me at 2am.

FactoryTalktotheHand said:

Automation is a game of hot potato. Whoever touches it last is responsible for the system until someone else does..

Click to expand...

I could not agree more... I can not count the times that I was just an excuse because someone else could not figure it out

Night shift ~ "well Mark did something and he will be here in a few hours and can look at it" .... yep I adjusted that prox that was loose a few days ago but because I hooked up the "black magical box" (laptop) they could not do anything with it

FactoryTalktotheHand said:

...I pushed the module back into it's socket and it took right off...

Click to expand...

Knowing Where to Put The "X"

ganutenator said:

I read the op as software complaints et al.
software complaints:
1) software crashes and you lose your work. Seriously wonderware? all I did was right click.
2) no line numbers in the structured text code Schneider?
3) can't rename a tag Phoenix
4) can't make the code window bigger Indusoft
5) whoops, I attempted to print before compiling so crash
6) tag properties in a gazillion dif. locations thanks Indusoft
7) the list is endless

customers:
I don't know how to do it so it must be easy

Click to expand...

The software bugs are ridiculous. Some are so bad you can tell that either the bugs were known and disregarded, or simply no one tested their own software. Renu's software in particular is riddled with GUI errors (talking about how this ComboBox was set wrong etc).

Love the customer comment, think I'm going to put that in my sig.

ganutenator said:

I read the op as software complaints et al.
software complaints:
1) software crashes and you lose your work. Seriously wonderware? all I did was right click.
2) no line numbers in the structured text code Schneider?
3) can't rename a tag Phoenix
4) can't make the code window bigger Indusoft
5) whoops, I attempted to print before compiling so crash
6) tag properties in a gazillion dif. locations thanks Indusoft
7) the list is endless

customers:
I don't know how to do it so it must be easy

Click to expand...

I could make a list 10x that long for Rockwell RSLogix5000, but some of my favorites:

Aliasing - Worst invention ever. Can't alias to a member of UDT, which means you end up with a tag for each I/O point....What's the point of that? If you want to change it, you have to download the entire program....can't do it online.

In the age of 4GHz processors and 64GB of memory, why does it still take 30 seconds to open a module property pop-up for a powerflex drive?

Why is the first thing that rockwell tells you to do for 80% of weird behavior is export to an LK5 (essentially recompiling). Fix your damn compiler!

Speaking of LK5 don't every put more than a couple of stratix switches in your I/O tree if you want the ability to export. It'll freeze up exporting every time if you have more than a couple.

Why build an emulator if it isn't going to emulate correctly? Did you know that a FOR-NEXT in RsLogix5000 works completely different than in RSLogix5000 emulate? I didn't either until it started fatal crashing my program. Seems in emulate, the good old FOR-NEXT gets called one more time for good measure, and therefore the index ends up one higher than you thought....good way to access non-existent elements in an array. Rockwell's explanation...oh yeah, the two were developed by two different software teams....there's a tech note somewhere from 2004 on it.

I could go on, but those are just the ones from my LAST project.