Operators in plants

An operator can be your best friend or your worst enemy. If an operator thinks you're trying to automate him out of a job, you're never going to get a straight answer from him when it comes time to troubleshoot.
I've found that adding a feature to the HMI based on an operator request can pay big dividends. If he thinks of you as a partner in getting the job done better, he'll be your eyes and ears helping to track down those intermittent issues.
 
An operator can be your best friend or your worst enemy. If an operator thinks you're trying to automate him out of a job, you're never going to get a straight answer from him when it comes time to troubleshoot.
I've found that adding a feature to the HMI based on an operator request can pay big dividends. If he thinks of you as a partner in getting the job done better, he'll be your eyes and ears helping to track down those intermittent issues.


I couldn't agree more with this. I do, however, subscribe to monkey theory. Monkey theory is this idea that if you can twist it, step on it, climb on it, or otherwise monkey it around, someone, somehow, will figure out a way.
 
I get lied to darn near every day by operators.

What happened? "Don't know, it just stopped. Maybe the program has a glitch."
Did you change anything? "Nope. I think the computer is acting up."
Has anything changed since you started this run? "No, it just stopped for no reason. There must be something wrong with the program."

After some research and troubleshooting....
Did it stop before or after you changed the recipe to the wrong product? "Umm...After?"

These kinds of exchanges are a regular part of my day. The trick is to know which operators you can trust, and which ones are going to deny everything. The trust worthy ones are your very best friends, and you need to buy them pizza on a semi-regular basis. The others are your worst nightmare and will send you diving headfirst into the rabbit hole every chance they get. I imagine it is hard to figure out who is who if you're only at a plant long enough to commission a new machine, and then move on to the next job. But for me, knowing who is who is an important key to being able to keep lines running.

I have suggested trying to setup some sort of data logging of operator inputs where I work, but if it costs more than a nickle, it doesn't matter how many dollars it will save. We won't spent the nickle. It's really a shame, the few machines we have that came with data logging are the easiest to fix. Usually, all you have to do is look up what parameters were changed before it "just quit working" and change them back.


Bubba.
 
Last edited:
I've found that adding a feature to the HMI based on an operator request can pay big dividends. If he thinks of you as a partner in getting the job done better, he'll be your eyes and ears helping to track down those intermittent issues.

This is a big one. Lots of times it's dead obvious stuff but someone missed it and plenty of systems limp along for a long time.

I've never seen audit trails provided built in by plc or hmi but that sounds nice.
I never saw them on the PLC, but they are common in HMI's, particularly for pharma.
 
+1 for Steve Bailey. I was in a plant that had a lot of older CNC machines, and the operator of an old Fadal was my BFF because I fixed the tool changer that hadn't worked in about 8 months, thus tripling his production. I got an emergency call that the Z axis had stopped working, and all these plant folks are standing around looking at their watches, and I had no idea where to start. He told me about 6 years ago when this happened the electrician at the time pulled all the boards out and cleaned the contact points with an eraser, and handed me an eraser. What the heck, I thought. It's not running now. Cleaned all the boards, badda bing!! up and running. Hero for another 45 seconds. (There's only one letter difference between "Hero" and "Zero")
Most of my projects now the folks blame the program. Running flawlessly for months, and then, bang! program is causing the problem. Until I explain to them that THEY were the ones who wanted this secure screen, and a different start sequence, and THEY didn't remember it. Program is working like YOU wanted it to. Of course I have bugs and errors, but to quote aabeck, "never underestimate the quality of idiots running your machines." I really like that. My boss tells me as a programmer, one is supposed to think of every possible scenario regarding the operation of the machine. And then someone will trick something out you had never planned for. Always.
 
I do, however, subscribe to monkey theory. Monkey theory is this idea that if you can twist it, step on it, climb on it, or otherwise monkey it around, someone, somehow, will figure out a way.

I just call it in a different way: a human is always smarter than any machine. Always. No matter how dim and uneducated he is, he will always - again, always! - find a way around anything.

Some humility in our profession never hurts.
 
1. People generally will put blame on things that they don't understand. (The automation system)
2. People will almost never admit there own faults. (This happens with the operators and the programmers)
3. Despite a programmers best efforts to anticipate every possible scenario operators will always find the one scenario you didn't anticipate.

Just my 2 cents


well said.
 
If possible or practical I always ask the operators how they want the screens arranged.
This goes a long way,
they like to give input and does make their life easier.
And you would be surprised how many time the operators are amazed someone is asking for their input.


On the other side,,,
years ago when I was hired my boss gave me some good advice...
"never believe anything the customer tells you" :)
 
First of all, human observations (eye-witness accounts) are notoriously unreliable, even in situations when we are trying to look for something. In most situations where something goes wrong we aren't waiting for it to go wrong, which means we aren't looking. This only makes eye-witness reports less reliable. In addition, because we would (presumably) be in a pressure situation, we probably forgot half of what we did in the minute leading up to the issue, which is the most important period of time for evidence gathering. A different twist on this is that we will sometimes perform an action that we believe is unrelated to the outcome but is, in fact, integral to the outcome, unbeknownst to us. The action isn't reported because it isn't seen as relevant. All-in-all, people are horrible sources of information.

