What should be correct order of Runtimes Groups?

What should be correct order of Runtimes Groups ? Is there any "correct order" ? What if feedback from valve is also used in this logic (so we have even more "loops") ?

Best regards

Kargan

------------------------------------------------------------------------------------------
Split from Runtime group in random order.

Hi Kargan,

the "correct order" of Runtime Groups is also like run sequence, it should be according to the data flow in order to reduce dead times to a minimum during program runtime in the CPU otherwise the CPU processing old values.

For this demand you can use the function "Optimizing the run sequence". This function is used to optimize the program run sequence according to the data flow in order to reduce dead times.

More Information about the optimiation of runtime groups and run sequence you can found in the manual CFC for SIMATIC S7 in section Optimizing the run sequence.

With regards
Heisenberg

Heisenberg2

For this demand you can use the function "Optimizing the run sequence". This function is used to optimize the program run sequence according to the data flow in order to reduce dead times.

Hi Heisenberg2,

I know the basics (more or less) and I read also this chapter. My question was more like "is there any sense to make this Optimization if logic is more complex" ? I did some example of very simple logic but with a loop - see attached screen. We have 5 CFC charts and let say they are in the same OB35. Small numbers are showing order of blocks on each chart. Now because of this loop (from Motor Fault to NOT gate at Logic CFC) - will "Optimize Run Sequence" propperly optimize Runetime Groups in OB35 ? Does such optimization will change a way of program execution ? 

Let's say Runtime Groups Order is (I hope that order of Runetime Groups is also order of their execution ??):

AAA

BBB

CCC

XXX

YYY

In ideal situation if value of binary signal will change BEFERO OB35 was executed we will have reaction in one Cycle of OB35 (from input to output). But what about this loop from Motor block to XXX Chart ? When exactly this signal is send from YYY chart to XXX chart ? During execution of YYY ? But this mean that when XXX was executed this information was not yet there. So we need at least two cycles of OB35 to get this logic fully "executed" ? 

I'm not sure if I explained this enough clearly :)
So if in a bad scenario we need anyway 2 cycles of OB35 to fully execute logic shall we care about Runtime Groups Order ? Of course this is simple example but usually logic are more complex and more "looped".

Hello Kargan, 

I would like to share my point of view. 

What I think is, it can't be perfect. As you said, there might be complex logic and a lot of loops. Therefore, my priority is like below

1. The primary order should be direct shutdown from the input. When certain input received, we must make sure the output is then send out in one cycle instead of >1 cycle. 

2. The second priority is, those with one cycle pulse trigger, be extra careful on the runtime group order. As it will just trigger a pulse in one cycle, hence, this should be taken care carefully. 

3. Always make sure the input is at the top of the Runtime order and output is at the back of the runtime order. (rearrange it at runtime editor)

These are the three things that I will focus in doing. Hope my ways do help you. 

Hello Kargan,

You are right on understanding with Input Driver-Block-Output driver. The order comes automatically with this concept.

* It becomes more tricky in case of pulse kind of behaviors. With such functions the run-time sequence plays very vital role. Wrong run-time group would cause non-functionality of process/logic or non-reliable behaviors. Since run-time groups are defined with charts so it becomes important to place group also in order along with group items.

Apart from pulse kind behavior the run-time group sequence is acceptable as long as it is not affecting on process behavior.

* The runtime group also plays important role in PID parts which I think should be considered as pulse kind behavior due to it's nature. The update to output driver in every cycles becomes critical where precision matters in processes. And to achieve that runtime group in correct order is important.

* Similarly, runtime group has big share in AS-As communications. As these communications has their own propagation times to deliver information from out of one physical device to in of another physical device and OB cycles where these are called. With incorrect order of runtime group will add up further time.

So runtime group with correct order helps to tune up logicx and run process smooth and hassle free.

Naming block also a good practice.

Hello Kargan,

Let me try to explain my sentence

Heisenberg2

the "correct order" of Runtime Groups is also like run sequence, it should be according to the data flow in order to reduce dead times to a minimum during program runtime in the CPU otherwise the CPU processing old values.

with your example of CFCs.

Kargan

 Let's say Runtime Groups Order is (I hope that order of Runetime Groups is also order of their execution ??):

AAA

BBB

CCC

XXX

YYY

The CFCs AAA, BBB and CCC are independent from each other, but they have to called for the XXX chart otherwise you get an addition dead time for each chart. 

The CFCs XXX and YYY have one connection form each other. So in both case (XXX first or YYY first) you get one dead time.

In this case, there is not only one correct solution, but more than one. So correct order can be:

• 1.YYY 2.CCC, 3.BBB, 4.AAA, 5.XXX
  The sum of all dead times in all CFCs are one.
• 1.AAA 2.BBB 3.CCC 4.XXX 5.YYY
  In this case the sum of all dead times are also one.
• 1.BBB. 2.CCC. 3.AAA 4.YYY 5.XXX
  The sum of all dead times are also one.
  
• all others orders where the sum of dead times is one.

An incorrect order would therefore a order if it contains more than one dead time. For example 1.AAA 2.BBB 3.XXX 4.YYY 5.CCC.

The optimize function will reduce the sum of all dead times to one. In the case that the sum of the dead times is already one nothing is changed. With the incorrect example above the optimize function will made as few changes as possible are to get to the goal of one dead time. In this case the function will place the chart CCC before the chart XXX (1.AAA 2.BBB 3.CCC. 4.XXX 5.YYY).

I hope I could at least bring a little clarity.

With regards
Heisenberg