Negative Value loaded into timer.

[wmor0082]

Had a negative value loaded into a timer in controls logix. Can you tell me why. We are using MES and Camstar for data colection. We are using udc to caplture data.

 

[shooter]

neegative only means it is more than half of maximum value .
128 is negative 127.

 

[bernie_carlton]

You will have to look for anything which can write to that timer Preset ...

Other code in the program

HMI (Display)

Networked device (another PLC etc)

From the way you wrote it it doesn't sound like your data collection writes anything to the PLC, be aware if it does though.

 

[TheWaterboy]

If the timer is on a ladder that is not being scanned for long periods of time, random values get put there. potentially negative ones too.

 

[dcooper33]

If the timer is on a ladder that is not being scanned for long periods of time, random values get put there. potentially negative ones too.

Perhaps your controller regrets all those wasted milliseconds of its youth?

 

[rdrast]

If the timer is on a ladder that is not being scanned for long periods of time, random values get put there. potentially negative ones too.

I have never seen this happen. Not once.

 

[Ron Beaufort]

Had a negative value loaded into a timer in controls logix. Can you tell me why.

well, this is just a GUESS of course – but the figure below shows one way that pops up in every hands-on class that I teach ...

and notice that you don't have to "Edit – Accept – Test – Assemble" your timer's rung for this unintended change to take effect ... just a sloppy Drag-and-Drop with the mouse is all it takes to ruin your day ... the mouse cursor is several inches away from the Timer's Preset value - but in RSLogix5000 that's "close enough" to count ...

and in case you're wondering, there's NO WARNING that you're about to alter your program – and no warning AFTER the fact either ...

going further - this is one reason why I refuse to work with this software without having a real-honest-to-goodness mouse ... those little "touchpad" things make it much too easy to cause these types of errors ...

going even further - in the example shown, the negative Preset value will NOT cause the processor to fault and shut down - UNTIL the input Local:1:I.Data.1 gets turned on - and the Timer's rung gets executed with True logic ... so in some cases, it might be quite awhile before anyone even realizes that Little Johnnie has made a mess of things ...

one step further - over the years I've had dozens of students tell me: "We always keep our processors' keys in the RUN position. That way we can't make accidental changes to the programs while we're troubleshooting." ... well, guess what? ...

.

 

[TheWaterboy]

I have never seen this happen. Not once.

Then you haven't tried it.

The timers use the system clock, grab a value at one scan, then the next scan grab another value and compare them. If you take the timer off scan for a long time, the next time it is scanned the system clock is so far ahead that the comparison results in some wild numbers in the ACC

 

[TheWaterboy]

Perhaps your controller regrets all those wasted milliseconds of its youth?

Don't we all.

 

[bernie_carlton]

The original post did not specify the accumulator or the preset. The accumulator having a negative value would be interesting. The preset having a negative value should cause a fault.

 

[Operaghost]

A negative in either the preset or accumulator will cause the fault if the timer is true.

If you cross reference the timer you should be able to see if any logic is writing to either. Look for destructives referencing either the PRE or ACC.

But, if an HMI is writing to it that is certainly harder to track down.

OG

 

[Operaghost]

Then you haven't tried it.

The timers use the system clock, grab a value at one scan, then the next scan grab another value and compare them. If you take the timer off scan for a long time, the next time it is scanned the system clock is so far ahead that the comparison results in some wild numbers in the ACC

Hmm, I haven't seen this one either, and yes I have tried. You are certainly right on in that when a timer is taken out of the scan (JMP or stop calling the routine) when it comes back into scan it will leap ahead adding the total elapsed time, not simply resume from where it left off as the older PLC/SLC products did.

But I have never seen it plug a negative number into the ACC. I just tried a little test here to see if I could cause this scenario by freezing a timer and then resuming. I even tried changing the clock value ahead. But even leaping ahead 16 years did not cause any issues.

In fact, in my testing it appears that if the timer ACC value would have exceeded the preset, it simply starts back at zero.

But perhaps I am not creating the logic the same way you did and that is leading to the difference. Maybe even a difference in the controller revision (I tested using v21).

If you can show the conditions that caused you to see this problem I would love to see it. I don't doubt you, I just have never seen this in the 14-15 years I've used this platform.

OG

 

[rootboy]

Perhaps your controller regrets all those wasted milliseconds of its youth?

LOL!

Makes you wonder why Rockwell chose to use signed integers instead of unsigned for timers and counters?

And what's up with the LINT?

It has an odd range to it. (0...32535129599999999)

 

[rootboy]

well, this is just a GUESS of course – but the figure below shows one way that pops up in every hands-on class that I teach ...

and notice that you don't have to "Edit – Accept – Test – Assemble" your timer's rung for this unintended change to take effect ... just a sloppy Drag-and-Drop with the mouse is all it takes to ruin your day ... the mouse cursor is several inches away from the Timer's Preset value - but in RSLogix5000 that's "close enough" to count ...

and in case you're wondering, there's NO WARNING that you're about to alter your program – and no warning AFTER the fact either ...

going further - this is one reason why I refuse to work with this software without having a real-honest-to-goodness mouse ... those little "touchpad" things make it much too easy to cause these types of errors ...

going even further - in the example shown, the negative Preset value will NOT cause the processor to fault and shut down - UNTIL the input Local:1:I.Data.1 gets turned on - and the Timer's rung gets executed with True logic ... so in some cases, it might be quite awhile before anyone even realizes that Little Johnnie has made a mess of things ...

one step further - over the years I've had dozens of students tell me: "We always keep our processors' keys in the RUN position. That way we can't make accidental changes to the programs while we're troubleshooting." ... well, guess what? ...

.

Yup, yup, yup. The same thing applies to incorrectly grabbing a tag when you really wanted the contact. When that happens to me, I abort the entire rung and redo that edit.

In all fairness, the old LogicMaster for the GE Series Six would do the same thing. While searching for a register, if you hit enter instead of search, you've just modified things a bit.

As for leaving things in the run position, I'm not a fan. But I have bowed to the inevitable...

 

[TheWaterboy]

OperaGhost - it was just as you describe - CompactLogix v17 - I had a timer on a ladder that would not be scanned for days, When it did get scanned it had impossible numbers in there. For the sake of this thread I assumed the sign bit was in play so eventually luck would draw a negative number. Perhaps not, or perhaps not anymore in v21. I don't clearly recall what numbers they were in my case because they were so far out of whack I knew something was wrong, but I got all timers (and ONS) out of the unscanned rungs and never looked back.