T-shooting and Intermittent problem

The intermittent problem is that a press we have stops in the middle of its cycle. No faults or errors are showing up, and it doesn't happen at the same time in its cycle. Checked for loose wires, eyes, etc. In fact, it may run for 10 minutes or 10 hours. We are using RSLogix 500 on SLC 1500 plc. What is a good tool to use, instead of looking at the suspected rung for hours, to check certain rungs or bits for the intermittent problem? Will establishing a trend be a accurate tool? I believe establishing histogram would be a good tool, but from what I can tell, you can only setup the histogram to monitor one word. Now if I could watch 3 separte bits from 3 separate words, then I could see the pulses, just like watching a scope, to verify bits are activated properly. Any ideas would be helpful.

Two things I have done is:

Add a counter to toggle every time a certain condition occurs. You would have to narrow the probelm down to a few rungs.

Add a unlatch bit at the end of ladder 2 to clear any math overflow errors. (S:5/0) It's crude, but it has gotten me out of a few jams. It doesn't sound like this is your problem.

If you are using RSLinks OEM, you could use the DDE tool to rapidly collect certian bits & words and plot them in excel. :shrug:

Just my 2 cents...

Try setting up a latch that can only be set when the condition you suspect of causing the fault is true. Don't put in anything to unlatch the bit. Later, after the machine has faulted, you can connect to the PLC and see if the latch is on. If it isn't, you know that something else caused the fault.

Be sure to document the rungs you add in case you need to leave it in place for a few days while you track down the fault. That way, if someone on the night shift has to troubleshoot the program, they won't be confused by logic that doesn't appear to do anything.

I would think that the most common thing to do is to make each variable that would stop the press activate a latch bit. When the cycle is complete unlatch all of them. That way, when the press stops in mid cycle, all you have to look at is which bit is latched and what activated it.

Hydraulic press? Had the same problem, turned out to be the valve (Parker) was intermittent.

I believe establishing histogram would be a good tool, but from what I can tell, you can only setup the histogram to monitor one word. Now if I could watch 3 separte bits from 3 separate words, then I could see the pulses, just like watching a scope

Click to expand...

Create a word like B10 and associate these bits to those you want to monitor and do the histogram to monitor that word.

To verify you dont have a stop or estop contact/wire issue then create code to tell if they are pushed after its running, if it says it has been pushed and noone has then the problem is in the stop circuit.

For your histogram, you could simply write a new word that combines all the bits of interest to you and log that.
Like jstolaruk said, don't think it is just in the program or electrical. How long has the process been running? The longer it has been running without problems, the less I would suspect the program and look for outside sources.

Are there light curtains on the press? We once had a case where the flashing light on a fork truck was interfering with the light curtains and causing a machine to shut down.

You may also want to put timers on each step of the sequence and then set latches if the timers time out. Set the timer for more than the expected time the step will take.

If you use a histogram, be aware that it might not be fast enough to catch every change of state that may occur during program execution.

Quote from RSLogix500 help:

...Since there is no native histogram function in the SLC/MicroController processors, data polled is subject to performance limitations such as the speed of the computer, the speed of the comms link to the processor, the number of views active, etc. And for data changing faster than one change per second, every change may not be represented on the histogram view.

Click to expand...

RSLogix 500 - Copyright Rockwell Software 2000, 2001, 2002

Could your problem be external to the controller? Maybe a stop input on a drive dropping out briefly? If so, you can wire a relay with a manual operator like this:
...................... CR1.. CR1
input wire to test->---] [---( )---common

Connect the input wire to the suspect circuit. Push the manual operator and the relay will latch closed. If power is ever interupted momentarily, the relay will drop out as evidence. This only works on circuits that are always hot. (Each time the control system turns off the input wire, you'll have to manually reset the trap.)

if you can't trust your histogram, who can you trust? ...

the histogram probably won't catch it ... read this post ... why not post your code? ... maybe we'll be able to spot something that you're overlooking ... and even if it's not being directly caused by the program, we might be able better suggestions about troubleshooting techniques ...

I dont think he was blaming the program, what he wants is a means to use the program to determine where the problem is. Technically any program that has "alarms" is doing just that, monitoring a specific area and reporting the condition.

NOTE: you do not need to use an output or an HMI for alarms, just the memory to be a to create them. When you have a problem you can always view your alarm page.

I was just wondering if the press stops in any particular portion of its cycle/stroke? We have a couple machines that have exibited such characteristics. One I set up a couple traps in the program to latch a bit when suspected rungs with suspected inputs went true. That machine also stopped at a certain part of its stroke, so automatically resetting those latched bits at top of stroke or other parts of the cycle allowed for normal use of the press, just needed to stop the operator from touching anything before I could get back out to hook up to the plc and check those mouse traps.

A couple times I found intmitttant or questionable wiring connections. Once it turned out to be a cam roller limit switch that had past the end of its life. This particular press blanks/punches parts out of or holes into strip steel all day and has quite a concussion at the bottom of its stroke and loosens or breaks something regularly. (Every couple moonths or so.) The contacts in a cam roller switch, which is supposed to pick up the the cycle at the bottom of the stroke were weak enough that they would bounce on the blow at the bottom of certain strokes of the press.

Another time it was quitting at the top of the stroke. Come to find out, dust or other debris had built up under or inside the top stop push button causing those contact to be held very close to the point of closing. The blow at the bottom of the stroke caused the pedistal to bounce just enough to close those ocntact at the bottom of the stroke causing the press to stop at the top.
I have never tried the historgram but have often looked at it and wondered. Just got used to using latching bits for "mouse traps" to narrow down the cause.