What's the most annoying PLC problem?

sprucebruce

Member
Join Date
Sep 2016
Location
Georgia
Posts
3
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?
 
If you want a trade show with plenty of PLC users, IMTS in Chicago starts tomorrow. I bet you'd find LOADS of guys willing to complain for 15 minutes if you buy them a beer.

https://www.imts.com/


for other internet forums, you might want to checkout http://www.reddit.com/r/plc or vendor support site forums (https://support.industry.siemens.com/tf/us/en/ is fairly active and global).

Problems:

semi serious answer: the users are typically the biggest problem

really serious answer: software incompatibilities between vendors are a huge issue. IEC 61131-3 exists, but its more of a minimum guideline than a rule. Every vendor has its own unique interpretations, features, and ways of dong things. Every vendor ALSO has a vested interest in lock-in, keeping the data in its format, which often makes export tricky. If you put in a lot of effort to make a good program in one vendor's system, you usually have to start from scratch to make it work on another vendor's system. The only exception is if you start from the beginning with the intention of making portable code, which then becomes very limiting.
 
I totally agree that the biggest problem is customers. They seldom have any idea what they actually need but are more than willing to load their projects up with ridiculous specifications.
 
The most annoying problem if you're a service technician is programs written by people with degrees in programming but no idea what so ever about automation.

If you're programming: yes, customers with wishlists that end up in the 100s kUS$ but only willing to pay sub 10kUS$. And don't forget to mention impossible delivery times.
 
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".
 
Convincing the user that when the machine has been running fine for the past six months and suddenly develops a problem, the problem is most likely external to the PLC and the program doesn't need to be "fixed". My most egregious example is the customer that had to wait a week before I could get to his facility. "The Y axis won't move. There must be a problem with the PLC program". I arrived to find a broken timing belt lying on the floor.
 
Another big problem is the customer having a little bit of information about a PLC and specifying that one for a project.

Either it is too small, lacks analog I/O when needed, or to the other extreme is way overkill that will never be utilized.

Or for a small machine they want emails sent to multiple people for 100 or more events.
 
with people who use PLCs on a daily basis

I have been working as a service engineer with siemens PLC's for 5 years or so, upgrades, updates, bugs, etc. As one customer explained, there are no problems only solutions. It also depends on who you will be interviewing. In short you have 3 or 4 main groups. Maintenance, software engineers, service engineers, and maybe remote support.

The questions will vary greatly. I have been dealing with so many customers, and I hear more often than not that they will prefer ladder logic. And why is the program so complicated. They always have a thousand and one ideas on what the program "should do". Also customers hate STL for some reason.

For me as a service engineer. Don't name a variable Motor_Fault and have the bit be TRUE when is normal. Variables naming should do what is called. The company I work for is big, and I work with software engineers from all over, some use STL, others FBD, SCL, a bit of ladder. I enjoy all except FDB the scrolling down is insane. Other than that timestamps is another big pet peeve that even some senior engineers do not take seriously.

I don't have any issues with siemens PLC's you adapt to the tools you use which is simatic manager and tia portal.

In short the biggest problems are there are wayyyy to many people hooking up to PLC's who shouldn't even own an ethernet cable or mpi adapter. Over-engineering of programs, what makes sense for you as a programmer might not make sense for maintenance personnel. If you have a piece of code that is complicated, at least try to comment your code well.

For customers issues I think so many come from the good ole' ladder logic days, that is hard for them to comprehend FB multiple instantiation and why that is good in terms of maintaining code. And when downtime is crucial maintenance personnel should at least get acquainted with the program structure for example which one is the Main function call? Where do all the motors get controlled from? So basically breakdown the program and have a cheat sheet, preferably do all this before the machine breaks. Learning while a machine is down, is not the best way to open the program for the first time.
 
Convincing the user that when the machine has been running fine for the past six months and suddenly develops a problem, the problem is most likely external to the PLC and the program doesn't need to be "fixed". My most egregious example is the customer that had to wait a week before I could get to his facility. "The Y axis won't move. There must be a problem with the PLC program". I arrived to find a broken timing belt lying on the floor.

Steve try having a running program for at least 3 years. And all of a sudden the program changed itself and morphed.

I have witnessed first hand where the operator manages to do a sequence so odd that you normally wouldn't perform in normal operations, that managed to find a bug in the program, but those are very rare.
 
Steve try having a running program for at least 3 years. And all of a sudden the program changed itself and morphed.

I have witnessed first hand where the operator manages to do a sequence so odd that you normally wouldn't perform in normal operations, that managed to find a bug in the program, but those are very rare.
How would you debug a problem like that where a system has been running forever and the customer doesn't want to take it offline to debug?
 
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".

definitely this as well. It is so important to know how/when to tell the customer that "physics says no".
 
How would you debug a problem like that where a system has been running forever and the customer doesn't want to take it offline to debug?

Our systems have historical data servers. And I have yet to find a customer that doesn't let you debug a program online. Is not like your hurting anything you are just monitoring.

Also sometimes the bug is obvious when you look at the logic, and just reported to engineering for a fix or fix it yourself.

So report steps taken by operator to create the issue. Then look and the logic conditions, and see how to prevent it.

Most machines have steps to follow for the operator in these one offs operators have done their own sequence that wasn't predicted in the logic to prevent an issue.
 
definitely this as well. It is so important to know how/when to tell the customer that "physics says no".

Actually I had a customer that wanted to change low pressure alarms limits, because the low pressure alarm was kicking them out of Auto mode. I saw the pressure taking a big dip, and I knew right then it was an actual hydraulic issue.
 

Similar Topics

For some reason, when I do a search (Find in Routines, Text Only) in Logix Designer (v30, v32, or v33), I can press F4 and it will step through...
Replies
1
Views
796
Trying to add a device through CCW, but it keeps requesting a password. There is no password on the device (see attached photo) and I have never...
Replies
2
Views
1,863
Does anyone else have the re-occurring issue where Allen Bradley Tag Upload Download tool keeps trying to locate the install file on their...
Replies
0
Views
1,013
Yesterday I went to upload the current program out of a MLX 1400 (i have the source code/project...at least 10 copies of the same program with...
Replies
5
Views
1,931
I need to get rid of this please help When an alarm happen on the HMI it leads to 3 screen popping up and covering all the screen display area...
Replies
3
Views
4,040
Back
Top Bottom