ladder diagram scan for trouble shoot

Hi
How to scan ladder diagram for trouble shoot in case of brakdown in machine. I mean is there any specific method or hit and trial method is used. Specially when we do not know the operation of machine and operator give very brife discription of brackdown events. if single scan playing any role. Thanks

What you are asking is almost impossible - if I understand your question.

If you don't know what the machine is doing then how could you possibly now that there is a problem, or where it exists.

If the operator can not give you an error point in the process, again what do you look for?

It would be like scanning a conveyor system in Cleveland, Ohio looking for boat traffic in the Panama Canal.

Good luck,

Rod

I wrote something similar to what Rod did but didnt post it. I agree that you have to at least understand the basic operation of the machine. You also have to understand how the components used on the machine works.

Assuming you have a basic idea of how the machine works the next step is to determine at what point the problem occurs. In many cases you dont need to hook a PC up to see the ladder, those little lights will tell you ALOT....ie you push START button but it doesnt start, you look at PLC and input for start doesnt light when pushed so you then check for voltage at the PB and/or continuity thru the PB, the results determine the next step. Thats why its always nice to have a drawing or at least a P&ID available, drawing is better.

There may be times when it seems that all I/O are working properly but the machine doesnt perform properly. THEN you connect a PC to the PLC and go online>then find the section pertaining to WHERE the problem occurs...the next step depends on what you do or dont find.

Troubleshooting is like art or music etc, its a skill that is developed over time. Like art, music etc some people seem to have a natural talent for it but it still takes time to truly develop.

One way to make troubleshooting faster is take the time to learn the machines. When not busy spend time at the machine(s), talk to the operators, help them run it and learn how to run it.

Another option that can help is attaching an HMI and creating as many "alarm" messages as you can. Its so neat when the screen tells you CF2 no voltage...ie control fuse 2 is blown.

Someone MUST take the time to learn how the process works!

If a problem occurs and no one knows how the process works, then asking for a "fix" would be like calling a welder to fix your defective wrist watch.

Hmm... maybe if I crank up on the Amps... "CLEAR!"

Once someone finally takes the time to learn how the process works... you still have a problem.

"Can you come fix this machine?"

"Yeah, maybe. I'll be right over."

"OK, I'm here... what's wrong?"

"It's broke."

"Yeah, I know... but what's wrong?"

"I don't know... All I know is it stopped! Right in the middle of running it stopped!"

"So, what happened?"

"It stopped running."

"Why?"

"I DON'T KNOW! Isn't that why I called you?"

"Hmmm... What did you do just before it stopped?"

"Nothing! I was sittin' here watching it run and it stopped."

So... bottom line in this exchange is, even if you do get substanitive answers, the answers can't be expected to provide any real insight.

more later...

What Terry said...

having said that though. The typical step with an unfamiliar machine is to:

-Ask the operator for the best "guess' as to which device is supposed to be energized.
-trace the device down to its I/O point.
-Search the PLC for that I/O point and see why it is (or not) energized.

At least that's what I do.

The most valuable tool...

One of the more common points touched on is the operator. That is my first stop. An operator is, in all likelyhood, your most valuable tool. Keep it clean and happy...and occasional coffee or pop doesn't hurt either. I've found that operators can get attitudes toward Tradesmen very quickly from the offset in pay, if nothing else. Remember, alot of us were operators of some sort at one time or another. Keep an open channel of communications with them, it will pay in the end. If the operator can tell you the 'last' function or operation performed it should be fairly easy to pinpoint that in logic, either printed or online.

I agree with Ron, troubleshooting is an art form. It takes time to develope and apply it. Enjoy it...don't let it be a chore.

Bob

Allow me to interrupt. I've seen the same problem that you are facing. That happens when you have Mr A (mechancal background) from department A and Mr B (instrument background) from Department B. When there is a problem, Mr A will say,
"Oh! that was PLC problem" and Mr B will say
"My PLC is running find. No red LED on the PLC".
There is nobody in the middle combine these two people and start scrathing a fishbone.

