Your better Peer-to-Peer for PAC

[chemabdn]

I need your better sample of Peer-to-Peer for comunications between PAC for upgrade my code.

Thanks

[Beno]

OptoMary is out of the office for a bit, I am not sure which one she / you are referring to, so just hang tight and she will come to the rescue soon.

[mstjohn]

Hi chemadbn,
I can think of at least 3 different ways to do peer-to-peer, but which (if any) make sense for you would depend on your goals and firmware versions. What kind of data are you trying to share? How fast/often? What hardware/firmware?
Thanks,
Mary

[chemabdn]

SNAP-PAC-S1

R9.4a

Floats, Integers between controllers

Refresh 1 sec more o less

[mstjohn]

If you don’t mind upgrading your firmware to 9.5, I’d recommend this RESTful approach. You can try it with PAC Sim 9.5 talking to a Learning Center we have here in the building, connected to the Internet, see this post:

Peer-to-peer via RESTful API!

Hi OptoFans, A nifty use for our new-in-9.5 RESTful interface: easier peer-to-peer communication between PAC controllers! Here’s a simple example to show how. This single-chart strategy lets you read and write to tags on a SNAP-PAC-R1 here at Opto 22 headquarters via that -R1’s RESTful server. Included in this CLIENT example PAC Control Basic 9.5 strategy, you’ll find 5 subroutines: 2 to write (POST) values to a remote PAC, 2 to read (GET) values from a remote PAC, One “Helper” sub…

Are you talking just a handful of floats and ints? (If you have, say, HUNDREDS or thousands of values you want to move, then using the older Scratch Pad method might make more sense.)

[chemabdn]

I work in a chemical company, and I prefer not to take risks. The firmware I have works well without any problems. What can be done with my firmware?

[mstjohn]

In that case, you’ll want to use the Scratch Pad method, which is described in the PAC Control User’s Guide, Chapter 10. Here’s the page in particular:

[chemabdn]

And this way to program peertopeer is correct for OPTO22?

[philip]

The easiest way is to add the remote controller as a Generic OptoMMP Device I/O Unit and then use the Scratchpad commands which take an I/O Unit as a parameter.

[chemabdn]

If it is simpler, I have tested it and it works fine, but we in our code have instructions P2P_Get_FloatTable, P2P_Get_Int32Table, P2P_Set_FloatTable and P2P_Set_Int32Table and I do not know if it can be done better? that’s why I asked.

[philip]

The scratchpad equivalents to what you are showing would be:

P2P_Get_FloatTable ~ Get I/O Unit Scratch Pad Float Table
P2P_Set_FloatTable ~ Set I/O Unit Scratch Pad Float Table
and so forth.

So the scratchpad becomes the P2P “holding area” instead of your P2P tables you have setup.

The rest of your code looks like it can remain the same, only thing you will need to watch out for is when I/O units go offline. If you use Opto’s IO Enabler chart, you should add the remote IO units to that.

If you have a lot of remote controllers and they all have the same or very similar strategies, then you are probably best having the remote controllers write to their local scratchpad (since you won’t need to write to different addresses) and then have the main controller read from each remote scratchpad. Hope that makes sense.

I recommend that you write comments in your strategies for which scratchpad areas are being used. I put these comments in the power up chart, so in the future I don’t accidentally write to a scratchpad area that is being used for something else.

[PilotMan]

I work for a Chemical company and have numerous controllers throughout the processes using the scratchpad as mentioned above. Since some of the processes are critical, there is a dedicated S1 controller that communicates with all the others and acts as a traffic cop moving large tables of data from proper sources/destinations in much below 1 sec. There is error checking, testing(Ensure controllers are actually running and processing data), alarming and logic to put affected I/O’s in their failsafe modes. If you are interested let me know and I can provide more insight. I forgot to mention; I have a master Excel spreadsheet to keep track of table elements and names. Each controller has an allocated table and range that is received from the dedicated S1 controller that compiles the data from the others.

[ScaDunk]

Do you guys know if there are any sample code examples of this stuff or would be willing to send me some examples of how you would set something up? I like your comments Idea. What kind of comments do you add?

I am trying to do some of this right now. I don’t have much data to move yet, but in the future I may have more.

Thanks

[philip]

Based on your other post on peer to peer, I would recommend you go with the REST approach if you are only reading a few variables - as you only have to have code for it on one controller making it easier to maintain.
With the scratchpad, you have to have the one controller copy from your variable to the scratchpad, and then the other controller will need to read the scratchpad, so you have two strategies to maintain for scratchpad communication. You may find a lot more posts about the scratchpad as that has been around forever and the REST commands are new.

The comments I use are pretty basic - I just stick them in a text tool on the powerup chart - here is one from one strategy:

SCRATCHPAD IN USE:

Integer area for start/stop scheduling - using the indexes that correspond to the device IDs controlled by this controller. (78 through 129 - see Init Zone and Group Names)
200 Load Shed

Float[0] is the max cooling call to determine if we should run the chilled water pump