PDA

View Full Version : What's the most annoying PLC problem?


sprucebruce
September 11th, 2016, 08:09 AM
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?

osmanjdt
September 11th, 2016, 08:38 AM
no problem no job

mk42
September 11th, 2016, 08:46 AM
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/ (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.

jstolaruk
September 11th, 2016, 08:54 AM
Most annoying PLC problem? Customers with their annoying lists of changes.

mendonsy
September 11th, 2016, 09:17 AM
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.

jvdcande
September 11th, 2016, 10:05 AM
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.

Tom Jenkins
September 11th, 2016, 10:15 AM
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".

Steve Bailey
September 11th, 2016, 10:33 AM
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.

Aabeck
September 11th, 2016, 11:28 AM
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.

fredz0003
September 11th, 2016, 11:45 AM
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.

fredz0003
September 11th, 2016, 11:55 AM
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.

sprucebruce
September 11th, 2016, 12:27 PM
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?

mk42
September 11th, 2016, 01:19 PM
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".

fredz0003
September 11th, 2016, 01:24 PM
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.

fredz0003
September 11th, 2016, 01:35 PM
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.

mk42
September 11th, 2016, 01:36 PM
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.

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.

Epy
September 11th, 2016, 01:37 PM
Most annoying problem for me so far is having to deal with the other integrators in town when they're doing the programming for one of our measurement skids (as mandated by customer).

Our measurement skids are small so basically the other integrators think it's an easy project to break-in their brand-new, untrained people.

After years of dealing with this, we decided charge customers as if we did the programming ourselves regardless because the idiots we get can't follow clear english directions about what the skid needs to do and how to calculate different things. We spend just as much time correcting their mistakes as we would doing it ourselves.

ceilingwalker
September 11th, 2016, 02:34 PM
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.

AustralIan
September 11th, 2016, 03:01 PM
Not being able to use text based merge/compare tools on PLC code, without spending 15seconds exporting first.

Peter Nachtwey
September 11th, 2016, 03:04 PM
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?
I don't program PLCs often but I may be just the person who want to talk to. I hate programming PLCs because:
1 Most of awful editors. Most make me use the mouse way too often. This means I must take my hand off the keyboard to grab the mouse and then move my hand back to the key board. I am a long time assembly language and C programmer. I like a good editor.
2. Some PLCs have glaring flaws. For instance the Step7/S7 doesn't have indirect programming in ladder. Mitsubishi's function blocks allocate data backwards from high to low instead of the intuitive low to high. The AB COP command is not smart enough to know if you are copying an array up one element. It should know it is writing over itself and copy the data starting from the back.
3 The choice of PIDs are limited and often are not implemented correctly. Some are too hard to setup. There are lots of threads about setting up an AB PID. This is an indication that it wasn't obvious.
4. Getting back to the editor. It is difficult to see more than a few rungs of ladder whereas I can see 40-50 lines of code.
5 No real time trace. A real time trace with event trigger like a logic analyzer would be great.
6. Many PLCs have kludge Ethernet interfaces. The AB MSG block is the best. Automation Direct is a close second. To many other PLCs use a socket interface. It may be flexible but few of my customers can implement them so I must help. It is the fact I must help my customers with PLC coding that p!$$e$ me off.
7. I/O is slow and non deterministic. Actually this is good for me because people that try to do motion control applications fail due to these reasons as well as not having the right PID.

Epy
September 11th, 2016, 03:50 PM
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.

:beerchug: Yes. Love that last second "oh you made it so it works this way? we wanted it to work this other way...even though we never said anything about that"

Aabeck
September 11th, 2016, 04:43 PM
:beerchug: Yes. Love that last second "oh you made it so it works this way? we wanted it to work this other way...even though we never said anything about that"

I had one customer that I learned to ask very specific questions and get detailed spec's on how something was to run, and inevitably at commissioning as soon as it was started they immediately jumped in "Oh that can't happen until after xxxxxx happens."

Most of the time it was an involved program change and a couple of times meant adding I/O to the line they forgot to mention.

But they paid well, and always on time.

cjd1965
September 11th, 2016, 04:49 PM
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".

This, this and this :)

DwSoFt
September 11th, 2016, 06:50 PM
I had one customer that I learned to ask very specific questions and get detailed spec's on how something was to run, and inevitably at commissioning as soon as it was started they immediately jumped in "Oh that can't happen until after xxxxxx happens."

