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!