S7-300 to S7-1500 migration: IEC timers

I've used the following timer code in S7-300's for a long time. When migrated to an S7-1500 plc, the timer behaviour changes so that I no longer get a pulse that is on for one scan. Anyone else get caught out with this new behaviour? (I wont post the fix yet - call it a mini-puzzle if this is new to you)


https://screenrec.com/share/3vidVyjBnx

Yes, I found I had to assign an actual output to the timer Q to get it to time if the timer was the last instruction on the rung/network

Steve

wow.


How does that not work? Or how does that not violate "left-to-right, top-to-bottom?" Siemens is broken (like everyone else).



Will PM my guess at the fix. nm, slp530 probably got it right.

I wait with bated breath. That is such an afront to my thought process that I'm not sure where to even start.

Keith

When I found that issue with the IEC timer it took me the better part of a month to figure out what was going on with my code. slp530 has the correct solution, you need to assign a bit at the Q of the timer. If you reference the Q at any point in your code it will check the current value of the timer again.

They also changed some stuff with safety that they didn't document too well like F-addressing type 1 and 2 and the handling of the Q_BAD status with RIOforFA-Safety.

It's because the Timer in the S7-1200/1500 work completely different to other function blocks (whoever thought this is an useful feature). Q and ET can be see as getter methods from C# for example. The time values are always refreshed when you access the Q or ET value. If you do this more than once in a cycle, then you may get different Q states / ET time values. This behaviour was the same with the S5-Timers in the S7-300/400, when you read the state of T1 for example more than once in an OB1 cycle, you may get different results.

It's described here in a small note at the end:
https://support.industry.siemens.com/cs/de/en/view/109476858

Another difference between the controllers is in the updating of the timer tags.

• With the S7-300/S7-400 the timer tags "Q" and "ET" are updated when the timer is called.
• With the S7-1200/S7-1500 the timer is updated when the timer is called or when the timer tags "Q" and "ET" are accessed.

Click to expand...

Originally posted by baref00t25:

If you reference the Q at any point in your code it will check the current value of the timer again.

Click to expand...

But this would also require that the timer function performs the equivalent of off-state logic immediately after it expires. I assume the IEC timer function works by comparing the current clock to a basis time saved when the timer was initiated by the leading edge of an active EN input. The only way I can think that a second access would be an issue is if the basis time were modified when the timer function call determined that the basis to current delta was greater than the preset. In any case I can think of, the basis to current delta will have to be larger for any code located after the timer function call. That means any later access should still satisfy the "done" case.

What happens in the case where the input condition to the timer stays true? Does the second access also read "incorrectly" in that case?

Keith

Here's the test that we did to figure out what the IEC timer was doing:

Timer TON call was placed in a 100ms cyclic task.
We examined the ET (elapsed time) of the timer in a 10ms task.
We were able to see that the elapsed time was incrementing by 10ms and not 100ms; meaning that just accessing the memory caused the timer to increment its time.

That is an interesting thing about IEC timers, I have no idea how the code is compiled in many PLC's, however, I do know how they are compiled in Mitsubishi. They are not actually timers (the same as in normal ladder as referenced by "Txx"), I think it is due to the transportable code idea between platforms. IEC timers in Mitsubishi load call to a sub routine (function) on the trigger signal and increment an internal word, compare that word with the timer value say T#3s (actually 3000ms) and increments it by 10 or 100ms (depending on the time base for that PLC). so not using a tag on the "Q" output of the timer does not return the bit from the function. I believe that many platforms i.e. Siemens, Mitsubishi use this to make it transportable, There are a number of functions in Mitsubishi that instead of calling the original functions as per ladder, they create the code either in-line or by jumping to a routine that emulates the function. I'm sure that many PLC manufacturer's do this rather than create a new interpreter or compiler so as to keep original hardware compatible with IEC.

Originally posted by baref00t25:

We were able to see that the elapsed time was incrementing by 10ms and not 100ms; meaning that just accessing the memory caused the timer to increment its time.

Click to expand...

That is consistent with the processor accessing the current and base time and calculating a delta every time a timer element is accessed. I would believe this to be true assuming that the IEC timer function really is performing a current-minus-base delta calculation.

However, going back to the initial case, I still can't see why the second access of the .Q element didn't return true. I can actually think of reasons why there could be a double increment of the done counter because of this access but not why there would be no increment. The timer function call should not have changed the .EN status as a result of the timer expiring nor should it have modified the base time. It has to be doing one of those things, though.

Keith

The IEC timer becomes a function block so needs to return a value or bit so needs to be parameterised with all the IN/OUT variables you need, the timer instance is not an actual timer so is not referenced as an actual timer. well at least not on Mitsubishi. I believe that to make IEC timers compatible with existing code this is the way some manufacturers have gone, I suspect that new platforms will remedy this so will not be compatible in any form with the older hardware, I have noticed that in GX Works that the latest PLC's use a different approach even IDE for the later processors.

I believe the reason is because the first access of the timer with .Q sees the timer has expired and Q goes high, so the second access of the timer with the TON sees the IN is low and resets the timer. The third access of the timer (second access of .Q) then sees the timer as reset and Q isn't high.

That's it barefoot. Here's my step by step evaluation. The timer Q is actually on for the short duration in Scan 5 between the N/C contact and the timer block being called. If the timer elapses during this short time frame, then a pulse will be generated.

So that would infer that any program access to any element of the timer structure triggers a full-blown access to the whole function, in effect running all timer evaluations as part of the access. That would definitely explain things.

Keith

By introducing a delay between the N/C contact and the timer call, you increase the chances of a pulse being caught.




https://screenrec.com/share/aGvObHTo6A