Most of the time it was an involved program change and a couple of times meant adding I/O to the line they forgot to mention.

But they paid well, and always on time.

They best is when you know the process and suggest improvements which require added devices and they say no. Only to have startup not go well and then they want it now...
But yes they usually pay well as well... lol

robertmee
September 11th, 2016, 07:07 PM
My biggest pet peeve is management trying to take away an operators ability to think and do their job. Stupid alarms or lockouts or stripping down functionality because they are afraid their operators aren't competent enough to run the machine. In my experience give the operator as many tools as possible and they will make the machine run better than any amount of situational code.

DwSoFt
September 11th, 2016, 08:52 PM
That's when they need to wake up and get better operators... Lol

bitmonkey
September 11th, 2016, 10:05 PM
Let me condense this thread for you. The BIGGEST problem in industrial automation these days is we have too many people with PhDs running around, who have no friggin clue what it takes to run a successful business, dictating to us how to "improve" the process with their FASTERBETTERCHEAPER mentality and absolutely no regard for the unintended consequences of their decisions.
No disrespect, you did ask.

John Morris
September 12th, 2016, 06:05 AM
Let me condense this thread for you. The BIGGEST problem in industrial automation these days is we have too many people with PhDs running around, who have no friggin clue what it takes to run a successful business, dictating to us how to "improve" the process with their FASTERBETTERCHEAPER mentality and absolutely no regard for the unintended consequences of their decisions.
No disrespect, you did ask.

And now you know WHY I got out of manufacturing!!!!!!!!!!

John Morris
September 12th, 2016, 07:22 AM
Most annoying PLC problem? Customers with their annoying lists of changes.