The best thing is that you call Mr A and Mr B and whoever is related to the machine (minus the Civil guy I guess) and do a brainstorming using whatever tools that you have.

You can use the session to find the problem as well as learning the machine more.

TQ.

Yes, always go to the Operator! Usually the first questions I ask are:

- What's happening?
- What's not happening?
- What's supposed to happen next?
- What's the last thing that happened?

And the bonus question that usually yields the most interesting answers:

- Has anyone worked on this recently, or did you just have a change over or something?

Asking these questions usually gets me enough information to point me in the right direction.

rstech said:

Yes, always go to the Operator!

Click to expand...

We don't have operators on our cranes, they are fully automated.

In this case I agree with what Terry wrote...

Someone MUST take the time to learn how the process works!

Click to expand...

Paul

PLucas said:

We don't have operators on our cranes, they are fully automated.Paul

Click to expand...

Well yeah, I guess that would eliminate the Operator approach. However, sometimes the Operator digs the hole a little deeper for you too. If a fully-automated system broke down it wouldn't start wiggling sensors, pushing buttons, overiding switches, etc.

I guess it all depends on the equipment, Operator (or lack of), etc. Point well taken.

rstech said:

However, sometimes the Operator digs the hole a little deeper for you too.

Click to expand...

All the more reason to go fully automated..

I was trying to make the point that you do need to take the time to learn the process, wether it is operator controlled or not.

rstech said:

If a fully-automated system broke down it wouldn't start wiggling sensors, pushing buttons, overiding switches, etc.

Click to expand...

No it wouldn't.. Our technicians do that!

I am a firm believer in learning about what you work with, learning the process is just part of this.

Taking the time to learn the process reduces downtime of the machine, in the long term.

My 2 pennies worth

Paul

PLucas said:

I was trying to make the point that you do need to take the time to learn the process, wether it is operator controlled or not.

I am a firm believer in learning about what you work with, learning the process is just part of this.
Paul

Click to expand...

Absolutely, I can't argue with that. Unfortunately, as a Contractor, I am often called to equipment I have never seen before let alone seen running! One day it might be a welder, the next an electro-plating line, the next an assembly machine. You get the picture. In these cases, you learn as you go. This is where an Operator is very helpful and can speed things up. That was the point I was trying to make.

But I couldn't agree with you more, knowing the process is a huge asset when it comes to troubleshooting and this is where I usually have to rely on the Operator.

PLucas said:

In this case I agree with what Terry wrote...
Paul

Click to expand...

Paul,
I know you hate to agree with anything that I might have to say, but... you have an out... you are only agreeing with the purity of my logic.

There, now it's not sooo bad.

PS...
I still believe, and KNOW that being able to read a schematic does not a programmer make! Being able to read a schematic only means that it might be possible. There's just too much proof to see it any other way.

And... just to stir the pot a bit more... I know many excellent programmers that have never seen a schematic!

A School Bus is Yellow (at least, they are so here in the States)... does that mean that any Yellow vehicle is a school bus? (Logic-101).

Terry Woods said:

Paul,
I know you hate to agree with anything that I might have to say, but...

Click to expand...

Ah, come on Terry, whatever gave you that idea??

Terry Woods said:

I still believe, and KNOW that being able to read a schematic does not a programmer make! Being able to read a schematic only means that it might be possible. There's just too much proof to see it any other way.

Click to expand...

Your memory serves you well, nearly well that is.
That disagreement dates back at least 2 1/2 years, for those of you who have never read that thread.. here's what I wrote

PLucas said:

I believe any electrician who can read electrical schematics should be able to read and understand straight forward ladder logic. After all, what is the difference between the two?

Click to expand...

I still stick by that statement, I have to, after all, I said it!

But, there's no need to resurect that debate, this is one that we will have to agree to disagree on.

Paul