Counter (CTU) spontaneously resets - Expert opinion requested

rguimond

Lifetime Supporting Member
Join Date
Jul 2009
Location
Escuminac
Posts
665
We encountered a problem last night that I can’t explain. My suspicion is that a faulty output modules in a remote rack controlled by a SLC5/05 caused the problem, but I’m looking for validation. I've contacted our local Rockwell rep, but havent received a reply yet.

We had a few valves not open. These valves are all controlled from the same output card, controlled by a sequencer. A counter that controls the sequencer seems to have reset itself after only completing part of the cycle (about 20 steps into a 100-step cycle). The sequencer started working spontaneously at one point. My question is:

Could a faulty output card cause a PLC reset that would restart the counter?


There is no logic other than detection of a "reset" bit on the 100th step of the counter that should reset the counter, and there is nothing that MOVes a value into the .ACC of the counter in question. It has worked fine for years, until last night.
 
Is this a new install or a system that has been working for a while???
My immediate suspicion would be that something in the up-count portion of the logic is causing the counter to run away at a very high rate.
 
Like I said, the system has been working fine for years. What's even stranger is that the problem self-corrected, then started again. I haven't been able to determine if the reset starts at the same place yet. I'm hoping it goes away permanently, but there has to be a root cause.
 
I forgot to mention that I already checked for the possibility of another PLC writing to the "N" data table that holds the "reset" bit. No PLCs write to this one, and this PLC doesn't read from another PLC into this data table.
 
I have never witnessed an a/b controller whose logic or data was corrupted by a hardware failure and continue to run. In every case I have seen, the controller "wipes itself" goes to fault state and there is no program in it left to run.

I have seen situations where communications problems caused data to get written to the wrong address, but this is very very rare.

It is more likely that the problem was caused by a rapidly changing address as mendonsy suggested, and that the potential for this issue has been there all along, but was never accounted for by the original program.
 
I agree. Other than hardware causing faults, I have seen what I think was a hardware issue cause a ML1100 go into PROGRAM mode spontaneously. I was never able to determine what the cause was. It happened two or three times then disappeared.
 
The logic that controls the counter is attached. My first thought was that the values in N11:0 were "zeroed" out, but they're not.

Is it possible that B3:4/9 drops out for a scan? This would explain the reset, but wouldn't it also stop the cycle?

VALVE SEQUENCER LOGIC.jpg
 
That snap shot does not tell the whole story. Can you post the program file (.RSS)
then someone can see what controls B3:4/9.
 
Not sure what the issue is but it might be worth putting in something that moves the counter value to a register as the 'reset' is fired. Then you can see whether the counter was at 100 when the reset fired (ie the counter ran away with itself) or the reset fired when the counter was at 20 (or whatever...).

Just in case it happens again.

;-)
 
I see an issue with the B3:4/9 XIO...
If the C5:0 accumulator is so critical within your application I would reverse the "logic" and use an XIC to condition the C5:0 (RES) command eliminating the possibility of some B3:4/9 OTE "logic latch" mishap.
 
I question the use of the XIO C5/CU instruction ahead of the counter. What that does, is ensure that the counter increment every scan during which the preceding logic is true.
 
can you tell us more about that CU reference? ... basically if the rung conditions are TRUE, then you've got a runaway counter here ...

I mocked up the rung as shown - and as soon as I made the "test switch" go TRUE, the counter started advancing on every other (alternate) pass ...

EDIT: I was putting the picture together when Okie posted - but the question would be "was it like this when it was working earlier?" ...

.

runaway_ctu.PNG
 
Last edited:
I'm guessing that it's always been this way - and that somehow the program intentionally makes use of a "toggling" kind of - sort of "alternating" action - which is set up by the way this counter is being triggered ...

can you post the entire program? ...
 
I think it was put there in order to avoid the overrun (or multiple counts on the same event) instead of the commonly accepted [OSR] placed after the count "decision maker"...
And one more...I have seen RED faulted SLCs due to CTUs without(or malfunctioning) RES instructions; they count up to 32767 and then fault the processor.
It is a matter of establishing if it was an overrun or a "false" RES, however, since we've pointed quite a few issues related to the "ran for years" logic, we could definitely conclude that the PLC hardware is not the culprit.
 
Last edited:

Similar Topics

Hi all, I'm newbie here to plctalk! I writing a PLC programm in ladder where I put an output bit to zero during 9s and the same output bit to one...
Replies
13
Views
6,710
Hey Everyone, After reading a lot on this forum and elsewhere I see not many are fond of the 1794-VHSC module. I can see to a degree as I was...
Replies
2
Views
30
Hello Folks, Has anyone configured a Momentum high speed counter on Unity 13.1. We need the wiring diagram for Momentum High speed counter and...
Replies
0
Views
65
Hi all, I am working with an incremental encoder (ABZ signals, 360 ppr (so 1440 counts per rev)) to replace the existing "manual" encoder wheel I...
Replies
25
Views
806
Hi y'all Just a quick question for using Rslogix 5000 I'm using a counter up bit with an analog signal (0-10V). When 10V is measured, counter...
Replies
5
Views
203
Back
Top Bottom