With no clue how long it takes to make those changes. They think its like flipping a switch and cannot (and don't want to) understand what it takes to make those changes. They just want you to stick to the unrealistic time frame they have stuck in there head.

My apologies, i am usually jovial and light hearted in my replies. but this one happen to strike a nerve.

James Mcquade
September 12th, 2016, 08:33 AM
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

dburnum
September 12th, 2016, 09:46 AM
My biggest pet peeve is management trying to take away an operators ability to think and do their job. Stupid alarms or lockouts or stripping down functionality because they are afraid their operators aren't competent enough to run the machine. In my experience give the operator as many tools as possible and they will make the machine run better than any amount of situational code.

Still...Id rather limit finite control of what an operator can do, then have an inattentive operator melt down or destroy a $1.5M heat exchanger.

My biggest complaint is as Tom Jenkins posted: Being requested to modify code to try and make a poorly engineered process run.

harryting
September 12th, 2016, 10:16 AM
People.

redbarron55
September 12th, 2016, 10:18 AM
Bosses who don't understand the real world we work in.
Little respect for 40 years in the business.

Currently I have a guy who wants to go back to the 70's with manual level and pump controls because he doesn't understand the system for "reliability".
So far where we had almost no problems we suddenly have problems with the "Code Black" modifications he mandated where none existed before.

This is so he can "run the plant in manual" while we find and fix problems.
It takes longer to get back to normal automatic operation from "Code Black" than it did to troubleshoot and repair any issues we might have.

All of this because we don't want to take the effort to train the electricians how to do their jobs in the 21st century.

Secpcb
September 12th, 2016, 10:55 AM
Redbarron,

I had a customer whose plant manager was way before the 70's.

He refused to allow any PLC's in his machinery, he wanted to be able to open the panel and see the mechanical relays activating, and if something wasn't he could isolate it to one relay or contactor not coming on.

And add to that about 40 or more pilot lights to show every possible condition.

redbarron55
September 12th, 2016, 10:57 AM
Redbarron,

I had a customer whose plant manager was way before the 70's.

He refused to allow any PLC's in his machinery, he wanted to be able to open the panel and see the mechanical relays activating, and if something wasn't he could isolate it to one relay or contactor not coming on.

And add to that about 40 or more pilot lights to show every possible condition.

This is one thing I don't miss about the 70's.
Now I would like to have my hair back........

dwoodlock
September 12th, 2016, 01:05 PM
My biggest pet peeve is management trying to take away an operators ability to think and do their job. Stupid alarms or lockouts or stripping down functionality because they are afraid their operators aren't competent enough to run the machine.

I spend a lot of time dealing with these scenarios as well, but its because we keep employing the type of people that are eluded by common sense and logical thought processes.

My biggest gripe as far as the PLC's is probably poor documentation. This is largely because lately all my projects have been in TIA Portal. The help files are pretty lacking. I've had instances where I followed their instructions, and it wont work, and then I contact the company directly and they tell me to do something different, and then it still doesn't work.

These situations aren't all bad because once I figure it out, I'll know it forever. The issue is that I hate having to spend 2 days trying to do something fairly simple by using their instructions that don't work.

SysIntegrator
September 12th, 2016, 01:50 PM
Seems unanimous that the user/troubleshooter is often the greatest struggle, and I couldn't agree more. Great integration, sophisticated development of fault codes, and anticipation of device/human error can make a machine or process robust, but there is no replacement for complete lack of technical knowledge and understanding of basic concepts. Some people can't be helped. Even worse is general laziness. In plants where technical knowledge is really deficient, especially at the supervisor level, I've seen many people blame software problems and claim it's out of their realm without putting forth any effort. Sure, the PLC program that hasn't been changed in 12 years all of a sudden has a new bug. I'll get right on it.

But on topic of actual develop and integration, incorrect indirect addressing is often the worst. I've lost hours trying to understand why code doesn't work like it should only to find a bit is being written from elsewhere in the program but I can't find it by cross referencing.

Jnoobs
September 12th, 2016, 01:53 PM
But on topic of actual develop and integration, incorrect indirect addressing is often the worst. I've lost hours trying to understand why code doesn't work like it should only to find a bit is being written from elsewhere in the program but I can't find it by cross referencing.

This right here is my number one gripe with programming. Wasting crucial time.

SysIntegrator
September 12th, 2016, 02:02 PM
I can't help it, I like this thread. My last job was realllly bad when it came to poor technical knowledge troubleshooting sophisticated equipment, with bad direction from management.

Software issues that are my own (or even others) creation, I can still stomach, that's just a challenge of a job that weeds out my competition. However, the greatest pains I have had in software/automation are mechanical problems that people REALLY want to be software or electrical. Changing code is faster and cheaper than regrinding gears and replating cylinders. There's no doubt I've had over 100 requests to change software for process/mechanical issues, and I haven't been in the business that long.

Epy
September 12th, 2016, 03:00 PM
My biggest gripe as far as the PLC's is probably poor documentation.

I'll 2nd (or 3rd) that. Especially with the budget stuff, always have to contact the factory on how to do anything out of the "ordinary" etc. The documentation that comes with only covers the basics.

redbarron55
September 12th, 2016, 03:31 PM
One of my problems is when some new guy knows everything and is god's gift to programming.
When he finishes this current project and if it works it will be one in a row!

But without him I might be unemployed since I make my money by making screwed up things work, mechanical, electrical, or Programming

harryting
September 12th, 2016, 05:34 PM
I'll 2nd (or 3rd) that. Especially with the budget stuff, always have to contact the factory on how to do anything out of the "ordinary" etc. The documentation that comes with only covers the basics.Don't get me wrong, I'm all for documentation. However, no documentation can save bad programming.

"A Computer language is not just a way of getting a computer to perform operations.. it is a novel formal medium for expressing idea bout methodology. thus, programs must be written for people to read, and only incidentally for machines to execute" -SICP

JaxGTO
September 12th, 2016, 05:34 PM
I would say my biggest problem as a System Integrator is the fact that we are on the end of every schedule. And of course the end date can't change because production always comes first. What really annoys me is that mechanical and electrical can always get behind and they never seem to get in trouble for it. Yet we have one day left for IO checkout and testing (which should have had 5 days) with the customer standing over our shoulder say "Can we make product yet?". But they never stand over the shoulder of the mechanical or electrical asking when they will be done.

The second biggest problem is trying to use a new product that turns out is not as available as the supplier said it would be.

Third biggest would be having to use a .0 of any software and spend more time finding and working around all the bugs then actually programming.

jstolaruk
September 12th, 2016, 05:39 PM
I would say my biggest problem as a System Integrator is the fact that we are on the end of every schedule. And of course the end date can't change because production always comes first. What really annoys me is that mechanical and electrical can always get behind and they never seem to get in trouble for it. Yet we have one day left for IO checkout and testing (which should have had 5 days) with the customer standing over our shoulder say "Can we make product yet?". But they never stand over the shoulder of the mechanical or electrical asking when they will be done.

The second biggest problem is trying to use a new product that turns out is not as available as the supplier said it would be.

Third biggest would be having to use a .0 of any software and spend more time finding and working around all the bugs then actually programming.

It does get old being the bearer of bad news: "I quoted a week, I need a week".

ASF
September 12th, 2016, 05:54 PM
It does get old being the bearer of bad news: "I quoted a week, I need a week".

Someone's signature on here always makes me laugh -
"If you want to make a baby, it takes 9 months. You can't just put 9 guys on it and give them a month."

JordanCClark
September 12th, 2016, 06:09 PM
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
September 12th, 2016, 10:20 PM
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
September 12th, 2016, 10:55 PM
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
September 13th, 2016, 04:18 AM
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
September 13th, 2016, 05:01 AM
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
September 13th, 2016, 05:10 AM
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
September 13th, 2016, 07:09 AM
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
September 13th, 2016, 07:16 AM
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
September 13th, 2016, 07:21 AM
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
September 13th, 2016, 07:30 AM
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
September 13th, 2016, 08:01 AM
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
September 13th, 2016, 09:09 AM
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
September 13th, 2016, 09:31 AM
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
September 13th, 2016, 10:10 AM
I didnt mean to pick on the mechatronic techs themselves, just management's insistence that mechatronics is a silver-bullet to automation.

FactoryTalktotheHand
September 13th, 2016, 10:28 AM
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.

fredz0003
September 13th, 2016, 12:16 PM
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.

bulletin blues
September 13th, 2016, 12:20 PM
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.

thebuj
September 13th, 2016, 12:40 PM
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.

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

FactoryTalktotheHand
September 13th, 2016, 12:42 PM
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.

FactoryTalktotheHand
September 13th, 2016, 01:00 PM
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.

John Morris
September 13th, 2016, 01:07 PM
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.

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

ganutenator
September 13th, 2016, 01:21 PM
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?

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

ganutenator
September 13th, 2016, 01:23 PM
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".

well said

fredz0003
September 13th, 2016, 01:34 PM
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.

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.

ganutenator
September 13th, 2016, 01:49 PM
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

ganutenator
September 13th, 2016, 01:53 PM
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.

geniusintraining
September 13th, 2016, 01:59 PM
Automation is a game of hot potato. Whoever touches it last is responsible for the system until someone else does..

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

gbradley
September 13th, 2016, 02:54 PM
...I pushed the module back into it's socket and it took right off...

Knowing Where to Put The "X"

Epy
September 13th, 2016, 02:59 PM
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 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.

robertmee
September 13th, 2016, 03:23 PM
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

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.

dwoodlock
September 13th, 2016, 05:22 PM
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.

This I can totally relate to. Most of the time they are telling me that I cant do something because its not allowed(although they couldn't remotely justify their reason). I then proceed to do it anyway.

example: "No wifi devices allowed that aren't part of the domain!!". I proceed to run a camera through a router that's broadcasting the machine name, because the machine had to run. IT spends weeks trying to locate said router, because its "broadcast signal is slowing down our network traffic".

long story short they never found it, and life goes on.

Epy
September 13th, 2016, 05:35 PM
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?

This. Finding this is true across many different software packages, PLC related or otherwise (instrumentation software).

In general, I've found just about everything (PLC/HMI related) shows signs of bad/wasteful programming in one form or another except Red Lion's Crimson. I really wish they would make PLCs...or just make it so I can monitor/debug scripts online. My programs are small enough to fit on a Graphite HMI.

rupej
September 13th, 2016, 06:17 PM
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?

Haha thanks for the laughs.... all of your examples are soooooo true!

sprucebruce
September 13th, 2016, 06:49 PM
omg, best offer ever. music to my ears. I could rant for hours.

Well in all seriousness, my email is sprucebruce901 at yahoo.com, I'm interested in hearing anybody's thoughts if they have 10 to 15 minutes to spare for a phone call. Especially any ideas of trade shows where I might talk to some folks in person.

You guys paint a pretty vivid and humorous picture of an operator bored at 2am fiddling with someone else's carefully constructed code. Not sure what we could do about Bubba in software, besides maybe some sort of limited "Bubba mode" where the controls are locked out like the steering wheel in a fischer price car.

rootboy
September 13th, 2016, 09:45 PM
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.

Agreed. Usually, but not always, a CS degree is your worst enemy when it comes to PLCs.

Years ago, I got tired of the CE (Central Engineering) runaround I was getting over their crummy code, and told a director to start thinking PLC, not PLC++. That got me into a bit of hot water. :)

rootboy
September 13th, 2016, 09:50 PM
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?

Bring in a new operator, an autistic preferably. Just keep an eye out for flying parts and such. ;>

https://developers.slashdot.org/story/11/10/05/235217/autism-traits-prove-valuable-for-software-testing

Andybr
September 14th, 2016, 03:25 AM
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

The moral of that story is never take a laptop to a problem until you are sure you need it. 90% of the time the problem will just be a simple hardware issue and when you walk in and find it straight away the shift guy will feel silly so next time they will not be so quick to drag you in. For the other 10% of the time hold your hands up and take responsibility for the problem and you will be able to keep some mutual respect. It only took me about 20years to learn this. That was around 20 years ago and the lesson has served me well.

willxfmr
September 14th, 2016, 03:39 AM
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.....



To me this looks like a classic case of management not having enough respect for the Bubbas to spend the money to train them, or willing to pay enough to get better qualified people. I see that a lot, and I feel sorry for the poor folks that have to come in and clean up the mess. But the root cause to me is a lack of training, and poor management decisions. Not the poor guy that was dressed up in a bacon suit and tossed to the wolves.


Will.

JordanCClark
September 14th, 2016, 11:38 AM
To me this looks like a classic case of management not having enough respect for the Bubbas to spend the money to train them, or willing to pay enough to get better qualified people. I see that a lot, and I feel sorry for the poor folks that have to come in and clean up the mess. But the root cause to me is a lack of training, and poor management decisions. Not the poor guy that was dressed up in a bacon suit and tossed to the wolves.


Will.

Poor management decisions first, but there's two parts to training: availability and teachability. Actually teachability even more so.

As I've been tasked to train our bubbas, I sent this letter out.

"The time has come," the Walrus said,
"To talk of many things:
Of shoes--and ships--and sealing-wax--
Of cabbages--and kingsó Lewis Carroll, Through the Looking Glass
Hi!

Been working on a training matrix and schedule and all the greatly fun things that go into planning events like this.

But, Iím at a point where I need your help. (Before you get a puffed head, everyone is getting this email. Iím separating each of you out for the sake of privacy.)

Now that the disclaimer is out of the way, Iím serious about needing help. And that in the form of getting some information from you.

As rude as this may sound, how teachable are you?

Yeah, Iíd better explain that one. Prepare for some heavy stuff in a short time. And maybe a soul-searching moment.

Deep inside all of us is the desire to improve our lives and make the world better. Whatever youíre setting your mind to, whatever youíre pointing your life at, whatever goals or dreams you have, you want to succeed.

But simply wanting to succeed isnít enough.

The world has changedóand not just in a ďmy kids donít call anymore, all they want to do is textĒ kind of way. While weíve been sliding through the technology revolution, thereís also been a shift in how we humans interact, and that has affected everything in our lives. The rules of the game have changed. And, that means the way to success in our lives has changed as well.

Let me put it this way: The desire to be successful hasnít changed. But how we get there has.

Success doesnít come to the one who works longest or hardest. It doesnít come from who you know, what you do, or where you come from. There is on element that matters more than all the rest.

Donít hear what Iím not saying. Itís not that these things that used to be linked to success (hard work, discipline, grit, willpower, even chance) donít matter any longer. They do.

They just donít matter first. Before all the other things there is one thing that matters first.

And thatís teachability.

I could give you the dictionary version of what teachability is, but instead here are two words that capture what it is, and Iíll even give you a formula for teachability that might help.

Those two words are desire and willingness. In the context here:

DesireÖ
Ö to become better
Ö to change
Ö to learn

WillingnessÖ
Ö to learn something new
Ö to relearn what you thought you already knew.

And the formula? DESIRE x WILLINGNESS = TEACHABILITY

If you rate desire on a scale of 1 to 10, and do the same thing for willingness, you would get score for teachability from 1 to 100.

Hereís a good example. I have a desire to lose 45 pounds. I put it at an 8. But, my willingness to do something about it rates a 2, because I really like my Oatmeal Cream Pies and Nutty Bars. That puts the index at 16ónot very high, and Iím not likely to succeed at losing weight.

So, hereís the soul-searching part of what I need from you. Rate your desire and willingness for each of the following. Iíll only use this to help me direct my focus to what will be most effective.

PLCs Desire _______ Willingness _______
Robotics Desire _______ Willingness _______
Sensors Desire _______ Willingness _______
Troubleshooting Desire _______ Willingness _______

Be honest here. This is just as much to help you out as it is to help me out. Iím getting too old for those 2am phone calls.

Any questions or comments, just ask.

Later!

Jordan Clark
Sr. Electrical EngineerThis gives them the opportunity for honesty-- for them as well as for me. I already know what their skill levels are. I need to know how much they want to put into it to improve their skills.

I could preach on this all day, but duty calls, and I sure some of you are thinking this::yakyak:

robertmee
September 14th, 2016, 03:03 PM
I completely understand your train of thought, but I would love to be a fly on the wall as each of your tech's read every other word of that letter. 80% on the over/under for eye rolls ;)

harryting
September 14th, 2016, 04:33 PM
I learned to bring donuts for the guys.

rootboy
September 14th, 2016, 04:54 PM
Sounds like my "Director of Engineering" with his "True North" motivational nonsense.

You probably have a bright future in upper management.

JordanCClark
September 14th, 2016, 05:38 PM
Sounds like my "Director of Engineering" with his "True North" motivational nonsense.

You probably have a bright future in upper management.

Sure I do, but:


I don't want the pay cut
I don't want the series of operations

lobotomy
removal of spine and testicles


What I wrote is completely true.
True North is a "Follow Your Dreams" derivative

Yes, it's nonsense. Dreams are good, but it's better to follow your opportunities.



In the end I can only share what wisdom and knowledge that I have. Sometimes it will sound like reproof, sometimes condescension. Whether anyone listens or not is up to the individual.

Epy
September 15th, 2016, 12:02 AM
Sure I do, but:


I don't want the pay cut
I don't want the series of operations

lobotomy
removal of spine and testicles


What I wrote is completely true.
True North is a "Follow Your Dreams" derivative

Yes, it's nonsense. Dreams are good, but it's better to follow your opportunities.



In the end I can only share what wisdom and knowledge that I have. Sometimes it will sound like reproof, sometimes condescension. Whether anyone listens or not is up to the individual.

hahaha

willxfmr
September 15th, 2016, 01:08 AM
Poor management decisions first, but there's two parts to training: availability and teachability. Actually teachability even more so.

As I've been tasked to train our bubbas, I sent this letter out.

This gives them the opportunity for honesty-- for them as well as for me. I already know what their skill levels are. I need to know how much they want to put into it to improve their skills.

I could preach on this all day, but duty calls, and I sure some of you are thinking this::yakyak:


I've got $20 on the over for eye rolls....

All kidding aside, you have a realistic approach of trying to decide who gets trained for what. The issue I run into is the fact that management simply will not spend a single dollar on training. The bring in new equipment, promise training, but when the time comes to pay for it.... nothing. The closest we get to training is hanging out with the person doing the startup and asking them a million questions. The problem with that is, they have their own job to do and generally don't have the time or desire to provide free training.

/start rant
A perfect example was a short time ago we added a new x-ray machine to one of our lines. The first time it was supposed to run on my shift, I get called up to the line because nobody can figure out how to start the thing up. I tried going to the setup screen, but needed a password to get in. Of course the only people that knew the password were at home sound asleep.
Well guess what? Bubba doesn't like secrets and he will make you divulge what you know at the most inopportune times. So after ringing the engineers home and cell phone for about 30 min, (Bubba is nothing if not persistent) I get let in on the secret location of the manual for the unit, that also has the secret password written in it. Too bad it's locked up in the engineers office! Well golly gee Mr. Engineer, I'll let production know that they will be down until you get here with the key to your office. Take your time, I'm here until 5AM.
The company that installed the unit offered to do operation and maintenance training on all 3 shifts before we started running production on that line, so we would have a clue how the thing worked, and more importantly how to fix it when it's not working. BUT.... They wanted $500 dollars per shift to do a 4 hour training session. Our engineer said there was no way they could justify such an "exorbitant expense". Five hours of downtime, and a 1 AM phone call... Sure we can afford that, no problem. But shell out $1500 to avoid it. No way, can't be done.

If you try to bring up any of the Rockwell or Fanuc classes, you get told to find something on YouTube. "That's just as good as going to the classes"
I personally have a great desire to learn, and the willingness to put in the effort. But where I work now, nobody cares, because the will be no training. Get used to it.

/end rant

Will/Bubba
*From here on to be known as Wubba. :)

