Before I spend a lot of time and effort, I was wondering if using table/element results in faster loop times then individual float/integer variables? Specifically, I currently have over 300 setpoints each with its own assigned variable and am interested in eliminating them all and replacing them with a 300 element float table. Then the code for each variable would change from something like this:
if (CALCULATED_VALUE > STPT_MAX_CALC_VALUE_LIMIT) then …
To the 300 float table element[5]:
if (CALCULATED_VALUE > fl_TABLE_STPTS[5]) then…
Changing from individual variables to the 300 element table would remove that may tags but I am not sure if during program execution, it takes longer to for internal nuts and bolts of the code to look up a specific element in this table?
The short answers your specific questions (with the usual disclaimers: your mileage my vary, etc.): Yes. No.
Longer answer: The two were close, but comparing float table elements was consistently faster than comparing the same number of individual floats, using R9.3c firmware on an R1 or R9.3b on SoftPAC. I’ll share a recording of the quick test I ran, and the chart too, if you’re interested.
However, other factors impact that speed a whole lot more, for example: SoftPAC vs. PAC-R1, Full Debug vs. Minimal Debug, PAC Control Debugger running vs. not.
Wow thanks for running a test so quickly and “YES” I am interested in your shared chart for I would like to test it on my development S2 I have here in my office.
Regarding your questions, I have been optimizing our strategies for 3 or so years and am familiar with both documents. Also, as much as I would like to run the strategy on a PC using SoftPAC, our process is extremely critical and needs to be controlled from your more robust controllers.
In regards to the table element question we have hundreds of alarms and setpoints that have been manually written back from the FFloor days when the M4RTU was hot stuff to using your latest PAC with the built in alarms. Now that I am in the process of reviewing, changing them all to the same modular type as my newest projects would standardize them and make it easier for others to follow.
Since, I already use the MicroSD to read & write these (alarm) recipes into tables using SUBS and then moving each table element to a unique variable, thus can be simplified by eliminating this last step. Of course, now we have the problem when debugging an alarm which will have the value somewhere in a specific element making it harder to find. But early this morning, I had an idea on keeping track and displaying all these setpoints by creating a new dedicated HMI with these tables and their values which is to be used for developers or troubleshooting only.
The way I have tested my changes in the past is when running in debug, I would put a break point on the first block in the chart that is being tested and then when it stops at that point look at the time on the bottom left window. I would do this several times to get the average loop time, make my changes and check again. This is a real primitive method and it seemed to work ok but I bet you have a better way knowing your experience!
Ah, good point and I was just about to suggest something that would help w/the troubleshooting/maintainability (although might slow down performance slightly, you’d have to weigh the trade-off).
Rather changing your (referring to example above):
[INDENT][B]STPT_MAX_CALC_VALUE_LIMIT[/B][/INDENT]
to
[B][INDENT]fl_TABLE_STPTS[5][/INDENT][/B]
I would create a “constant” which is more meaningful and searchable than [B][I]5[/I][/B]. For example:
[B][INDENT]index_STPT_MAX_CALC_VALUE_LIMIT[/INDENT][/B]
The latest R1 firmware appears to still be R9.3b. Are you from the future? Your secret is safe with me. Thanks for running this benchmark, and publishing the chart.
For wine and flowers I could be convinced to share some stock tips, too.
But yes, I should’ve called that B9.3c as you are correct, that’s not yet been released–although I just did a quick test on R9.3b on this R1 and the float element accessing was still slightly faster than a single float access, so my time-traveling tricks shouldn’t matter here!
