L32E placing negative value in timer ACC

[Andrew_W]

Afternoon Guru's

I have a unique problem I haven't encountered before and need some advice. I've been called out to a remote plant that I've never worked on before due to a train not running, upon my arrival I found the processor a L32E version 16.20 faulted. When I connect to the processor I find a type 4 code 34 fault on one of the timers. During the exicution of the program the .ACC value on the timer randomly jumps between 0 and -2147483640. After searching the program the only place that the timer, and any associated variables are referenced is in the one line of code, and as far as I can tell there is no connection to either an HMI, or any other device. What would cause this error, and what can I do to elminate it and get this plant running?

Thank's for any insight you may have

Andrew

 

[Bullzi]

I cant think of any reason why that would happen. I am sure Ken or George will have an idea.

One thought I had on how to get this going again could you just create a new tag and a new timer for the one that is messing up? That is if the code doesn't use some element of the timer a million times. Might get you moving faster.

 

[widelto]

Are they computing some variables to get .pre value as a result ??

 

[Ken Roach]

That value is unlikely to be random;

-2147483640 in decimal =
80000008 in hexadecimal =
1000000000001000 in binary

Any chance they're moving a value into the .PRE of that timer but mis-using a COP instruction ?

Is this a standalone TIMER type tag, or part of a TIMER[x] array ?

I agree that if it's a mis-behaving HMI driver that it will be very hard to find.

Creating an all-new tag for that timer will let you see if the old tag keeps changing, while moving the timer function to a new tag that should be unaffected.

 

[Basti504]

Is the timer tag part of a UDT (or inside an Add On Instruction)?


If you inhibit all Programs, does the value still change? Knowing this could exclude the PLC logic being the cause.

 

[mellis]

Since the program is faulting, stopping the PLC for a bit should be ok for troubleshooting. Put the controller in program mode, if the value is still jumping around, an external entity (or more than one) is probably writing to the tag. If it goes to the negative number and stays, try entering a different value by hand. If it switches back to the same negative number, probably something writing to the tag. It could be an HMI or another PLC.

If nothing happens in program mode, then put it back in run mode. Some code somewhere is writing to the timer .acc tag.

A Sherlock Holmes quote comes to mind...
How often have I said to you that when you have eliminated the impossible, whatever remains, however improbable, must be the truth?