Loops vs Program/stage

[CReese]

Okey doke,

So I've got it refactored in both stage programs and in loop programs.

Stage takes about 1.9s for 1024 alarms, even though those not enabled skip almost all of the logic elements (all but about 15 of them).

Loop (even with a much larger set of logic to process), takes <590ms.

Either I've really screwed up the stage program, or there is a lot of overhead somewhere. I've disabled all other code blocks, so it's just those in question running, so it's not a scan overhead issue with other processes that I have programmed.

Pretty interesting ... but disappointing.

[BobO]

Stage takes about 1.9s for 1024 alarms, even though those not enabled skip almost all of the logic elements (all but about 15 of them).

Loop (even with a much larger set of logic to process), takes <590ms.

The stage implementation is basically doing 1 loop per scan. My guess is that the loop implementation would be about the same if you changed the time slice to 0. The problem here is that you have conflicting needs, in that you need to bulk process the alarms, but an alarm event may not be something that can be processed synchronously. If the loop implementation works, and you are sure that you won't run into trouble when multiple alarms fire at the same time, there is no problem using a loop.

Our motivation is to keep you from doing things that may bite you down the road, not to keep you from doing the app in the way that you feel is best. We've simply seen too many folks hurt themselves...

[CReese]

Worst I can get is a second, and now it seems to hover just under a second whether I'm yielding at 0 or never.

[BobO]

Depending on stage ordering in the program, it's possible that it ends up being more than one scan per pass. There are a large number of variables to consider.

The point is the same though...a loop is a very efficient way to run though large numbers of things, but of marginal use for more asynchronous operations...whereas stages are optimal for asynchronous events, but not the most efficient for rapidly churning through blocks of data. Your app is a hybrid and you have to balance the needs. If engineering was easy, they wouldn't pay us as well, right?

[franji1]

Worst I can get is a second, and now it seems to hover just under a second whether I'm yielding at 0 or never.

You also want to look at your max scan time to help determine optimal .TimeSlice value, in addition to "calendar time" to process one "alarm cycle".

BobO and I were talking, and you previously mentioned this, but possibly looping within the "into alarm" SG as long as you have NO alarm events to process.  This would be implemented as a WHILE, not a FOR/NEXT, and you maintain the index across ladder scans.  This way, as long as you have no alarms, they are "monitored" at a fast(er) pace.  Once alarms start showing up, you slow down, but only to "process" the alarm.

I don't want to get into the logic just yet, but does that make sense to you?

[CReese]

Yes. My brain, however, has decided to call it a day. I'm not in the office Fridays, so I'll pick this up again on Monday. Thanks for being online and helping out. Support is important.

Colin

[BobO]

Support is important.

Hey, if we can't be engineers, at least we can be engineer supporters!

[CReese]

Worst I can get is a second, and now it seems to hover just under a second whether I'm yielding at 0 or never.

You also want to look at your max scan time to help determine optimal .TimeSlice value, in addition to "calendar time" to process one "alarm cycle".

BobO and I were talking, and you previously mentioned this, but possibly looping within the "into alarm" SG as long as you have NO alarm events to process.  This would be implemented as a WHILE, not a FOR/NEXT, and you maintain the index across ladder scans.  This way, as long as you have no alarms, they are "monitored" at a fast(er) pace.  Once alarms start showing up, you slow down, but only to "process" the alarm.

I don't want to get into the logic just yet, but does that make sense to you?

Is this functionally any different than yielding on an alarm log event?

[BobO]

Is this functionally any different than yielding on an alarm log event?

Very much so. What we were thinking was something like this:

Stage 1: Initializes a "loop", which is really just a loop counter. Jumps to stage 2.
Stage 2: Uses a WHILE/WEND loop to cycle through all alarms. If it finds one, it jumps to stage 3, the alarm handler.
Stage 3: Processes the alarm and jumps back to Stage 2. The handler may well be several stages.
Back at stage 2: Continue cycling alarms and processing as appropriate until you hit the end of the list. Jump back to stage 1.

This should give you the benefit of both fast and sequential. This is exactly how I would do it.

[franji1]

Our idea is only helpful for one key feature, to reduce the latency (i.e. calendar time) from when an alarm occurs to when it gets reported.  If the current "calendar time" of a 2 second delay (or more?) is acceptable, then this isn't that important.  However, if you can get that down to 100ms or less, and that makes a big difference, then this idea should be looked at.

[CReese]

What is most important is the loop cycle time. The log rate is not terribly important.

I want each alarm (value vs. norm value) translated into a status as quickly as possible.

[CReese]

Ok, so:

SG0:
SETNUMR DAlarmIndex=0

SG1:
WHILE DummyVariable:
IF DAlarmIndex>=NumDAlarms
    JMP SG0

<< Process Alarm with index DAlarmIndex >>

MATH DAlarmIndex=DAlarmIndex+1
IF LogEvent:
    JMP SG2
JMP SG1

SG2:
<< LogEvent actions >>
JMP SG1

Question : The LogEvent actions can be in a task since it will be executed before the next Log Event, correct?

[CReese]

This is an important line I missed:

When the Jump To Stage (JMP) instruction is executed, it does NOT cause an immediate jump to the target Stage logic, it only disables the current Stage and enables the target Stage. The effect of this instruction will occur the next time those Stages are normally processed as part of the controller's scan. This means that any ladder logic instructions between the Jump To Stage (JMP) instruction and the end of the Stage will still be executed.

Sorry guys, not used to having to read instructions for basic logic.

[franji1]

Question : The LogEvent actions can be in a task since it will be executed before the next Log Event, correct?

I would NOT stick it in a separate code-block, but do all the logic from within S2.  That way, if you DO have anything that takes more than 1 scan, you will stay in S2 until it finishes, then once the work inside S2 is done, JMP back to S1.  Hence, your JMP S1 from within your S2 should have a contact driving it.  You could make it unconditional ONLY IF there are no multi-scan instructions inside S2 (no edge triggers, no async/device instructions, no tmr, no cnt, only "combinatorial" logic that runs to completion within its execution).

[franji1]

When the Jump To Stage (JMP) instruction is executed, it does NOT cause an immediate jump to the target Stage logic, it only disables the current Stage and enables the target Stage. The effect of this instruction will occur the next time those Stages are normally processed as part of the controller's scan. This means that any ladder logic instructions between the Jump To Stage (JMP) instruction and the end of the Stage will still be executed.

One way around that is to use the current stage as an enabling condition

SG S1
...

some terminating condition
JMP S2 (this turns ON S2's bit but also turns OFF S1's bit, but the program pointer is still within S1 on this scan)

S1 contact AND ...  // if the JMP S2 happened, this logic will not be "enabled" because S1 will be OFF
S1 contact AND ...  // ditto
S1 contact AND ...  // ditto

There are other ways around this:
SG S1
...
(termination condition)
OUT Terminate_S1

Terminate_S1 NOT contact AND ...
Termiante_S1 NOT contact AND ...
...
Terminate_S1 NOT contact AND ...
Terminate_S1 contact JMP S2
SG S2


FYI, the EXIT instruction does NOT behave this way - it tweaks the processors program counter to the end of the code-block.  So if you have a conditional EXIT condition, the rest of the code in that code-block WILL be skipped (that implies the remainder of the code within that Stage).