Thanks

Happens to me today in TIA 15.1

 The TIA V16 Update 1 has the same IEC timer issue.

Kryten Head One

I have had it upgrading projects from older TIA to P16 only way I could find around it was to go through the whole program finding every instance an IEC TON had been used replace it with a new TON with a different name and then delete the old IEC ones from each header and Compile. A bit hit and miss surely there should still be a compatibility for an IEC TON to be in TIA Portal in the first place?

Hit the same problem this week. The same between V14 and V16.  Took me half a day before I googled the issue I found this thread.

Somebody mentioned it is supposedly documented. Who on earth is going the read the documentation on how TON works!!! 

I regularly use the construct where I put the timer with its IN and PT parameter at the top of SCL code and evaluate the timer.Q further down the code in that block.

That may have work in inadvertently because of the context where timer.Q is accessed. Apparently it does not work in many cases. Explains some shady behaviour in the past. 

If it is a know issue, I feel the compiler should at least have warned about it..

Just adding Q=>tempBoolean to the call of the timer instance started things going, which I think is awful!!!

(not using any reference to IEC timers, just referring to the plain vanilla TON)

HansAST

Somebody mentioned it is supposedly documented. Who on earth is going the read the documentation on how TON works!!! 

Some of those who lost a half of day too.

HansAST

Hit the same problem this week. The same between V14 and V16.  Took me half a day before I googled the issue I found this thread.

Somebody mentioned it is supposedly documented. Who on earth is going the read the documentation on how TON works!!! 

I regularly use the construct where I put the timer with its IN and PT parameter at the top of SCL code and evaluate the timer.Q further down the code in that block.

That may have work in inadvertently because of the context where timer.Q is accessed. Apparently it does not work in many cases. Explains some shady behaviour in the past. 

If it is a know issue, I feel the compiler should at least have warned about it..

Just adding Q=>tempBoolean to the call of the timer instance started things going, which I think is awful!!!

(not using any reference to IEC timers, just referring to the plain vanilla TON)

V16 Update 4, still there.

Totally agreed. One of the most basic functions and Siemens still manages to mess it up, and make it more complicated than it should be. Very disappointing..

I understand that there's extra functioality, that let's you update the timer each time .Q is accessed. Very well, but that's not intuitive at all !! Make a separate timer with this functionality, but give the basic timer to the regular users. 

I've used many other brand PLCs, never seen anything like that.

I might be late to answer this, but i just found out by why by troubleshooting. If the timer is not used anywhere else e.g timer.Q or timer.ET, then the sytem does not see the need to turn it on. Try adding an output coil to the timer, or using timer.Q as an input or timer.ET in comparators or something. 

In short, the timer must have some use otherwise, it doesn't seem to work.

livebray0

I might be late to answer this, but i just found out by why by troubleshooting. If the timer is not used anywhere else e.g timer.Q or timer.ET, then the sytem does not see the need to turn it on. Try adding an output coil to the timer, or using timer.Q as an input or timer.ET in comparators or something. 

In short, the timer must have some use otherwise, it doesn't seem to work.

It's been already pointed out in this discussion. So no worries.