s7-scl for loops execution time??

First of all sorry for my bad english..

Second looking for some info about the execution time of for loops as i have a system that sometimes get heavely loaded due to many big for loops executing..

Questions:

1. Is the execution time of a for loop depending on the data area i am indirect adressing for example

i have a db with an array of 1000 integers and another with an array of 1000 bools and i have a foor loop that just loops trough this area..

Sure i know the execution time of comparing bools instead of int is faster but i wonder if the for loop itself takes longer to execute??

2. How long time takes each increment of the loop in execution time?? lets say i only do a loop with nothing in it e.g

for i:=0 to 1000 by 1 do
end_for


//EDIT

Ok found some info but as I dont have step7 here i wonder is scl using the loop instruction when compiled to STL code??

If it does i can find ut the cycle time now.. Thanks anyway..

1. see 2 but use different arrays

2. Create a function with your nothing loop.

Call it from OB1 say n times until you can see a scan time of say 50ms.
Increase n to m until the scan time is 100ms

1 call is thus (m-n)/50 ms

This leads to a good question.

I keep loop times down by dividing the loops over multiple scans. I haven't had to worry about this with PLCs but a motion controller can't afford to take a scan time hit due to a big loop. After you get the information that L D [AR2,P#0.0] ( couldn't you have picked an easier name to type like TAK or NOP? ) then you have and idea of how many loops you can do per scan without noticing a big jump in the scan times.

A simple motion controller type of program would put all the code that it needs to execute deterministically in an interrupt. If a lot of information must be processed in a loop then that is done in OB1. In think there is even a background OB. L D [AR2,P#0.0] should know about that any background OBs. This way the long loops do not interfere with your normal processing. What you would do it set a bit in the interrupt OB when you want to execute the long loop. When the long loop is done it clears the bit. The code in the interrupt OB will see the bit cleared and know the loop is done. Meanwhile the code that must execute deterministically will still be executing and not be hung up waiting for the long loop to complete.

Now here is where the experience Siemens guys are needed. Say for instance bara_hence has a long loop that takes 100 ms but the real time code is in a 10 ms interrupt OB.

How does the interrupt OB get fresh inputs and update outputs if the I/O is only updated at the end of scan?

At first glance it looks like the S7 has many options on how to handle interrupts and back ground tasks, now what is the reality?

Yes I should spread whats possible over some scans just havent done that as this wasnt a problem until friday night 00.00...

But monday morning I will do that already prepared some source code for that so that should go fairly fast..

As for running a Background OB that sounds to good to be true when I think of siemens.. But thats just me.. Maybe in the 400series that is possible..

As a little question working with siemens CPUs what have been your worst program regarding scantimes??

Our CPU is right now from 20ms-89ms.. The 89ms probably comes when the clockbyte bit for 1s goes on then all ethernet communication, some loops and other executes.. This is what I tend to divide on several scans on monday..

I don't have long scan times.

I am not really a PLC programmer. I just write example programs that make it easier for people to get their PLC to work with our controller so my example program are very short.

However, since I write embedded code for motion controllers, I must be aware of all the tricks.

Our CPU is right now from 20ms-89ms.. The 89ms probably comes when the clockbyte bit for 1s goes on then all ethernet communication, some loops and other executes.. This is what I tend to divide on several scans on monday..

Click to expand...

Don't execute all your 1 second tasks at the same time. Divide your second into 0.1 second intervals and do 1/10 th of what you need to do each 100 ms.

Some tasks you may want to schedule to run every 500 ms or every 200 ms.

The problem with PLCs is that they scan everything all the time when often they don't need to. Try to avoid that. The S7 has a JL instruction that makes it possible to state machines which are very efficient if it applies to your application.