PLC Pie Guy
September 15th, 2016, 04:43 AM
CONFESSION:: Sometimes I pay for my own training!
I started as an Industrial Electrician simply with an interest for controlling things. I got good at but I wanted more.
If I had been waiting for my original Bubba automation want to be employer to send me, I would still be there too, dragging teck cable through miles of sludge and such!
Some training later and a little bit of offering free help to an onsite integrator for some needed experience and I get to work on my own projects for my current company now instead of hiring an integrator.
I still have more courses to take that I will likely pay for myself as well.
It bites paying out of pocket but if the training is what you want, take it!
It will pay off.

Just realized this is getting way off the OPs topic.

SORRY

redbarron55
September 15th, 2016, 11:00 AM
Currently my job is to make the plant absolutely, positively, 100% reliable so that they can do without me.
The manager has been getting the "Bubbas" to install floats and old relay level controls for the various sumps and wells so that they can run the plant in manual.
A big rush back to the 70's for greater reliability!
I was working in the 70's and I don't remember it being as reliable as what we have today.
This plant has been running for 7 years whit never a failure that interrupted the process and the guy is worried.
Since the "Code Black" project started we have had some failures with parts of the plant..... all related to the Code Black changes.
Really what has the world come to .
Let's go back to the 70's since we don't want to train our maintenance personnel for current technology.
I have offered to have training and have put on classes, but no one really wants to put forth the effort to upgrade their "skills".
I guess pretty soon we will rip out the wonderware and plc's and put back in relay logic and big boards with lights and meters.
This is with a Wonderware / Modicon system.
Guess how well they understand the Siemens PCS-7 system in another part of the plant!
After 45 years in the business I am pretty well fed up with this turn of events.
18 more months to 70 and outta here!