Add to that the fact that controls systems are generally closed environments that we have no direct knowledge of and (specifically in the OP's case) we have a machine that is likely new to the operators or, at least operating in a different way. The control system will be the odds-on favorite target for blame.

PLC-resident state and logic loggers and traps are a good idea if you are hunting a specific fault. It can be a little difficult to decide what to log some times but it can be extremely helpful.

As was stated before, if you want any real information out of the operators, both you and the operators need to be on the same page concerning what the machine or process should do in the first place. What the operators see as wrong may not be wrong, just different. Just as importantly, what the machine or process is doing may be what is intended but it is not what needs to happen based on operator experience. The only way to handle either of these is for the developer and the operator to agree on proper operation. That doesn't mean you need to necessarily bend to the operators picture of what the machine to do. But at least the operator knows what should happen.

I had a case years back in a previous life that highlights both of the previous points. We had a machine HMI that was written in C and run on a DOS machine. The HMI maintained the recipe information and was an integral part of the machine order change sequence. We would get random reports, usually on second shift, that order changes were not completing. We had no immediate idea why. This HMI would log fault and action data in a text file if desired. We had the plant start a log and then send us the text file after the next issue they had. Looking at the log file, all alarm and event logging just stopped about 30 minutes before the issue. Up until then everything was working just fine. It was like the program froze. If the program didn't acknowledge that the order queue shifted as part of the order change the order change wouldn't complete. We told the plant to check the HMI operational status the next time this happened. Turns out the operators were shutting down the HMI program and playing Gorillas while the machine was running. So this is a double whammy thing. The operators didn't understand that the HMI program was an integral part of the order change sequence (that isn't particularly intuitive). Also, we would not have suspected something like this if we hadn't seen the log file.

Keith
 
Commissioning a new system, had several people "play" with it.

found several minor potential problems with operation sequence I had not anticipated, and off I went operator-proofing equipment...
 
Commissioning a new system, had several people "play" with it.

found several minor potential problems with operation sequence I had not anticipated, and off I went operator-proofing equipment...
For many years we have referred to field testing of equipment as "idiot proofing"1
 
Commissioning a new system, had several people "play" with it.

found several minor potential problems with operation sequence I had not anticipated, and off I went operator-proofing equipment...


I saw this post on Reddit a while ago and well if this doesn't perfectly describe commissioning and then handing over to an operator then I don't know what does.
A QA tester walks into a bar...
A QA tester walks into a bar and asks for a mug of beer.
A QA tester walks into a bar and asks for a cup of coffee.
A QA tester walks into a bar and asks for 0.7 mug of beer.
A QA tester walks into a bar and asks for -1 mug of beer.
A QA tester walks into a bar and asks for 2^64 mugs of beer.
A QA tester walks into a bar and asks for a pet bunny.
A QA tester walks into a bar and asks for qwertyasdf.
A QA tester walks into a bar
A QA tester walks into a bar, climbs out of the window and walks back in through the door.
A QA tester walks into a bar, walks out of it, walks back in, walks back out, walks back in and beat up the bartender.
A QA tester walks into a bar and asks for NaN cup of null.
A QA tester walks into a bar and asks for aa cupcup of beercoffee.
A QA tester walks into a bar and deletes the bar.
A QA tester walks into a bar pretending to be the owner, drank 500 mugs of beer and did not pay.
5 QA testers walks around a bar.
20 QA testers walk into a bar.
1000 QA testers walk above a bar.
A QA tester walks into a bar and asks for a mug of beer'; DROP TABLE bar;
The QA testers were very satisfied and left the bar.
A customer walks into a bar and asks for a hotdog.
ERROR.


Some of the comments on the thread are absolute gold as well. I think my favourite has to be:
How did the "and asks for a pet bunny." work and the "and asks for a hotdog." fail?



Unlike "pet bunny" and "qwertyasdf", a "hotdog" is an actually valid food choice, but not of the beverage type. Unfortunate edge case that was overlooked.


Here's the whole thread if you want a good laugh
 
I like this thread.

Once upon a time, many many years ago, I had an operator tell me "The machine did
just like it does when that light is burnt out!" Pointing at an incandescent lamp which
shone across the machine focused on a photocell used for positioning. The lamp was
burning bright as day.

She was one of the good operators. So I walked around the room, came back, looked
at the lamp and it had gone out. When I started to change it, it came back on again.
I replaced and re-focused the lamp. (We can replace a LOT of lamps for what one
unplanned shut down would cost.)

By the way, those incandescent lamps were replaced with solid state retro-reflective
photo eyes a few years later.

And, yes, a good operator is the maintenance guys best friend.
Poet.
 

Similar Topics

Good Evening , I am working on a Panelview Plus application.This is a plant that runs 24 /7. Sometimes operators don't share information ...
Replies
1
Views
1,411
Anyone have an idea of how to create a FIFO que and storage network using only the folowing instructions (and,or,not,xor). I'm working on a...
Replies
17
Views
8,114
Using CoDeSys 2.3 for the first time. I've not been able to use in line comparison operators successfully in Ladder - and haven't found any...
Replies
11
Views
9,080
Have you ever had to go in to a plant/shop with the mission of automating a manual machine and have to learn how the machine operates, from the...
Replies
8
Views
4,124
Hey everyone, Please share stories that you may have of operators, not knowing how to do their job, my most recent one was on a service call...
Replies
44
Views
10,719
Back
Top Bottom