PLC "troubleshooting experience"

Quick question relating to my job search.

Some job descriptions state "PlC troubleshooting experience" as either a requirement or a plus.

What exactly are they looking for? I dont think they literally mean fixing the PLC since they just throw em out.

So far from what I gather here,Im thinking they mean "troubleshooting using the PLC program as a guide".

So if I was on an interview and the guy said "Ok pretend the line shuts down" based on your "plc troubleshooting experience what would you do" as a test of my supposed PLC literacy?

From my scarce knowledge so far, here goes, I would ask if it was a SCADA controlled process, find a terminal or plug in a laptop somewhere (into the ethernet or rs232 of a nearby PLC?) open up say MODBUS for example. I would proceed to use its diagnostic functions whatever they are to see what condition triggered a shutdown.

I would hopefully look at a nice graphic of a machine and see an error message like "error number whatever, banding machine time out (for example), and scurry off somewhere around the end of the line where the banding machine is, fluke in hand, see that the banding machine was jammed, clear the jam, then go back to the MODBUS terminal or laptop and click on a "problem fixed resume production" icon or whatever?

If no SCADA, then find a nearby PLC cabinet, Plug in a laptop with a rs232 or ethernet cable and open up RSlogix or whatever ladder program they run on, see what the program thinks
is wrong, hopefully the programmer has made nice handy notes that tell me something in the banding machine triggered the shut down, go fix the banding machine and then tell RS logix to start the line back up?


Is this the drill? Im not looking to pass for an automation expert, I just want to not sound 100 percent PLC ignorant like my last interview.

A lot of jobs dont expect you to program them, I would think they would in fact not want you monkeying around with the program for safety reasons. If all I have to do is find my way around a PLC platform program, could I download a sim and rslogix right here at home and start playing with it? No hardware required?

TIA guys feel free to point out something Im not getting!

Enjoy
http://www.ab.com/programmablecontrol/plc/micrologix/downloads.html

some of the advice in this recent thread might be helpful to you ...

http://www.plctalk.net/qanda/showthread.php?p=386247&postcount=1

my personal "best shot" starts in post #14 - but I'd read the whole thread if I were you ...

and another ...

http://www.plctalk.net/qanda/showthread.php?p=82534&postcount=1

see post #7 for what I personally think might be impressive on a job interview for folks who don't have any real-world experience behind them ...

Thanks guys, Time to go bum supper at a friends house, I appreciate the response and will check those links asap!

Say Ron, are you the same RB on the "boot camp" series Ive bee absorbing on you tube?

Outstanding videos and I like the concept. Ive learned from electronic diagnosis that it only takes one tiny false assumption to ruin an entire conclusion. Everytime I did a post mortem on a bad diagnosis, 90 percent of the time a seemingly reasonable conclusion that just wasnt really true was where things got off track.

In answer to the question, PLC troubleshooting would be fault finding using the PLC as a tool.

The HMI is another tool, this would probably be the first stage to look at the alarm, it can sometimes tell you exactly what the fault is, i.e. 'overload x tripped'. Sometimes it can point you in the right direction, 'stage x timed out', in this case it will tell you something is taking too long but not why.

To troubleshoot using the PLC is to access the PLC code via the PLC programming program, which will allow you to look at the code status.

This is not the HMI, it is usually on a laptop which you would connect to the PLC. For AB it would be Ethernet or ControlNet usually.

What you would usually see would be a graphical representation of the code (ladder logic) which will show what is live and what is dead, like looking at an electrical schematic diagram which comes to life with the current status.

Then go through that looking for what is causing the fault.

Above all else, do not lie at an interview, if you can get some programming software to look at then that will help you understand but you would have to tell the possible employer that is what you have done.

I know Siemens have a free limited version of Step 7, but I feel in your geographical position it would be as useful as a chocolate teapot, you would need to get hold of ControlLogix by AB.

Great info much appreciated

I hurried thru Rons post and his signature clearly states he is indeed the Ron B. of the "PLC bootcamp" series. I try not to ask obvious questions but it happens! Anyway the series tries to nip false assumptions in the bud and dosent assume you know something you might not. I was relating these most wise concepts to my own experience. The beginning is a good place to begin a given subject. Some other sites jump right into the latched relay around the start switch, but thats not really square one.

Anyway those were some great threads there Ron, should keep me busy going thru all the links there.

Thanks for the links to all the software downloads Bob, now maybe I can keep myself occupied without bugging everyone with my newbie questions!

Thanks for the peek into the real world of PLC troubleshooting, Peter. It was similar to about what I pictured it was to be. Again, Im not seeking to be an outright PLC fraud, but rather to be able to semi-intelligently converse about PLCs at least the most basic concepts, instead of a blank stare. Yes, I think Allen Bradley dominates the PLC market down here.

Quick question Peter, regarding using the HMI. I was under the impression that the HMI was a custom made program just for a particular machine?

Wouldnt I have to go into the diagnostics of the banding machine HMI in my example and thus have to know the banding machine was what triggered the shutdown in the first place?

Or, since everythings networked on the ethernet, could I just walk up to the nearest HMI on the line and access the banding machine timeout error and diagnostic help anywhere?

Also could the banding machine guy just clear the jam, hit the green button or tell the HMI alls well and start the whole line back up again?

I ask because operators on the other side of the factory might be messing with something and the machinery starts running.

Or does everyone start there own machine back up?