agarb
September 16th, 2016, 08:28 PM
I interpreted the intent of this thread to be more about PLC-specific problems as opposed to dealing with customers, management, Bubba, etc.

So here are mine:
1. Software from different vendors not installing and co-existing beside one another on the same PC. Even worse is that this problem even exists with some software packages created by a single vendor. My work around is virtual machines but this entails a performance loss and managing 15+ virtual machines is rather cumbersome.
2. Complex, large, cumbersome software installs. (Wonderware!)
3. Software packages that save the project across multiple files/directories, etc. (FactoryTalk View, Wonderware, Step 7, etc.) I'd much rather have one project file (Logix5000, PanelBuilder, etc) that is easily found, archived, transferred, etc.
4. Non-intuitive software that lacks context sensitive help.

travispedley
September 16th, 2016, 11:06 PM
My biggest ***** is when I spend weeks developing a machine that does 50-60 vision inspections on a product because their end user has received parts that are incorrect, incomplete or out of spec and my customer wants me to add an HMI screen to allow them to enable/disable the inspections. Then quality finds out about it and gives me a black eye for putting it in the program. You know, the bypasses I was specifically told to put in by the guy who signs the checks.

Liam Moran
September 17th, 2016, 01:16 PM
Bring in a new operator, an autistic preferably. Just keep an eye out for flying parts and such. ;>


