Content
# #ccsd-water-ignition — 2025-08-29
**06:46 [andy](https://slack.com/archives/C08TVA84PD4/p1756475169723029):** I believe it can, but I found the forum post that directed me away from this approach. but I'm not sure I agree with it, because that's what Atascadero has done for years:
https://forums.opto22.com/t/communication-between-snap-pac-s1-and-ab-plc/1129/2
*[Mr_Bill](https://forums.opto22.com/u/mr_bill)*
Junior Member
[Dec 2016](https://forums.opto22.com/t/communication-between-snap-pac-s1-and-ab-plc/1129/2)
The EtherNet/IP capability of the EB brains only supports being a slave to the AB PLC. In addition, EtherNet/IP protocol puts a lot of traffic on the Ethernet network and can flood the other devices. Because of this, whenever implementing an EtherNet/IP protocol solution, it is important to use the right kind of Ethernet switches, ones that support IGMP snooping.
A better route for this application would be to use Modbus/TCP. If the AB PLC supports Modbus/TCP protocol, then the next question would be if the AB PLC can be a Modbus/TCP Master or Slave or both.
On the S1 you can use the [Modbus Integration Kit for PAC Control](http://www.opto22.com/site/downloads/dl_drilldown.aspx?aid=4206), which supports both Master and Slave capabilities. You may simply want to make the S1 the Master and the AB the slave and then read and write on a regular basis.
**06:47 [andy](https://slack.com/archives/C08TVA84PD4/p1756475242349409):** I could put managed switches to facilitate IMGP snooping to control EIP explicit messaging to the Opto 22 controllers if you guys can figure that out. That would be simple
**06:48 [andy](https://slack.com/archives/C08TVA84PD4/p1756475283523649):** I'm pretty sure AMWC doesn't have managed switches everywhere, they use NTRON unmanaged at the RTUs
**06:54 [andy](https://slack.com/archives/C08TVA84PD4/p1756475694733819):** Some feedback from Gemini (take it with a grain of salt perhaps):
Yes, Opto 22's official forums and other industrial automation communities have posts from users and Opto 22 engineers that confirm this can be done. These discussions often detail the exact process of using Allen-Bradley's `MSG` instruction to send explicit messages to SNAP PAC hardware.
Here are summaries of what can be found in public forums:
• *General Confirmation with Various PLCs:* In a discussion on [MrPLC.com](http://MrPLC.com), engineers confirm that communicating with Opto 22 SNAP I/O from Allen-Bradley PLCs like MicroLogix, CompactLogix, and ControlLogix is possible but requires the use of explicit messaging (the `MSG` instruction) to send and receive data. They note that while Opto 22's documentation heavily features examples with implicit (I/O) connections, the explicit messaging method is the way to achieve this communication with PLCs like the MicroLogix series.
• *Data Exchange Method:* Posts clarify that you will use explicit messaging commands from the Allen-Bradley PLC to connect to the Opto 22 rack. This involves pushing data to or pulling data from specific object attributes into data blocks (tags) within the PLC. For example, one `MSG` instruction would be configured to read input data, and another would be configured to write output data.
• *Official Opto 22 Documentation:* The forums and product pages frequently reference official Opto 22 guides, such as the "IO4AB User's Guide (Form 1909)". This guide specifically details how to set up EtherNet/IP messaging between an Allen-Bradley® Logix™ controller and Opto 22's SNAP PAC I/O using Rockwell's RSLogix™ 5000 software. This confirms it is a well-documented and supported integration.
• *Supported Hardware:* Product pages for hardware like the SNAP-PAC-EB2 explicitly state they can be "used as intelligent remote I/O with Allen-Bradley industrial PLC systems such as MicroLogix, or other A-B PLCs using explicit messaging".
These forum discussions and official documents collectively confirm that not only is this possible, but it is a recognized application for integrating Opto 22 I/O into a Rockwell Automation control system.
**16:57 [Kevin](https://slack.com/archives/C08TVA84PD4/p1756511870567079):** Thanks Andy. I think we will try to make the AB explicit messaging work as this will be the cleanest solution in my opinion. We put in a couple hours last night and made good progress. Shouldn't take but a couple more to explore this solution.
**16:58 [Kevin](https://slack.com/archives/C08TVA84PD4/p1756511906352249):** what radios are in use at CCSD?
**16:58 [Kevin](https://slack.com/archives/C08TVA84PD4/p1756511931139529):** I'm vaguely remembering they are not all the same
**17:15 [andy](https://slack.com/archives/C08TVA84PD4/p1756512930659499):** They are mostly all Ubiquiti Ethernet TCPIP based radios. Mostly 5.8ghz some 900mhz