TON Timer keeps resetting itself

All,
I've got a TON that keeps resetting itself even though the rung remains true, I've slammed my head over this for some time now and cant figure out whats going on....any thoughts?

What PLC are you using? Check for an RES (or similar reset) instruction somewhere in the program. Perhaps one of the input arguments is going from true to false and back to true faster than the IDE is able to update graphically.

If you are able to share your program, perhaps someone here will be able to look through it and help you find the problem. (Zip it up first, forum rules).

Does it really remain true OR does it only appear so? The PLC logic executes faster than the PC screen updates so it may appear always true but pulse for a instant and cycle the timer off and on.

Also any RESETs that affect it at any time?

blythgoe said:

All,
I've got a TON that keeps resetting itself even though the rung remains true, I've slammed my head over this for some time now and cant figure out whats going on....any thoughts?

Click to expand...

Can you make a rung for each conditional element in the rung to test for a bit dropping out during the Timer enable period?
Or, better yet, does this cpu have a bit histogram?

Duplicate Address

Depending on the PLC - if you have an older architecture with global timers is there a duplicate timer address somewhere else in the program?

All of the above are common, one I came across some years ago was a delay timer for a build back system. I was working on another line when one of the plant electricians asked if I could look at the air conveyors as the build back on one of the legs was not working, after looking at the code, checking there was no duplicated timer, the engineers had already replaced the the photosensor & even the cable, I noticed that the inputs on the card seemed a little dim, a quick measurement showed only 20v not 24, the PSU was not adjustable but in any case 20v should give a reliable true signal, I asked if they had a scope & on checking the input it was found it was switching at 100hz, it turned out to be the capacitors had deteriorated so it was getting 100hz clipped unsmoothed dc.
Replacement of the PSU cured the problem, the sensor was working but switching at 100hz (full wave rectification), this was resetting the timer but monitoring the rung was not showing the input going false.

Let's say the existing program is summat like this:
Where that RunTon may represent more than a single XIC/NO instruction.

Change it to this:
[Runs] is a FLOAT/REAL; [TonInput] is a BOOLEAN/BIT.

I expect OP will see [Runs] drop to zero whenever the TON resets "itself."

put a counter CTU in parallel with the TON..

if the CTU increments the TON is being toggled faster than visuals..

drbitboy said:

Let's say the existing program is summat like this:

Code:

 RunTon
---] [------------[TON]--

Where that RunTon may represent more than a single XIC/NO instruction.

Change it to this:

Code:

 RunTon
---] [-------+-------[TON]----+----
             |                |
             |     TonInput   |
             +-------( )------+
             |                |
             +-------[ADD ]---+
                     [Runs]
                     [1.0 ]
                     [Runs]


   TonInput
------]/[------------[MOV ]--------
                     [0.0 ]
                     [Runs]

[Runs] is a FLOAT/REAL; [TonInput] is a BOOLEAN/BIT.

I expect OP will see [Runs] drop to zero whenever the TON resets "itself."

Click to expand...

It may actuate fast enough he won't see the change. Remove the ADD for the 1 and set it manually to 1. let the loss of the TonInput set to zero.

Or as the next post suggested.. CTU it. that'll trap it more effectively.

Well, I'm not sure what happened. I added a counter and it did count the correct amount of times the rung was true. For some reason it just started working. Thanks!

Nova5 said:

It may actuate fast enough he won't see the change. Remove the ADD for the 1 and set it manually to 1. let the loss of the TonInput set to zero.

Or as the next post suggested.. CTU it. that'll trap it more effectively.

Click to expand...

OP is seeing a steady true input to the TON, else they would not "observe" the TON of resetting "itself" as unusual. So they will see TonInput incrementing but resetting to zero before TON timeout*.


I went with ADD 1 and a REAL to avoid overflow and faults, which could happen with a CTU.


* Unless RunTon is on a short cycle, but even then sample aliasing will (briefly) show a non-zero TonInput. The CTU will work, of course, but it might be worth adding a reset on the CTU control object if the counter goes above 30k to avoid overflow.

blythgoe said:

Well, I'm not sure what happened. I added a counter and it did count the correct amount of times the rung was true. For some reason it just started working. Thanks!

Click to expand...

Huh?


screen shot of working and non-working, please.


I'm only it it for the puzzle.

blythgoe said:

Well, I'm not sure what happened. I added a counter and it did count the correct amount of times the rung was true. For some reason it just started working. Thanks!

Click to expand...

Things that go away on their own mystically are not solved. They will return.

drbitboy said:

OP is seeing a steady true input to the TON, else they would not "observe" the TON of resetting "itself" as unusual. So they will see TonInput incrementing but resetting to zero before TON timeout*.


I went with ADD 1 and a REAL to avoid overflow and faults, which could happen with a CTU.


* Unless RunTon is on a short cycle, but even then sample aliasing will (briefly) show a non-zero TonInput. The CTU will work, of course, but it might be worth adding a reset on the CTU control object if the counter goes above 30k to avoid overflow.

Click to expand...

You can protect from overflow as simply as a RES when reaching close to overflow. But the reality is he should see it long before then with any method. Depending on Timer length. what I saw with yours was Sure it adds 1 but is set to zero on loss of TonInput, but goes back to one on the next true input to the timer.

But since we don't know his TON preset it's hard to judge. a simple clear or counter works to advanced it. You can also use a latch but to see it drop. manually set the bit high, then use a OTU to set it Low. Its a 1 time test but if your watching it, and see it go low but don't "see" the input for the timer going low, its just actuating to fast for the logic software on the PC to show.

Nova5 said:

You can protect from overflow as simply as a RES when reaching close to overflow. But the reality is he should see it long before then with any method. Depending on Timer length. what I saw with yours was Sure it adds 1 but is set to zero on loss of TonInput, but goes back to one on the next true input to the timer.

But since we don't know his TON preset it's hard to judge. a simple clear or counter works to advanced it. You can also use a latch but to see it drop. manually set the bit high, then use a OTU to set it Low. Its a 1 time test but if your watching it, and see it go low but don't "see" the input for the timer going low, its just actuating to fast for the logic software on the PC to show.

Click to expand...

Meh, we're picking the fly-.... out of the pepper; either way is unlikely to not open OP's eyes as to why TON resets (I was assuming 16-bit .ACC; with 32-bit .ACC it's almost in "who cares?" territory, of course).



[GRT Runs 1.6e7] replacing [XIO TonInput] is the same as the RESet of the CTU when object.Accum approaches overflow.



Still the actual result is a bit of a poser: the problem "went away" when a rung was added? I don't think so.