Peer-to-Peer one variable for many uses


#1

I am setting up a Peer-to-Peer where I need to get one piece of information from a variable on another R2. The variable may end up being used in a couple different places and/or charts. Do I need to just call that get REST sub that gets my variable every time I need it or is there a better way to keep it updated? In other words should I have a chart to just periodically update variables from a peer unit or is there a better way to keep those variables up to date?

One of the charts that will use this variable is going to rely on it for a ‘do while’ and I don’t want it to get stuck in the loop while because the variable hasn’t been updated. I could have it run the get REST sub every time it goes through the for loop which is inside the do while loop, but I’m wondering if that’s the best way if it may be updated elsewhere at the same time?


#2

Hi ScaDunk,

I’d say get it fresh each place you need it, unless you’re bumping up against speed limitations. (Is this a high-speed situation?) Also be sure to check the errors coming back from the RESTGetInt32 call (or whichever peer-to-peer subroutine you’re using) in case the network goes down or something. You’ll want to make sure you’re not stuck in a loop and doing the wrong thing if comms between the two peers goes away. When you test your code, make sure you disconnect the two and make sure your logic handles that situation appropriately.

In general, the notion of having one chart/piece gather all the data in batches makes more sense for older/slower (like serial) connections or if you’re getting a LARGE amount of data. But if it’s just a little data on a zippy Ethernet connection, it’s usually okay to just grab it when you need it.

-OptoMary


#3

The easiest and cleanest approach is to use the scratchpad (updated periodically) and allow other controllers to grab this data when they need it. I suggest checking communication (in case the PAC-R isn’t available) and transferring the scratchpad data to an internal variable (keep it the same name as the original) to prevent simultaneous calls from different charts.

I know you mention using the REST interface but scratchpad communications is fast and clean.

On larger peer to peer setups you may want to consider reading a heartbeat from each of your data sources to ensure the controller is operational (keep in mind that scratchpad works with the program running or not running), plus compress your binary type data into I32 variables. This will greatly streamline your system.

With 2 or 3 controllers you can simply grab info as you need it but with a larger number of controllers (we’ve done system with 12+ controllers passing internal variables back and forth - some at 100msec update times) I would suggest designating controllers that will both read and write to other controllers scratchpad (read destination info and supply destination with its info). This will reduce Ethernet Collision which we’ve seen slow down communications as well as reduce overall processor utilization (bad communication slows down overall chart time since the commands take longer to complete).