TIA IEC timer: unwanted behaviour

I recently discovered that when downloading an online edit [S7-1500] that requires the initialization of the modified FB's iDB, an IEC timer whose input [enable] conditions are already at logic 1 will reset its output but not re-trigger and run because it hasn't seen a 0/1 transition at the input through the download. Siemens tech tell me that this is because the DB and FB are loaded simultaneously and that there's no way around it without external logic to break the input to the timer when the download takes place.

Today I had to cycle the power to the processor and the same thing happened when it came back on: all timers with pre-existing enables didn't restart. In my application, they're all on-delay debounces for level control thresholds, so all the pumps that should have restarted didn't. This response suggests that I won't be able to create a universal TON instruction or pulse timer at the top of the program to generate a reset pulse if that timer is unconditionally enabled, as I would in A.B.

Can anyone help me out with this one? Thanks.

Would TONR / IEC solve?

Lare, yes, I think it would if I use the first scan bit to reset it.


I guess the only remaining question is: As all the timer instances are FBs in FBs, (unconditionally called from OB1), will the first scan bit operate here?

DairyBoy said:

I guess the only remaining question is: As all the timer instances are FBs in FBs, (unconditionally called from OB1), will the first scan bit operate here?

Click to expand...

The firstscan bit will be active thoughout the 1st run of OB1. So also for all FCs/FBs called from OB1.

But that would not have helped in the situation you describe.
You have a program that is already in run, and you download a program update that initializes the IDBs, and thus you get the issue you have observed. In that case firstscan will not be triggered.

TIA has plenty issues with programming in run, but the one you describe is new to me. IEC timer IDB gets reinitialized, causing the DN bit to go off, but it subsequently does not see a transition on the EN bit.
Not sure how I would counter this. Maybe a special manually activated bit to restart the timers ?

Jesper, thank you for your thoughts. I had planned to add a First scan XIO to reset the timers after a power cut.

Siemens tech have offered a possible work-around: Put one independent bit in the iDB and set its default to true. Use it as the reset for the timers via, say, a XIO. Then set it to 0. It will remain in this state until the next download. I figure if I place the Set instruction at the end of the containing FB, it will scan through all the timers in the instance FBs first. Although that assumes that the downloaded modified containing FB gets scanned from the beginning, and not at a random point within it.

DairyBoy said:

[..]Although that assumes that the downloaded modified containing FB gets scanned from the beginning, and not at a random point within it.

Click to expand...

In that case though, I suppose you dont have the problem since the timers will get started the normal way when they eventually are called ?

I will delay the Set to 0 instruction for 1s to ensure >1 scan and enable the 1s timer from the same bit via XIC. Not nice, but necessary, and the timer must be remembered for including in future applications.

Not sure if undestanded all from english rightly.


Do you mean, that if you download IDB of IEC timer to PLC, then timer is resetted, even when timers input is active.
And for timing again, timer needs to see 1-0-1 change?




couple pictures would be nice

.. or some code that demonstrates the problem as I cannot repeat this on my S7-1500 plc.

Lare, yes- exactly that. Here is the answer to my question from Siemens tech:

Many thanks for sending your application & we've looked at the issue in the office. It appears you have done everything right and this is an issue with how the blocks are downloaded.
I think the problem is that the timers need a rising edge signal to start the timing function (press F1 with a timer selected to see the timing chart) and the issue is that the FBs and iDB are both downloaded at the same time. The timers don't see a rising edge and so are not triggered.

We can't really think of a way around this apart from adding in latches or other program changes which I appreciate are not ideal. One idea might be to add a contact in series with the timers that was low for 1 scan and only operated when you change the code?

Sorry it's not better news.

It all depends on who you get with tech support - sometimes I've got a confident correct answer but other times been told something is not possible only to find through research and experimentation that it is possible.


Did they discuss the memory reserve feature?

L D[AR2,P#0.0], memory reserve, no. the application is barely scratching the surface of the memory.

Refer to the help on memory reserve:

Here's what I understand his issue to be.
Let's say he has a TON timer with a NO contact connecting the supply rail to the EN input of the instruction. When the NO closes AND stays closed the timer times out and the sets the output to true and he's happy. Then say the CPU is restarted, when it runs the NO contact is still true as it was before the CPU stopped but the output of the timer is False and to set it to true the NO contact has to go false then true because the timer requires a rising edge.

And I'm curious what does he have connected to the timer that he would want to start on CPU restart or transition from run-stop-run.

Something is wrong here..I believe that in some combination of online change with iDB reinit it might not work, but on restart it should work normally. I'd have problems with this by now if it didn't.

kalabdel said:

. Then say the CPU is restarted, when it runs the NO contact is still true as it was before the CPU stopped but the output of the timer is False and to set it to true the NO contact has to go false then true because the timer requires a rising edge.

Click to expand...

The No contact is still true but in the iDB it is false after the reset, just like the output. And when it is called it starts to time again because he got a true on the in contact..
And if the iDB is set to be Retain, then it won't start to count but the output will stay true too.