July 5th, 2011, 04:29 PM
Peer-to-Peer - how do YOU do it?
I've been looking through various requests for Advanced Training and the requested topics are wide-ranging. One topic that comes up often is Peer-to-Peer where devices share information with each other.
When the devices are controllers, the "how" varies from the older Factory Floor controllers (where peer-to-peer was much trickier, via TCP), to the recommended usage of our Scratch Pad commands in PAC Control as described in Chapter 10 of form 1700.
There's also the option of doing Mirrored I/O (click that link to see a recent description in OptoNews), if you're sharing data between two brains.
Any of you OptoForum users out there doing some form of sharing data between Opto 22 devices, either using the methods mentioned above, or something different?
Last edited by mstjohn; August 9th, 2011 at 01:23 PM.
July 8th, 2011, 02:12 PM
Our first attack at this topic was pretty crude, but it got the job done so well, that we left it in place for some years.
(If I get some time we can dig into some of the more advanced ways we did this).
In a nut shell we just ran a chart every three seconds and it just wrote the data into the scratch pad of the other unit (or itself depending on what we needed from that peer).
Here is how it looks from the outside;
In each block was the appropriate command "Set I/O Unit Scratch Pad Float Element".
Floats, ints and strings..... as needed....
We just had to keep track of what index had what values in it and make sure we did not double up on the index numbers.
Not all that hard to do in the comments / text.
At the other end, we just read that scratch pad index, and hey presto, peer to peer.
So as you can see it was really simple, but it got the job done.
Those commands made life soooooo much easier than when first tried it when the M4SENET-100 cards first came out and none of those commands existed in Factory Floor....but lets not drag up past horror stories (My first attempt at that chart bricked the LCM4 controller about 4-6 times before I figured out what I was doing wrong. The only way to get it back was to do a fail safe boot loader recovery....but I said that we were not going to drag up those old war stories!).
So, yeah, peer-to-peer, how you all doing it?
August 9th, 2011, 03:13 PM
Now make your PC a "peer" too
Here's the latest chapter to help make peer-to-peer even better--now your data can be stored in either:
FYI - to allow my R1 to "see" this "Generic OptoMMP Device" running on my Windows 7 PC, I needed to turn off the Domain piece in my Windows Firewall.
- The "local" scratch pad area
- Another I/O Unit's scratch pad area
- Your PC running OptoMMP Server (New & very exciting)
Check this out: neat-o!
Download this nifty server now: OptoMMP Server.
Last edited by mstjohn; August 10th, 2011 at 08:46 AM.
Reason: added link to download
May 22nd, 2013, 04:04 PM
Here's another method of doing peer-to-peer, or connecting a groov to a Factory Floor controller!
June 20th, 2014, 07:01 AM
Hi I am new to the Opto Product. Is there any more info on setting up the Scratch pad Peer-to-Peer communications?
I have read the 1700 chapter 10 which has good over view, 1704 Pg.95 but i don't have configuration file, as i worked from PAC control, and 1595 chapter 3 also a good description on how it will work when i get it set up.
I have tried to us the command but i don't think i have the I/O Unit of the type Generic OptoMMP Device.
Last edited by lowbank; June 20th, 2014 at 07:04 AM.
June 20th, 2014, 09:05 AM
Welcome to the OptoForums!
The commands you'd use for that method of doing peer-to-peer do not require a particular I/O Unit type (should work with all of them).
If you don't yet have one configured for the "peer" you want to communicate with, just add one with the IP address of your peer controller and choose that Generic OptoMMP Device for the type.
Also, don't forget our product support is FREE! and they have lots of experience with this Scratch Pad method of doing peer-to-peer.
June 20th, 2014, 03:11 PM
Thanks for the welcome.
I am setting up peer-to-peer between SNAP-PAC-R2's. So I don't need the Generic OptoMMP Device is this right? If so where do i define the scratch pad area. Also when i add a "Set I/O Unit Scratch Pad float Element" command. I have no "Index" Variable to use or "Put Status in" Variable to Put it in. I can change the value of the scratch pad address in PAC Manager. but cant see how to connect this to my strategy.
June 23rd, 2014, 08:26 AM
I can see you are some of the way there, so forgive me for helping those that follow in the future and go back to basics.
Lets start at the start for doing peer to peer......
In controller 1, set controller 2's IP address as an IO unit. (A real IO unit or generic, it does not matter for scratch pad use).
In controller 2, set controller 1's IP address as an IO unit. (A real IO unit or generic, it does not matter for scratch pad use).
(Dont worry about modules, you just need them for their scratchpad areas).
In both strategies, setup each controller in the IO enabler chart so if they go off line, they will get back online automatically.
Ok, so now that each one can see the other, we are ready for the strategy to exchange data.
Open up doc 1703. You can do this from PAC Control, click on Help->Manuals-> Commands quick reference.
Go to page 5. It has the 'I/O Unit- Scratch Pad' command section.
As an example; Controller 1 will issue the command 'Set I/O Unit Scratch Pad Float Element' every (say) second.
When you pull up the command, you will see how it works.
You will be setting the I/O unit to be Controller 2. The index you will need to keep track of (perhaps make 0-99 controller 1 and 100-199 to be controller 2, just a thought) so you don't use the same index twice.
It will come from a float variable (or an int if you use the int version of the command, or a string if you use the string version).
Put the status in a trash variable if you don't care if it gets written to the other controller or not, or in a variable that you do a check of if you do care.
That's all it takes for controller 1 to write a float var to controller 2.
In controller 2 you will have a chart that uses the command 'Get I/O Unit Scratch Pad Float Element', only here it will read it from itself, this way it will read the value that controller 1 wrote.
Done. The loop is complete.
Controller 1 writes it to controller 2, controller 2 reads it.
Reverse the whole thing for controller 2 to write to controller 1 and controller 1 reading itself to get the value.
Note that Opto has already defined the scratch pad area for you.
No better way to do this than to open up Pac Manager and click on Tools->Inspect.
Enter the IP address of either controller 1 or controller 2.
Once that data comes up, on the menu on the left, click on 'Scratch Pad - > Floats'.
There you can see the whole scratch pad area, and the index for each element.
If your strategy is running those commands, you will see data in the matching elements.
Lets know how you get on.
June 23rd, 2014, 04:14 PM
Thanks for that simpler then I thought. One Question. Is it better to write to the remote sites like you have in the above example. Or if you write to the local Scratch pad and the remote site retrieves the data over the net work. does this make any difference? Not sure if you will call this of topic, But if the remote site is disconnected and I have a groov box watching a Variable from the remote site in the local Scratch pad what is a good way to alert users of groov that the value on groov is not getting updated because the comms is down?
Attached diagram of my project
June 24th, 2014, 10:51 AM
Thanks for the diagram, always helps when you have a big picture.
Regarding peer to peer it does not matter if you push or pull (in my experience).... Either way you need to know the data validity and be able to handle old stale data. If you do it at the server (central) or at the client (remote) really does not make much difference.
Regarding stale data, there are a few different ways to tackle it.....
What we did at the hospital was to make index 0 be the controllers 'seconds since midnight'.
All the controllers had time sync charts in them, so they were all roughly in sync.
When ever we did any peer to peer data work, we always looked at the source time, if it was within about 10 seconds of the controllers time, we knew we were working with good data.
If we were more than 10 seconds out, then we considered it old and handled it accordingly (up to you to decide what that means for your process).
You could put a counter in index 0 and every write increments it. The client reads the count and compares it to the last time it read the data.
You could put a counter in index 0 and every write increments it. The client could write 0 to index 0 when it does the read.
Im sure you get the idea. The key is to have some other bit of data that shows the age of the data being read/written.
Once you have that bit of data, its trivial to attach it to a groov gadget. (Have a status page or put said gadget on every page - or both).
Lets know if any of that is clear as mud.
P.S Sorry, cant help myself.... Aussie Aussie Aussie!!!!
Last edited by ben orchard; January 5th, 2015 at 11:02 AM.
Reason: The command we used is 'seconds since midnight' - not milliseconds.