Hello,
I have been using numerous scratch pad instructions “Set I/O Unit Scratch Pad Float Table” and “Get I/O Unit Scratch Pad Float Table” for quite some time to share data between different controllers running various strategies throughout our facility for quite some time now and have a question regarding which method of communication is faster.
If the data is stored in a currently 50% (will continue to grow) filled 3000 element segregated table is it more efficient to use one “Set I/O Unit Scratch Pad Float Table” and move all 3000 elements in one shot? (I prefer this option)
The other option would be to use 6 or 7 “Set I/O Unit Scratch Pad Float Table” instructions and move only those groups of elements being used out of the 3000 in the table.
Adding a little more insight, we have 8 controllers that share lots of I/O and variables using the scratch pad and we have now added a 9th controller that is a dedicated scratch pad handler. It gathers all data from individual controllers and puts them in the 3000 element table and sends out the data for all others to read using " “Set I/O Unit Scratch Pad Float Table”. This 3000 element table has specific element ranges for each controller to pull the data such as 100-299 = controller1, 300-699 = controller2…etc.
The end result of all this now each controller only has one set and one get I/O unit scratch pad float table instruction to the new dedicated scratch pad controller instead of have to go to every individual controller.
Folks,
I have just finished some timing tests and answered my question myself with “yes” using one “Set I/O Unit Scratch Pad Float Table” with a length of 3000 is still a very fast 13ms.
Hi PilotMan,
Sounds like an interesting application. FYI, when you mentioned a “dedicated scratch pad handler,” I thought: This might be a good place for a SoftPAC – our new PC-Based control PAC which includes all relevant parts of the MMP, including the scratch pad. More info on this SoftPAC page on our website, including a spot where you can sign up for the webinar we’re having next week! (Oct. 18, 2012) <end of shameless plug>
Just curious, what type of PAC did you run this test on? I’m seeing numbers in the same ballpark, a little zippier on my SNAP-PAC-S2, and I would expect results to vary based on a number of things (including what else is happening on your controller/network).
Thanks for sharing!
-OptoMary
Hello Opto Mary,
I did sign up for the webinar and was considering the PC based controller but since the controller scratchpad is so critical to send and receive data to 8 other controllers running different plant processes, I feel more comfortable using the PAC S2 in a secured enclosed cabinet over a PC. Besides, I trust your made in America PAC Controller to be more robust then a lot of the PC’s out there!
The scratch pad controller is a PAC S2 and I have a test setup with a total of 2x S2’s and 2x R1’s. I have and still am putting a lot of time on this trying to optimize by monitoring and tweaking to keep chart and controller loop times as low as possible. There is one method that would help considerable since the different controllers only need part of the data stored in the 3000 element table. It is more involved requiring the dedicated scratch pad controller to map table elements into specific groups for each controller instead of the current method where it simply combines the data and sends it out in the 3000 element table for everyone. This would reduce the get table range sizes considerably (to about 1000) for the individual process controller side and it does reduce my chart speed from 240ms to about 160ms but on the downside, following a variable from the source controller through the data transfer and then the destination controller gets a bit confusing and requires a spreadsheet to keep up with them.