The HMI is usually an input/output device to the PLC and while it does have a program inside it, that program would likely not be the issue (although if it's sending the wrong data due to the operator, it could cause a problem--but the HMI PROGRAM is still okay).

More likely a jam, material break, or machine component is the culprit. Programs don't typically break. You CAN however go online to the PLC and find out what the system is doing or not doing. If the PLC is saying to stop the bander, what is telling the PLC to stop? That's where a PLC can be a huge diagnostic tool even though it's doing its thing like normal.

Contrary to operator's opinions, the PLC rarely fails or causes a problem on its own. The problem is (99% anyway) an outside input or output that has failed in some way. That's where you DO need the PLC to diagnose what when wrong, and then go troubleshoot the end device.

The other 1% is when the operator happens to arrange his sequence of operations in his own way, which was never, never envisioned by the engineers and programmers who developed the program... trust me, this happens. This is when you have to do a little coding to cover the "what ifs" situation. Remember in my other thread where I talk to the operators about how he operates? This is why.

Between the engineer who designs the system, you the programmer, and the operator, there are three completely different mindsets operating, and you WILL NOT understand the others sometimes. I've been down that ragged road before...

It looks like you need basic troubleshooting experience. PLC troubleshooting is no different than anything else. You check for power, condition of lights, trouble with IO, is the PLC in "RUN", stuff like that, pretty much as you do in any other component. The HMI is a tool, which may or may not help you out. I've seen some with the IO mapped to special diagnostic screens, but overall this type of diagnostics is useless to me. Access to the PLC is key. I think you'll find basic troubleshooting skills apply to most PLC diagnostics, regardless of what the operator says. "The PLC tripped us out again!" is a statement you will learn to sagely nod your head to, and then proceed to go unjam the bander, as you used in your example.

Oh, and diagnostics for all equipment do not exist in the PLC. Eyes, ears, and nose work wonders!

>>Contrary to operator's opinions, the PLC rarely fails or causes a problem on its own.

I can tell that tomalbright works offshore with this statement!!!

tomalbright hit the nail on the head. most of the time the issue will be with an end device. whether you need the plc to troubleshoot the problem will depend on how familiar you are with the process and also the equipment. alot of it will be industry dependent also. some industries may need to make changes in plc logic more often than others.

the same thing - said in a slightly different way ...

http://www.ronbeaufort.com/qa_wtmto.htm

Experience counts, but logical thinking is of essence. When the machine stops for some reason you'll need to trace back to the condition that keeps it off. Let's say some motor isn't turning on, and the HMI/SCADA isn't giving a hint to what may be wrong.

Enter the ladder diagram and go on-line. Use the find function to locate the output coil for the motor. Look at the rung, there will be some contact keeping it off. Again use the find funtion and locate the coil for that contact, look at the rung. Sooner or later you'll find a rung with an input in the wrong state. Now go and have a look at whatever is connected to that input. Yes, you'll have to grab some tools and get your hindy off the chair.

Sometimes, rather than an input there may be some logical condition or interlock creating the issue, there are no really hard and fast rules.

It's usually some unsignalled condition, something broken or the BOFH forgetting to turn on something and the whatever sensor interlocking. Unsignalled conditions really shouldn't happen, but they do. Sloppy programming or limited resources in the HMI.

It looks like you need basic troubleshooting experience. PLC troubleshooting is no different than anything else. You check for power, condition of lights, trouble with IO, is the PLC in "RUN", stuff like that, pretty much as you do in any other component. The HMI is a tool, which may or may not help you out. I've seen some with the IO mapped to special diagnostic screens, but overall this type of diagnostics is useless to me. Access to the PLC is key. I think you'll find basic troubleshooting skills apply to most PLC diagnostics, regardless of what the operator says. "The PLC tripped us out again!" is a statement you will learn to sagely nod your head to, and then proceed to go unjam the bander, as you used in your example.

Oh, and diagnostics for all equipment do not exist in the PLC. Eyes, ears, and nose work wonders!

Click to expand...

Ditto,Ditto
This method is called "Front Panel Milking". You put your hands in your pockets and open your eyes. It's amazing what the indicating lights on the processor and input/output modules can tell you. Some fuse holders even have leds. HMI's, if you have one with alarm screens.

tomalbright said:

Contrary to operator's opinions, the PLC rarely fails or causes a problem on its own. The problem is (99% anyway) an outside input or output that has "failed" in some way. That's where you DO need the PLC to diagnose what when wrong, and then go troubleshoot the end device.


Oh, and diagnostics for all equipment do not exist in the PLC. Eyes, ears, and nose work wonders!

Click to expand...

ydtech said:

Enter the ladder diagram and go on-line. Use the find function to locate the output coil for the motor. Look at the rung, there will be some contact keeping it off. Again use the find funtion and locate the coil for that contact, look at the rung. Sooner or later you'll find a rung with an input in the wrong state. Now go and have a look at whatever is connected to that input. Yes, you'll have to grab some tools and get your hindy off the chair.

Sometimes, rather than an input there may be some logical condition or interlock creating the issue, there are no really hard and fast rules.

It's usually some unsignalled condition, something broken or the BOFH forgetting to turn on something and the whatever sensor interlocking. Unsignalled conditions really shouldn't happen, but they do. Sloppy programming or limited resources in the HMI.

Click to expand...

Mickey said:

Ditto,Ditto
This method is called "Front Panel Milking". You put your hands in your pockets and open your eyes. It's amazing what the indicating lights on the processor and input/output modules can tell you. Some fuse holders even have leds. HMI's, if you have one with alarm screens.

Click to expand...

Double ditto, ditto and ditto. I love those BFI (blown fuse indicator) type fuse holders.

Another favorite operator saying "The PLC program has changed somehow", even if nobody has been near the PLC. I normally just nod my head, go online and find the faulty culprit