So I have 1 SNAP-PAC R1 A that I want to talk to SNAP-PAC R1 B via tcp/ip. I see examples of passing strings to one another, but I want to send commands from A to B. I want to be able to turn on a digital output connected to SNAP-PAC R1 B via the GUI running on SNAP-PAC A. I don’t know how to send that kind of command. Thanks if you can help.
Hello FlyingTurtle,
The easiest way to do that would be just using the “Turn On” command in the strategy running on your SNAP-PAC-R1 (A). You’d configure an I/O Unit in that strategy with the IP Address of your SNAP-PAC-R1 (B) and configure the appropriate point(s) on that rack/unit.
Does that make sense? Am I missing a piece here?
-OptoMary
Yes, that worked great. Turns out that I am going to need to use TCP/IP so I can check communication between the two though. And in case A goes down, B can run a chart on its own. Unless there’s a way to check if communication has been lost without setting up handles?
There are several ways to check communication between various OptoPieces. I doubt you’d need a comm handle.
Be sure to check out this “I/O Enabler” example which comes with some good documentation.
You might find our “watchdog” feature helpful too. [U][B]This thread[/B][/U] talks about the watchdog feature and detecting other communication issues.
Are these PACs far away from each other, with a high likelihood of losing communications between them? Perhaps wireless?
I’m not sure I completely understand your setup/concerns there, but another thing you can do is read a value in the mem map, like “elapsed time since powerup” at address 0xF0300160 (find more handy mem map addresses in form 1465), delay a couple seconds, check to see if that value is different than last time you checked, and it’s not, proceed with failure more and/or error logging.
For example, you’d call commands like these then check if nOldSecondsSincePowerup is not equal to nSecondsSincePowerup (if it is equal, then something funny is going on).
Does that make sense? Can you tell us more about your comm concerns?
-OptoMary
The optos will be roughly 30 ft apart from each other.
The 2 optos don’t talk via wireless. They talk via a switch, Each opto is connected to the switch individually through eaches ETHERNET 1. My setup is as such:
Opto A has a 32-SNK module connected to set A of digital outputs.
Opto B has a 32-SNK module connected to set B of digital outputs.
I have a laptop with a GUI interface that turns either set of outputs off and on via toggle buttons on the GUI.
All of this currently works.
In the future, the laptop won’t always be there though. I will eventually will have just a touch screen interface HMI.
I am just trying to figure out how communication works between the two to implement if Opto B loses communication with Opto A (very unlikely, but I still need to account for it), Opto B will turn off all of set B digital outputs (since Opto A doesn’t “exist” anymore to control set B of outputs since it lost communication).
Does Opto B also get the same strategy downloaded as Opto A when I select download via PAC Control? Or does it get a strategy at all? If it doesn’t get downloaded, do I have to download the same strategy separately to Opto B that has the logic to check communication and turn off set B of outputs? If I do that, wouldn’t I be duplicating certain things since that strategy is being run on Opto B at the same time?
I didn’t know if I had to make a new strategy file that only exists to turn off set B of outputs (download that strategy separately to Opto B) to be checking if it lost communication or not.
You’ve shown how you can check for communication without a handle, but I was thinking that that only works for when Opto A is checking communication, that Opto A can only do something if communication is lost with Opto B?
So I guess when it comes down to it, I don’t know how Opto B can act on its own/ how to implement it (downloading a separate strategy and what not). And if it has its own separate strategy running, then it’s great that you mention I don’t need communication handles to do a simple check if B has lost comm with A. Of even if it doesn’t, that I can still do that.
Again, in the future I will not always have the laptop connected and the optos only have each other.
So when would I use TCP/IP? Or it so just happens for my purposes I don’t need the data exchange that I don’t have to use it?
Thanks again for your help!
Are you saying that if comms between A & B go missing, you want to turn off all those outputs on B? Because that’s EXACTLY what the built-in watchdog feature does, no programming needed!
That very intelligent I/O unit, when configured for watchdog, will “notice” when nothing has communicated to it in X number of seconds. You configure each point to go into a particular state when that happens – in your case to “off.”
So all you have to do is, in your strategy running on A, configure that “yonder” I/O unit (B) for watchdog after however many seconds you want:
Then, for each of the points on that yonder B I/O Unit, you’ll set Watchdog to “Yes” and “Off.” Make sense? That Yonder I/O Unit (B) could even be a -EB1 or -EB2, because, if I understand your needs correctly, you don’t need to program any logic on that device at all since the watchdog feature is built-in!
Make sense?
-OptoMary
So! Unfortunately that solution doesn’t work out. I did what you said. However, I think the units being connected to a switch is causing issues with the watchdog? Simulating losing connection, I unplug B’s Ethernet cord. The outputs turn off like I want. However, if I unplug A (simulating A went offline), B’s outputs are not turned off. I believe this is because technically it still has a connection, the switch, and therefore the watchdog isn’t activated. Not sure if this is the case, but sounds like it could be. Unfortunately, I need the switch so I can connect a touchscreen via Ethernet later additionally since the opto only has 2 ports. 
To be clear, the watchdog only triggers if NOTHING is talking to that B unit. Could something else (PAC Display, your laptop) still be communicating with it?
Also, what’s the relationship between the A outputs and B outputs – do they always match? (If so, there’s another feature that might be helpful to you…)
You are absolutely right. PAC Display was the culprit. I turn off PAC Display, disconnect the Opto A cable, and Opto B’s outputs turn off. Unfortunately, either the PAC Display or Touch Screen will always be running while the equipment is being used. So it will always be talked to.
A outputs and B outputs rarely ever match.
Thanks again for all this help you’ve been providing! You’re amazing. 
Aw, thanks.
BTW, there is a setting in PAC Display where it will get your I/O values (like from that unit B) either directly from unit (B)… or via the controller. If you’re currently configured to get info directly from the I/O, and you switch that go the “get it from the (A) controller,” that might help? (If you set PAC Display to NOT read directly from the I/O, then it will only communicate with A, then A will do the requesting of the tags.)
In PAC Display Configurator, look under: Configure > Runtime… then the “I/O Unit Tags” tab for the setting I’m talking about here.
I don’t know why you are reluctant to use a Comm handle and setup a TCP connection between A and B to monitor comms.
But there is an undocumented PING “function” that uses MMP via memory map read/writes to ping an address.
You could set this up in your B strategy and if the ping function fails, perform your I/O default chart.
I use this function for exactly the same reason. I have to know if certain devices are alive on the network.
Good point, dmolley, I should’ve mentioned the PING option. There’s a sample chart for that [U]here[/U].
Thank you! I will try your options. I’m not necessarily reluctant to use a Comm handle. I just couldn’t get my TCP comm handles to work. Could anyone link me to some examples using TCP comm handles? Particularly ones where it is SNAP PAC to SNAP PAC communication? I read the one in the user’s manual, but I guess I’m not setting it up right because I can’t connect. Or I’m just not understanding the manual example.
Could you tell me what “manual example” you mean? Normally, a comm handle is NOT how you’d communicate from one PAC to another (you’d use more built-in commands).
dmolley had a good point about the PING option, but I’m not sure what he had in mind for comm handles to another PAC – unless it was something pretty fancy. (I happen to know he does some pretty fancy stuff!)
In any case, here’s a “[U][B]comm handles 101[/B][/U]” post that talks about when you WOULD use a comm handle (usually to talk to a non-Opto Device).
But I’d really like to know where you’re seeing a manual recommend comm handles for what we call “peer-to-peer”? (Often the scratch pad area of the mem map, and corresponding “I/O Unit” commands, are recommended for peer-to-peer.)
mstjohn is right, I was thinking of communication between a pc and an OPTO device, which I do often. I actually don’t think I have ever had the need to communicate from one OPTO device to another other than the built in commands. I think the easiest solution for the problem you have described is using the PING option that mstjohn has posted for you. It not difficult to implement and since it is an icmp low level protocol thingy, you don’t have to worry about setting up and terminating a TCP session and catching errors just to see if some device is online.