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?
RunTon
---] [------------[TON]--
RunTon
---] [-------+-------[TON]----+----
| |
| TonInput |
+-------( )------+
| |
+-------[ADD ]---+
[Runs]
[1.0 ]
[Runs]
TonInput
------]/[------------[MOV ]--------
[0.0 ]
[Runs]
Let's say the existing program is summat like this:
Where that RunTon may represent more than a single XIC/NO instruction.Code:RunTon ---] [------------[TON]--
Change it to this:
[Runs] is a FLOAT/REAL; [TonInput] is a BOOLEAN/BIT.Code:RunTon ---] [-------+-------[TON]----+---- | | | TonInput | +-------( )------+ | | +-------[ADD ]---+ [Runs] [1.0 ] [Runs] TonInput ------]/[------------[MOV ]-------- [0.0 ] [Runs]
I expect OP will see [Runs] drop to zero whenever the TON resets "itself."
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!
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!
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.
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.