Timer not starting

Rather new to structured text.
I'm trying to edit a machine so that it will reinitialize with some push buttons held in for 10 seconds.

Pushing the buttons will make Timerenable true but my timer never starts timing.

What am I doing wrong?

Initial_timer is a FBD_Timer, Base local tag.
Initial_timer.enable=1 initial_timer.enablein=1
Initial_timer.enableout=1 initial_timer.EN=1

Added rung 24 through 28 and Added OR conditions to rung 31.

Can someone please enlighten me?

Is the subroutine being called?

It's in Main of the MainProgram, so I thought it would execute.
Or should the TONR be moved to Main of the back program?

It's in highlighted blue.

I don't have any way to test, but I would think it would make sense to assign the values of .TimerEnable and .PRE before the call to TONR(Initial_Timer) cf. here. That said, it should not matter as those assignments should effect the start of timing on the next scan.

The fact that it does not start timing suggests the code is not being called. I would write initialize .PRE with a value other than 10000, e.g. 9999, in the tag menu list; then if it changes to 10000 you have some confidence that these lines of code have been called.

Also, why do the Initial_Timer.PRE, Initial_Timer.TimerEnable and Intial_Timer.Reset tags show up twice in the tag menu list? They are shown once, indented, as members of the timer structure, and then again as tags, unindented, on their own.

Sidebar 1 for an unrelated issue: the code should not need to test [SB932_10_SbloccoLas AND SB932_9] in that IF expression:

1. First of all, it could test .TimerEnable instead
2. But second of all, I don't think it should test anything other than .DN after the OR, because
   1. It might be possible for the timer to complete (so .DN would have a value of 1) since the previous scan (when .DN had a value of 0 and .TimerEnable was 1), even if .TimerEnable now has a value of 0 on this scan, in which case the IF expression would evaluate to false, and then the .Reset will clear the value of .DN back to 0 on the next scan.

Sidebar 2 for an unrelated issue: I would also move the assignment of .Reset from .DN to after the IF-THEN-END_IF statement; I don't know how TONR is implemented internally, so it is possible, if unlikely, that assigning a value of 1 to .Reset will actually execute the reset at that assignment statement (currently 28), which would clear the value of .DN to 0 before the IF-THEN-END_IF.

I would probably do summat like this:Although it might make sense to move the reset to outside and after the IF-THEN-END_IF clause.

_

Thank you Brian.
I appreciate you passing on your knowledge.

I first had the TONR call after the enable and pre but that didn't work either.

Great idea to see if I can't overwrite the Initial .Pre value to see if the code is calling for the 10000 in the program.

I don't know why do the Initial_Timer.PRE, Initial_Timer.TimerEnable and Intial_Timer.Reset tags show up twice. I was alarmed to see the duplicates until I saw another timer (I didn't write) listed the same.
Wouldn't I get a warning it there was a duplicate address?

Another thing is if I change the value of one, the duplicate value also changes.

As to sidebar 1: I added SB932_10_SbloccoLas AND SB932_9 to the IF (line 31) condition to prevent it coming true in case the .DN bit falsely sets. Ironically the opposite thought.

I like your arrangement of the .DN bit and (NOT SB63_3.01 AND Initial_timer.DN) in ( ).

I'm still not clear why my timer doesn't work.

I like your take on this. Interesting that you have the TONR (initial _timer) in two places.

I guess an old dog (me) can learn some new tricks.

The line that bothered me in your initial code was:

Since this was immediately after the TONR, the TONR would set the .DN bit but the reset would immediately clear it, and so any use of the .DN bit elsewhere in your code (like Line 31) would never see a live .DN bit.

Personally, I would have also put the Initial_Timer.Enable line before the TONR line, to mirror more closely the ladder:

  SB932_10_SbloccoLas       SB932_9        

----------| |------------------| |------------[TON ]

i.e., the enable conditions come first, then the TON. The way you did it, the TON wouldn't start counting for one whole scan after the conditions are met.

A one scan delay may not be a deal-breaker: people have been living with one scan gaps in TONs every time they condition the TON with -|/|- TON.DN to make a self-resetting timer.

But I've also seen programs where every millisecond counts, and that kind of code doesn't fly. YMMV

Aardwiz,
Thank you for that.
I agree with your points. I'll amended the order.

Aside from my slopy code, TONR should have still started accumulating.
The initial_timer.acc never budged from zero.

My Main routine is a periodic task and my TONR is called after returning from jsr(S00100_input) subroutine.
If it's not being called, I don't know why.

Does the rest of the logic work? Does it actually jump into the S00100_input routine?



Your periodic routine where this is called from, what's the frequency it is called at?

Yes, the reset works.
On fist scan it jumps to the initialize subroutine and resets machine. My aim is to manually do so without cycling power.

I expect it would jump into the Input subroutine every scan.

I don't know the scan frequency offhand but this is the Main task that should be actively scanning.

I'll play with it more tomorrow and let you know how it goes

PiperJohn said:

Aside from my slopy code, TONR should have still started accumulating.
The initial_timer.acc never budged from zero.

Click to expand...

Are you sure that there's not another use of .Timer_Enable or .Reset elsewhere in the code?

As Ron Beaufort has repeatedly pointed out, the data table is updated by the PC software only periodically, and it is entirely possible to see that .Timer_Enable is set in Studio while at the instant the PLC is scanning the TONR instruction that bit is not set.

No,There isn't another initial _timer. Timer_enable or .reset.

Sorry, I was thinking the enable bit would remain true regardless provided the DN bit isn't set.
In other words, placement the TONR calls are critical in order for timer it to update properly.

It's working perfectly now.

Thank you everyone for the help.
Brian, your suggestions and link were especially helpful.

Regards, John