Timers not resetting (they continue after the PT time is elapsed)

Einstein, just some real life experience, what will happen in that case. The .Q in network 1 is executed before the timer.

Easy to test, create a new network after network1, and move the timer Q and coil there.

Guys, we are quite off topic! This is being discussed here and always here.

(Anyway, I'm sorry Hati, but I attach here the result of the test. Did you mean something different? Also Einstein, is this what you meant?)

So, "TOF timer not resetting, continues after PT time is elapsed (ET>PT)", I mean, how is ET>PT possible in TOF?

vcamp7

Guys, we are quite off topic! This is being discussed here and always here.

(Anyway, I'm sorry Hati, but I attach here the result of the test. Did you mean something different? Also Einstein, is this what you meant?)

So, "TOF timer not resetting, continues after PT time is elapsed (ET>PT)", I mean, how is ET>PT possible in TOF?

Hello.

The PT value on the TOF is configurable in your use case.
This might contain a clue.

It is possible to have ET > PT and best illustrated with an example:
1) IN = OFF; TOF is running aiming for PT = T#24d.
2) After running for some time PT is changed to PT = T#1s.
3) ET > PT
4) The TOF runs out when reaching the T#24d target.

If the above scenario is what is the case on your site is open for debate.. and somehow I doubt it. Other strange occurrences I have seen on older S7-1200 firmware V3.0 processors coded with Step7 pre V13 SP0. This would include where instances are re-initialized and loss of transitions on the timer input. Double use of the same timer was also a re-occurring issue.

Having more information about your situation might be helpful. I have no comment to make on the code pieces you shared up to now.

As added note.. the above example scenario can be guarded against by controlling how/when the PT value is changed or the coding:

Consider creating a formal Support Request with the Siemens' Support Team if the contributions from the forum volunteers are not fruitful.

~

qwazee

1) IN = OFF; TOF is running aiming for PT = T#24d.
2) After running for some time PT is changed to PT = T#1s.

You are right. Since my PT results from "seconds in the heating cycle" divided by "quantity of burners", when the burners are 0, PT equals 16#7FC0_0000 which means T#1D_3H_57M_43S_296MS.

Fortunately, when the burners are 0, the timer (and almost everything else in the FC) is disabled.

qwazee

Other strange occurrences I have seen on older S7-1200 firmware V3.0 processors coded with Step7 pre V13 SP0. This would include where instances are re-initialized and loss of transitions on the timer input. Double use of the same timer was also a re-occurring issue.

This issue, actually, happened after the restart of the CPU (so the client says). Anyway, I have read about those problems in other topics, but it doesn't seem the case with the code here. 

qwazee

Having more information about your situation might be helpful. I have no comment to make on the code pieces you shared up to now.

 Also, with use the "Manual_Trigger" (which was set-rest by HMI) we could clearly see several times that ET went past the PT fixed at T#20s.

Unfortunately, I cannot reproduce the issue in office so far. Would matter if in the same Profinet network there is a PLC300 and PLC1200 as I/O Device?

That is the worst part.. squashing a bug when you do not know where it is hiding. Heck,, you are not even sure what colour it is yet.

It would be best if you qualify/limit the setpoints that is in use. It does not matter if those are in use or not. It simply takes one possibility off the list.

Also keep in mind that using M-bit memory present a possible problem that the tag is not initialized by the time the timer is processed in the first scan.

In my code I make use of the RESET_TIMER instruction. Each time the code is initialized / powered-up, all the timers are forced reset.

This strategy makes a bit more sense in my coding structures as we make extensive use of instances within FBs. Rarely do we have timers taking a DB as an instance. For the downside of this design, the RESET_TIMER comes in handy. A 'firstPass' state inside the FB tells the FB when its code is processed for the first time since power-up or re-initialization. 

How you structure your code is less prone for re-initialization problems. But you have to be watchful on the order of the tag getting a value and when that tag is consumed by the timer. Consider using RESET_TIMER even if it is a secret function placed there while you search the root cause of the problem.

As for the networked devices.. 
It could have an influence if the timers are triggered by signalling that comes from the network AND the setpoint is not correctly set. Signals from the network should not be trusted until communications is established. This can be a bit after the main controller restarted. A easy way is to have a timer that is started after the PLC is restarted -- no actions are taken inside the reboot time.

Good luck.

vcamp7

Guys, we are quite off topic! This is being discussed here and always here.

(Anyway, I'm sorry Hati, but I attach here the result of the test. Did you mean something different? Also Einstein, is this what you meant?)

So, "TOF timer not resetting, continues after PT time is elapsed (ET>PT)", I mean, how is ET>PT possible in TOF?

The timer .Q is used multiple times, that is the reason why you feel it's not working. IEC timer are asyncrhronous, so the .Q output can change during cycle excecution. If you need the .Q information multiple times in your code, use the below method.

Ok, Hati. Anyway, the off-topic was about the scan cycle. In this case, I would split from here.

Thank you, qwazee, I'm looking into that ;)

De hecho, tuve un problema resiente y mi error o bueno, desconozco si fue mío o error del programa, ya que al usar los timers, dentro de un FB, este nunca se activaba el PT.

Lo que hice fue sacarlos a un FC, y funcionó sin problema al igual que el OB Principal.

Hello Josue_Aguilar499,

Please try to discuss your question in English language. This is an international community and we try to focus on one language. Posting in English will help to generate more replies to your question.

This is the translation of your post:

Josue_Aguilar499

In fact, I had a recent problem and my error or well, I don't know if it was mine or the program's error, since when using the timers, within an FB, the PT was never activated.What I did was take them out to an FC, and it worked without a problem as did the Main OB.

Kind regards, Moderator_Lan

Hi everyone,

the problem was solved in the end. 

FACT: the .PT value inside the instance DB of the timer is different from the PT tag that you monitor in the FC (!). They might have the same number, but they are different objects and have a different behaviour.

CONSIDERATION: We were looking at an ET tag that was incresing over the monitored PT tag. That means that the .PT value inside the instance DB of the timer was bigger than the PT tag (and also still bigger than ET).

(ET > PT), (.PT > ET) => (.PT > PT)

Using this insight, I changed the logic and solved the problem.

Thanks to everyone that was kindly helpful.