As the father of a 15 year old with Aspergers I find that remark objectionable. Not for its content, just by the level of ignorance displayed by it.

willxfmr
September 17th, 2016, 10:59 PM
As the father of a 15 year old with Aspergers I find that remark objectionable. Not for its content, just by the level of ignorance displayed by it.

Did you read the link that was also in the same post?

I did not take his post as being disparaging to people with autism. Rather I think it showed that some autistic people are in fact superior at debugging programs than people that are not autistic.


Will.

rootboy
September 18th, 2016, 01:05 AM
As the father of a 15 year old with Aspergers I find that remark objectionable. Not for its content, just by the level of ignorance displayed by it.

Really? So I offended you by pointing out how they are vastly superior to "normal" humans. I guess that we are all offended by something...

As an aside to your child, tell him or her that it gets easier over time.

Peter Nachtwey
September 18th, 2016, 01:34 AM
You guys are off topic. You are complaining about people, not the PLCs.

m_turk
September 18th, 2016, 03:31 PM
You guys are off topic. You are complaining about people, not the PLCs.

Yeah, but.. The PLCs do what you tell them, the people are not so easy to command... :)

redbarron55
September 19th, 2016, 07:04 AM
Yeah, but.. The PLCs do what you tell them, the people are not so easy to command... :)
The true variable!