S7-1200 RUNTIME instruction problem with possible workaround

Hello.

The RUNTIME instruction on the S7-1200 is (still) flawed. My test system is a CPU1214C FW4.2 programmed as FW4.1 with Step7 V13 SP1 Update 9.

An earlier discussion lead to the discovery (thanks Alex Mol). Further investigation was done to compensate for this. I need it for an active project. The findings and SCL code are now shared for discussion.

With each call of RUNTIME:
- The elapsed time is calculated from a timestamp given as input on the IN-OUT parameter called MEM.
- The timestamp is modified to a new value.

The problems are:
- The timestamp can only be values between 0.0 and ca. 85.9. (For my test system.)
- A negative "elapsed time" result is given when the timestamp value "folds over" to near 0.0. This is the overflow.
- Additional code is required to handle the overflow. (^{Bad: CPU cycle time sacrificed})

The attached code demonstrates how this case can be handled. It assumes the overflow is at a known fixed number. This may differ between firmware versions. I have yet no way of making sure what that is for each PLC. The number is assumed from experimental measurements. The constant is not based on documented fact.

The attached code is a STOPWATCH. It works very much in the same way as the TONR time accumulator works. The code was not tested on a very long term, but works well over several minutes of testing.

The following code was used to test the functionality. It is also included in the attached file (instT1 not included).

"instT1".TONR(IN := "DX".trigger,
              R := "DX".zero,
              PT := T#1D);

#tempDINT :=
    TIME_TO_DINT("instT1".ET);

"DX".elapsedTime[0] :=
    DINT_TO_LREAL(#tempDINT) / LREAL#1000.0;

"StopWatch"(run := "DX".trigger,
            zero := "DX".zero,
            memory := "DX".timeStamp,
            time := "DX".elapsedTime[1]);

This code was required in our project as we need to start a time measurement in a hardware interrupt. The timestamp needs to be read within library built blocks to trigger a timed interrupt when close to the exit event.

Hopefully others will find it helpful. Please share the code again if you make changes.

Bye.
 - Dan

Alex Mol

cut>>>>
With your FC as a reference, I changed as much things as possible on the FB and CPU side:

- InOut variables to Static ones
- Switching OVERFLOW values, 85.9 and 85.8997266578954
- Switching between several minimum CPU cycle times: 10, 25, 50 and 75ms and no minimum cycle time
- Data type conversion, especially LREAL_TO_REAL

<<<<cut
 

Hello Alex,

Thank you for sharing your test results. It sounded like a positive review. I am glad the code is helpful to you.

You mention something of a "0.05" difference. Interesting comment for which I would like to know a little more about.

1. Would that be 0.05seconds?
2. + or -
3. Static or dynamic: Remaining constant / Increasing or decreasing / fluctuating?
4. Not too clear - against what was it measured? (Date-Time?)

It is not possible to start the processes at exactly the same time. Even some processing variation might take place between the call of the two processes.

From my example code you can see that I used an IEC_TIMER as test base. That seems to be giving good results, though the IEC_TIMER is in whole [ms] increments.

I would think it is worth capturing the bias between the two measuring systems and then compare this to following differences after a longer period of time.

If the difference grows (+ / -), the OVERFLOW value might need tweaking. If the difference is more-or-less static, there is no problem.

This test is not important to me - my timings will not exceed 2H. Not sure if it is of value to you.

Regards.
 - Dan

// Monitoring maximum value of the memory

IF (#memory >= "DB1000_PLC Info".Memory_Highest)
THEN
"DB1000_PLC Info".Memory_Highest := #memory;
ELSE
"DB1000_PLC Info".Memory_Overflow := "DB1000_PLC Info".Memory_Highest;
"DB1000_PLC Info".Memory_Highest := LREAL#0.0;
END_IF;

2 x "internal clock" x "UDINT number"

Throwing numbers around, I think the internal clock is 0.1GHz.

OVERFLOW = 2 x (1E-8) x (4,294,967,295) = 85.8993459sec

 This is in the range of your experimental calculations - right?

1. The timing crystal may vary in frequency. Between one clock and the next but also between devices. I am not sure if there is a clock frequency feedback that the RUNTIME uses. That would make the use of UDINT a little questionable - why not reset UDINT on each call?
   
   
2. Working with floating point numbers introduces calculation errors. But I am not sure where the risks become apparent. Your experiment should not show this flaw yet.
   
   
3. Do not trust the real-time-clock of the PLC as an absolute measurement.

Hour    StopWatch time          IEC Time

               
1       3599.99807855981        T#59M_59S_998MS
2       7199.99706495861        T#1H_59M_59S_997MS
3       10799.9980687626        T#2H_59M_59S_998MS
4       14399.9970656096        T#3H_59M_59S_997MS
5       18000.4170390216        T#5H_417MS
6       21600.998066123         T#6H_998MS
7       25200.9970717243        T#7H_997MS
8       28800.9970600833        T#8H_997MS

So yes, my 85,8993450750698 by slope calculated OVERFLOW was pretty close to the real 85.8993459 value. Maybe because I did’n used the right values before, it looked like the OVERFLOW reacted dynamically. Now with the right value I can say it looks very static.

Factors to consider -

1. That’s a very good one. I’m still hoping we’ll get some answers from Siemens if they are reading this.
   
   
2. Me neither. Strange because we are working with a lot of decimal calculations. But realy I don't care at this moment. Maybe for the next rainy day.
   
   
3. That’s what I’ve leaned now. Very weird you can’t trust a CPU’s internal clock.
   

Today the sun is shining...

Sincere regards,
Alex

Hello Alex.

Now THAT is what I call teamwork! So this is how open-source projects look like.

Thank you for pushing through with the test. Nicely done. Good results too.

The ca. 3ms gap can probably be explained if one looked at the structure of the test code. it is too strange that it is in the ballpark of the cycle time.

Attached is the code segment that contains the improved #OVERFLOW value. Some extra (boring?) notes have been added into the code that explains what was done.

So - - - - - - what is next?

Hello Dan,

Your thanks has been reciprocated. It was a pleasure working together. 

What's next... fixing TIA bugs?

Regards,

Alex

While your approach is correct and the function is working in 1200,  I am not feeling very comfortable with the fixed value of overflow. Nobody assures that this value will be the same in next firmware versions or in different PLC types (eg. S7-1500 has different overflow value).

I am thinking a different workaround about this problem. We can detect when the overflow happens (the tempElapsed<0), instead of trying to calculate the exact remainder of time, let the function to return the previous values of elapsed time, skipping the calculation. The error would be very small, actually the difference between the previous cycle  and the current, possibly a couple milliseconds or smaller every time when the overflow occurs. 

Hello.

Thank you for voicing your concern. Your approach is a good one.  As the code is open source, you are welcome to modify it. You may find that the error made per wrong overflow value is on average as good as looking at the previous scan time.

Combining your suggestion with what has been done - compare and choose - is also an idea.

The application for which the code was designed for needed the approach. The scan time  differed much from one scan to the next at triggering of some events. I am happy with the solution for the application it was designed for.

Regards.

arkalis

While your approach is correct and the function is working in 1200,  I am not feeling very comfortable with the fixed value of overflow. Nobody assures that this value will be the same in next firmware versions or in different PLC types (eg. S7-1500 has different overflow value).

I am thinking a different workaround about this problem. We can detect when the overflow happens (the tempElapsed<0), instead of trying to calculate the exact remainder of time, let the function to return the previous values of elapsed time, skipping the calculation. The error would be very small, actually the difference between the previous cycle  and the current, possibly a couple milliseconds or smaller every time when the overflow occurs.