S7 1200 OB1_PREV_CYCLE

Hello Dan,

Yes, I'm using it for a while.

This topic was not about RUNTIME, but about time measurement between two cycles. I was wondering how to do it and if it was reliable and accurate, so I shared my code.

As I'm always using my own created timers (pulse, TOF and TON), I need the CPU cycle time. For me this topic was interesting because it was giving an other solution. What's left for me now, and that's the interesting part, are there (big) differences between "method one" and method two" like your IF statement style queston. (very good topic by the way)

Regards,

Alex 

Alex Mol

Hello Dan,

Yes, I'm using it for a while.

This topic was not about RUNTIME, but about time measurement between two cycles. I was wondering how to do it and if it was reliable and accurate, so I shared my code.

As I'm always using my own created timers (pulse, TOF and TON), I need the CPU cycle time. For me this topic was interesting because it was giving an other solution. What's left for me now, and that's the interesting part, are there (big) differences between "method one" and method two" like your IF statement style queston. (very good topic by the way)

Regards,

Alex 

Hello Alex.

This topic was not about RUNTIME, but about time measurement between two cycles.

I invite you to evaluate the code piece I designed for you. It is a worthy candidate as alternate to your code. The code piece spits out the equivalent result as what you are looking for. 

There is no dependency on any outside actions as what you have now. Call the FB in OB1 and see what I prepared for you. If you don't like using my code - no problem. But do test it first.

..there (big) differences between "method one" and method two"

(Thanks for complimenting the IF statement topic.)

I think we need more topics on this kind of stuff. In the office we call it "little foxes". The kind of questions that is not overly important but it hounds you and nibbles at your curiosity.  Which type of differences did you find?

Bye.
- Dan

Hallo #dP,

your restart is ever false.

So see this little correction

#dP

 

Alex Mol

Hello Dan,

Yes, I'm using it for a while.

This topic was not about RUNTIME, but about time measurement between two cycles. I was wondering how to do it and if it was reliable and accurate, so I shared my code.

As I'm always using my own created timers (pulse, TOF and TON), I need the CPU cycle time. For me this topic was interesting because it was giving an other solution. What's left for me now, and that's the interesting part, are there (big) differences between "method one" and method two" like your IF statement style queston. (very good topic by the way)

Regards,

Alex 

Hello Alex.

This topic was not about RUNTIME, but about time measurement between two cycles.

I invite you to evaluate the code piece I designed for you. It is a worthy candidate as alternate to your code. The code piece spits out the equivalent result as what you are looking for. 

There is no dependency on any outside actions as what you have now. Call the FB in OB1 and see what I prepared for you. If you don't like using my code - no problem. But do test it first.

..there (big) differences between "method one" and method two"

(Thanks for complimenting the IF statement topic.)

I think we need more topics on this kind of stuff. In the office we call it "little foxes". The kind of questions that is not overly important but it hounds you and nibbles at your curiosity.  Which type of differences did you find?

Bye.
- Dan

Hello Dan,

No offense from my side at all. I appreciate your contribution, but like I said, my code was within the topic. Many topics about RUNTIME already exists. As I'm more into the 300/400 and 1500's, the 1200 works a little different. I've used RUNTIME only to measure a FB, not an OB. So I was curious.

Anyway, the code to measure time difference between two cycles has a deviation of -5s per hour. So after an hour the code will show us 59m 55s. Useless in my opinion.

Your code works perfectly to measure the CPU cycle time. In S7-1500 simulation though, the statMemory variable - and all within it - will freeze after some minutes. I don't think your code isn't working, but it's a RUNTIME issue. For the 1500 I will stay at the RT_INFO. 

In S7-1200 simulation statMemory will go back to zero after 439 seconds. At that moment for one cycle the cycle time wil get a -439 s value too. This I can measure with the simple code:

#time := #CPU_CycleTime_s + #time 

Ok, this could be a simulation issue, but now the code is running in a 1214C and it will go up to only 86s instead of 439s. It doesn't matter if I use your code or just 2 simple lines in OB1, it will go back to zero every 86s. After some days testing, changing codes, changing variables and even started a new project, I still don't know why this happens.

So for now I have to go back to the standard TON and TOF timers, because I can't use the cycle time for my own timers unless the PV is less than 86s.

