Execution Speed on indexed variables

[ATU]

Is there a big difference in the BRX execution speed for instruction parameters when using indexed variables and offsets? Trying to balance speed, program storage and readability. Need to get a feel how much these variations can impact execution speed. Also  is it less of an impact on boolean instructions than moving data around? Just need a ballpark feel before I change a bunch of code.

ie

Var
Var1
Var[V100]
Var[V100+25]

[BobO]

Is there a big difference in the BRX execution speed for instruction parameters when using indexed variables and offsets? Trying to balance speed, program storage and readability. Need to get a feel how much these variations can impact execution speed. Also  is it less of an impact on boolean instructions than moving data around? Just need a ballpark feel before I change a bunch of code.

ie

Var
Var1
Var[V100]
Var[V100+25]

Much slower, but does it matter? You can use TICKUS() in the MATH box to profile code sections. It accesses the hardware microsecond timer directly, so you can grab the value at different points in the scan to see what the actual hit is.

[ATU]

Thanks I will try that

[franji1]

Remember that you can tweak each code-block's .TimeSlice also to minimize PLC scan time.  If you are using a lot of array indexing, you are probably using a lot of FOR/NEXT loops.

If your code blocks can handle "yielding", you might try reducing the .TimeSlice (in microseconds).  Looping affects PLC scan time more than linear code.  The ability of a code-block to handle yielding has more to do with the code outside the FOR/NEXT loop, e.g. TMRs or EDGE bits or ?  Check your friendly neighborhood Program Check rule report for potential issues.

If you are doing a lot of STRING operations inside FOR/NEXT loops with NO yielding (.TimeSlice is 65535 or inside a SUBROUTINE) - that will definitely cause big bumps to your PLC scan time.  That's probably the worst case scenario.

[franji1]

BTW, NESTED FOR/NEXT loops are killers.  If you have two loops nested, each one is 1000 iterations, that means your INNER CODE will run 1MILLION TIMES (think bubble sort with 1000 elements).

It's situation like these where yielding with 1000 microsecond .TimeSlice is REQUIRED, but you have to treat the "bubble sort" as a "fully asynchronous" operation, with the ".Done" bit on the "DoBubbleSort" Task code-block.  This asynchronous behavior on the "parent" code-block is easy to comprehend and implement using STAGE.

[ATU]

I was using the offset  index  [V10+25]  pulling data out of an array  in multiple places.  Wanted to make sure it was worth it to first load the value into a memory location and then use that in the instructions. Codespace is getting tight, but I don't want to lengthen the scan time.  I identified places where I repeat code and can use small subroutines. That helped.

[franji1]

I identified places where I repeat code and can use small subroutines. That helped.

Time vs. Space.
If minimizing scan time is the priority, inline code is faster than using subroutines with multiple CALLs for each sub.
If minimizing code-space is the priority, placing large sections of common code in subroutines and using multiple CALLs can be more memory efficient.

It's like horse power vs. fuel economy in an automobile.  It's hard to do both.

But if you are NOT doing any of this inside a FOR/NEXT loop, it's most likely a TRIVIAL bump to scan time regardless.

If a control system gets too complex (e.g. controlling a machine vs. controlling an entire assembly line), then it may be better to have multiple PLCs that are focused on all the localized "lower level" control, but then share data between the two for "higher level" (supervisory) control.

We had to split up a PLC program on a corn cooking batch process at one facility because it had 12 kettles.  The program could handle up to 8, but we split it up between 2 PLCs (one of 8, the other 4).  It was a hack of the original design for both systems, but we got it to work.

[ATU]

I have 4 BRX's already splitting up the process, and they are  passing data with Modbus and Peerlink.  Good thing I split it up when I did, but feature creep is killing me on this one PLC for code space.  The problem is that if I remove features now, that also takes time. I guess you guys run into that all the time.

[Controls Guy]

It's like horse power vs. fuel economy in an automobile.

If you do it well enough, eventually you get to perpetual motion.   

[franji1]

If you do it well enough, eventually you get to perpetual motion.   

I was thinking more like Miller Lite - Less Filling/Tastes Great

[Controls Guy]

I was thinking more like Miller Lite - Less Filling/Tastes Great

Excellent analogy.  All the beers that I think taste the best actually qualify as dinner.