Loops vs Program/stage

[CReese]

Hello all.

I'm trying to evaluate program simplicity vs. execution speed for the following scenario:

I've got a series of operations that perform math, move data around, do some copying, etc., on one element of a bunch of arrays. So something like:

SETNUMR
Myarray1[index] = Myarray2[index] + Myarray3[index]

but obviously much more involved.

Currently I have it set up in a loop where index goes from 0 to length of Myarray1.

For another set of operations, however (memory read operations), I have a two-stage program to do a single operation. I call this from a supervisory program. When the single operation read completes, it goes to the second stage, where it exits to signal completion and this initiates an index increment in the supervisory program and the single operation is again carried out.

My questions:
1. Which is more efficient?
2. How does the loop work in the context of scans? Does it simply span as many scans as necessary to complete the loop operation?

Thanks,
Colin

[franji1]

Looping is discussed in the Help Topic Programs and Tasks Overview DMD0231.  Look under the section Code-block Configuration Options where it discusses the .TimeSlice member of the code-block element.

[CReese]

That was helpful. So the default time slice will punish the loop performance-wise if it is too low, and the overhead of all other scan operations would punish the per-scan staged operation, if I am reading this correctly.

One more question - why don't PD, ND, and Differential contact instructions work in loops properly? This is another reason I'm considering trying my loop operations in a different fashion. Although I prefer state logic, in this case it is resulting in significantly larger code blocks.

[franji1]

"Efficient" is a relative term here.

Minimize Scan Time
Get all the work done as fast as possible (even if my I/O does not update for 3 seconds)

The two are diametrically opposed.  Usually, something between the two is "optimal".  What's good about Do-more is that once you have the basic "algorithm" working, tweaking the .TimeSlice (in micro seconds) is the best way to optimize it.

I've generally seen that .TimeSlice around 100 - 500 uSec for general MATH/MOVE type operations does a good enough job at minimizing scan time, but getting a lot of work done on each scan, thus taking less total number of scans to do all the "looping".

A .TimeSlice of 0 means only iterate the loop once and move on to the next code-block ("always yield" - this minimizes scan time).

A .TimeSlice of 65535 is "DirectLOGIC" mode where you will stay in the loop and no other instructions, no other I/O is done until the loop is done (e.g. FOR/NEXT loop in 260), "never yield".  If it's 1000 iterations, your PLC literally will loop those instructions 1000 times (better make sure your watchdog timer is high enough for lengthy operations, otherwise it will kick you out of RUN mode - you can even manipulate it programatically in DST23, $WatchdogTimeVal).

We just posted an overview of Programs vs. Tasks in the Do-more Example forum.  Look here http://forum.hosteng.com/index.php/board,20.0.html) and click on the "Overview of Programs Vs. Tasks" topic.  Inside there is an attached .PDF of slides that give a good overview of all these details (and many others).  I recommend looking at all of those slides to get a good understanding of how Programs and Tasks work inside Do-more.

[BobO]

One more question - why don't PD, ND, and Differential contact instructions work in loops properly? This is another reason I'm considering trying my loop operations in a different fashion. Although I prefer state logic, in this case it is resulting in significantly larger code blocks.

They work fine, it's just that the conditions required to define an edge are harder to manage in loops. An edge is defined as power ON following power OFF on successive invocations of the instruction. That says that, at best, a differential contact can only be true every other pass through the loop.

[franji1]

One more question - why don't PD, ND, and Differential contact instructions work in loops properly?

The Pgm vs. Tasks Overview may help explain that.  But if you are looping, you are executing no other ladder logic.  So unless the state of the differential contact is being manipulated from WITHIN YOUR LOOP, you will NOT see an "edge" while within the loop (because you are looping, so STRPD X0 will NEVER EVER change because you are not executing any I/O cycle while you stay within the loop).  Sometimes changing .TimeSlice to 0 helps, but usually you must rewrite code within a loop to NOT be dependent upon "edge" triggers (loops and edges do not work well together).

[CReese]

you must rewrite code within a loop to NOT be dependent upon "edge" triggers (loops and edges do not work well together).

This is what I've done. I have a redundant logic bit so that if the logic fails, a change has been made. Essentially equivalent to creating a 'previous value' to compare to, but I don't need one for each piece of data.

If result != logic formula(data, data, data, data, data):
    // something changed, so act accordingly.

[CReese]

One more question - why don't PD, ND, and Differential contact instructions work in loops properly?

The Pgm vs. Tasks Overview may help explain that.  But if you are looping, you are executing no other ladder logic.  So unless the state of the differential contact is being manipulated from WITHIN YOUR LOOP, you will NOT see an "edge" while within the loop (because you are looping, so STRPD X0 will NEVER EVER change because you are not executing any I/O cycle while you stay within the loop).  Sometimes changing .TimeSlice to 0 helps, but usually you must rewrite code within a loop to NOT be dependent upon "edge" triggers (loops and edges do not work well together).

The state of the contact does change within one iteration, and it does not work.

Pseudocode:

For Alarm in Alarmlist:
   if conditionA & conditionB, SET alarmactive

   if differential(alarmactive), log alarm
next

I change no conditions and am watching the differential contact flicker and a counter counting ... while the state logic remains quiet.

[franji1]

Are you using arrays on any of the differentials?

[franji1]

Actually, do you RST within the loop (I saw the SET).  You need to RST the alarm state at the top of the loop?

[franji1]

Actually, do you RST within the loop (I saw the SET).  You need to RST the alarm state at the top of the loop?

And even THEN, you need to evaluate the alarm condition EVERY-OTHER time in the loop (to give the differential contact a chance to see the OFF state.  This is where it gets hard.  If you can rewrite without differentials, that would be best.  Edge detection within loops requires at least two iterations of the loop.  PLCNut has tried that and it gets ugly very quickly.  I think Mr. Nut ended up using an inner FOR/NEXT loop that goes from 0 to 1 to make sure all the inner logic is scanned twice so that edges can be detected.  It is not "straight forward" to say the least.

Try to rewrite to eliminate all edge-triggers, if you can.

[CReese]

Pseudocode:

For AlarmIndex
From 0 to NumAlarms-1

   if AlarmValue[AlarmIndex] != AlarmNormValue[AlarmIndex]
       set AlarmStatus[AlarmIndex]

   if Diff(AlarmStatus[AlarmIndex])
       run LogEvent

next

Could I trick it with something like a SETNUM(AlarmStatus[AlarmIndex] AlarmStatus[AlarmIndex]) ?

The alarmstatus needs to be retained between loops. The statuses are being published to MC registers for read by external systems.

[CReese]

A couple interesting notes:

I found two code blocks that had been set to never yield, despite being copied from code blocks that had standard 100ms yield values.

I changed these values, and now the program refuses to copy, freezing at Monitoring ROM Update status in PLC.

If I turn everything off and on again I can read, but the program runs at a snail's pace, and if I try to update again it freezes. Awesome.

[BobO]

Scan time is going through the roof due to the work. Go to program and figure out what is causing the high scan time.

[BobO]

More to the point...comm is handled at the bottom of each scan. If you wind up with a 100ms scan time because something isn't yielding, it will kill comm. The controller hasn't crashed, but it might look like it externally because it becomes very unresponsive. Worst case get to program mode using the switch on the front...