One more challenge to go...

Maybe somebody has an explanation for this.

Regards,

Alex 

Hello.

Your response has been very valuable to me. Thank for sharing.

I have followed up on your notes with my own tests on the RUNTIME instruction. There was a big issue on PLCs before FW4.1. Now with FW4.2 is the first time I look to using the instruction again. Again there is an issue.

The problem - the RUNTME instruction cycles its timestamp (MEM parameter) between 0.0 and aprox. 85.8988246166602. Each time there is a fold-over to 0.0, the measurement error occurs.

If we know what the maximum MEM value can be, we might code some compensation.

This revelation just destroyed many hours of work for me. I needed an accurate time measurement concept to track parts on a conveyor. The timestamp should be triggered by an interrupt for my application.

Luckily I have time to conjure up an alternative now and not on the customers production floor.

Bye.
 - Dan

For what it is worth - revision 3. It compensate for the overflow / roll-over effect.

This is not solving my project issue, but it might solve yours.

- Dan

UPDATE 1:
Further investigation brought a possible solution for my problem. That can be viewed at discussion. Thanks to Alex for his feedback on this subject.

Hello Dan,

Thank you very much!

As I remember I wasn't able to write a value to the timestamp. I'd tried to do it every 60s by a pulse bit. I will try your code anyway.

Nice to see this topic is getting another turn and new 1200 issues are brought to light. I hope Siemens will fix this issue soon. Half of my standard library is useless now. 

Thanks ones more,
Alex

#dP

For what it is worth - revision 3. It compensate for the overflow / roll-over effect.

This is not solving my project issue, but it might solve yours.

- Dan

UPDATE 1:
Further investigation brought a possible solution for my problem. That can be viewed at discussion. Thanks to Alex for his feedback on this subject.

DAN, YOU'RE THE BEST!

Your code is running perfectly! I think I was writing to the wrong variable...

--------------------------------------------------------------------------------------------------------------------------------------

#tempElapsed := #OVERFLOW + #tempElapsed;

As I could see in your code above, you want a "0" value result (85.8997266578954 - 85.8997266578954 = 0).
Therefore I changed the line in V4 to:

#tempElapsed := LREAL#0.0;

And this is working as well. My "RunningTime program" - which I always use to measure and preset running hours - is running for over 5 hours now without any problem.

Attached V4.

Best regards,
Alex

Hello Alex.

Your compliment is very encouraging. Thank you.

Not wanting to sour the situation but I do not agree with the change you made. I suggest you set in the hardware configuration that the PLC cycle is running at a minimum period.  Then you can test versions 3 and 4 against each other.

I suggest:
PLC > Device Configuration > Cycle >
Enable minimum cycle time for cyclic OBs > 30ms

To try and explain - begin with what RUNTIME is doing:

Elapsed time = timestamp.now - timestamp.earlier
          ET =        TS1    -      TS0

When ET < 0 then it means that there was a fold-over event. It does not mean that ET = 0 as what you have done in V4. We now need to convert this to a modulo scale.

Where ET < 0 and delta2 is the time "distance" to the overflow event:

TS1 = 0 + delta1
TS2 = OVERFLOW - delta 2

ET = delta1 + delta2 - OVERFLOW

Time distance between timestamps
= ET + OVERFLOW
= delta1 + delta2

If the scan cycle is short (1ms and less), the fold-over event does not make too much difference. But with higher cycle times the difference is bigger.

Added: Have a look at my other post to which I linked to. It has a STOPWATCH that works like a TONR time accumulator. - WEB LINK - Perhaps you will want to use it. Note that I assumed the #OVERFLOW := 85.9s.

I enjoyed our discussion. Hope we do so again.

Bye.
- Dan

Hi Dan,

Strange, very strange...

My CPU is running at a minimum of 75ms and V4 is still going on.

In attached screendump you'll see my IDB from the hour counter. All is depending on the CycleTime FB. At the upper part you'll see the cycle time at 75ms and at the lower part static value "s_Seconds". Its value shows it survived V4
Note that I changed the cycle times to a static variable because from other blocks I can directly point to this. This is just a part of my program I want, not a part of V4

Yes, I love well argumented discussions. It will bring us to a higher level.

Regards,
Alex