Communication between SNAP PAC S1 and AB PLC


#1

We are building a water plant in the Bahamas and we designed and built the equipment and are doing the controls with OPTO22 hardware and software. We have a number of cabinets with EB1 brains on IO racks and an S1 running the show. There is one subsystem however that is being outsourced by our client which is going to be running on and Allen Bradley CompactLogix L33. This was brought to our attention too late and we already shipped the cabinets and don’t have spare IO that they want us have for interfacing with this other piece of equipment. I would prefer hard wired IO, but since that’s already done, we’re looking at using Ethernet to send and receive data.

I have probably built about 20-25 control systems for water plants over the years but I have never had to get into sharing data over networks with other brand PLCs. Can somebody give me some instruction on how this is set up? I recently taught myself modbus TCP protocol with pointers from a few of the very helpful engineers at OPTO, so I’m sure I can get the swing of this too.

The AB system is going to have about 10 digital outputs to me, 2 digital inputs from me, an analog input from me, and an analog output to me. Both of us would be running logic control, but I need to be able to issue start commands, and they need to be able to send me status signals back and so forth. So it’s not just a simple extension of IO, where one system is Master and the other is Slave. That’s what’s confusing me because the instructional media I’ve come across talks about how to configure opto22 hardware to act as expansions of existing AB control systems, and that’s not really what I have going on.

I have OPTO hardware in my shop that I can play around with, but unfortunately I don’t have any AB stuff to set up and learn on. I’ll need to start a conversation pretty soon with this other supplier on how we’re going to integrate our systems, so any help I can get before then would be great!

Thanks,


#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, 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.


#3

Is it possible for the AB PLC to write to the OPTO22 scratchpad? I haven’t ever used the scratchpad but it’s been recommended to me for sharing info, but what about when I need to know something from the AB system?

We have a phoenix contact 5 port managed switch (PN: 2891030) and two phoenix contact 16 port unmanaged switches (PN: 2891933). The two control PCs running PAC display are connected to the 5 port managed switch, and the two 16 port switches are also tied to the managed switch. All the EB1/2 brains and the S1 are connected to the unmanaged switches. This AB PLC would also be connected to an unmanaged switch.


#4

In order for the AB PLC to write to the S1 scratch pad, it would need to support the OptoMMP protocol, and that’s not likely. The key is to find a protocol that is common to both the PLC and the S1, such as Modbus/TCP and use that to get data back and forth.


#5

Ok,

Well fortunately we are using Modbus TCP for controlling all of our drives. So we would just use the same protocol for comms with AB? So we’d address their PLC as another device (slave or master) and have a designated set of registers on their end that we’d read and write to?


#6

This is actually possible using Modbus/TCP and is built in.

See 1678 Modbus TCP Protocol Guide


#7

You mean the AB PLC can use modbus tcp IP to write to the OPTO scratchpad? Do you know if an Allen Bradley CompactLogix L33 can use Modbus TCP as is, or if there is an additional module required?


#8

All of the Opto Mem Map (OptoMMP) can be accessed via Modbus/TCP (see this post for details), including the scratch pad.

Not sure about the CompactLogix part.


#9

Now the issue with this is the AB PLC system is already done and they want a heap of money to add a modbus module. I wasn’t aware that their controller (CompactLogix L33ER) couldn’t talk modbus without added hardware.

Has anybody had any experience using RSLogix 5000 to read and write to an opto scratchpad?


#10

I have not actually implemented it completely, but I did begin the whole process on a MicroLogix 14 and using EthernetIP, it will talk just fine without using any additional hardware to a Logix controller platform. If you know anything about AB (i’m pretty rusty) you use messaging to connect by setting up tables for the variables in the ML. It’s been a while so I don’t remember the commands, but if you have access to the strategy for the Logix, then it’s really just a matter of reading the docs from Opto22 on the web pertaining to doing a Opto for AB set up. It’s really a very complete step by set process in the AB.
The Opto side is also pretty straightforward. There is a free software package to download and run on your PC and it allows you to create a config file to download to the Pac controller (or brain) that sets up the scratch pad for EthernetIP. All of this is in the docs online.

The scratchpad is really simple to use in general, it is simply like using a table in Pac Control, and you use commands for reading and writing to it, and then use commands to send or receive it to another remote IP address. The key to using it is creating a spreadsheet to keep track of what registers are doing what and whether they are being read or written. The table itself is simply a memory map area of the controller or brain that is reserved for this purpose.

Using the controller instead of a brain is simply a matter of creating a generic brain in pac control in the controller, check Pac Man docs as well.

I use scratch all the time for peer to peer. There is a scratch pad area for each type of data, integers, floats, strings, bits. Each has an area of something like 10,000 registers, stings have less. You can create multiple tables in say the integer area by reading an writing (or reading) from register 100 to 199 for instance and then sending (or receiving) that same area. Typically, I read or write the scratch table to or from a table in Pac Control, but you can also do single elements. So to summarize, you’re moving data from (or to) Pac Control vars or tables to scratch and then sending (or receiving) the scratch to some IP (or other controller or brain).


#11

Isn’t it possible to just use Ethernet IP configurator to set up a couple assembly instances to share with AB? I found a section detailing this in the IO4AB Users Guide. It looks like we can create an assembly on the PAC side which references the scratchpad. Then on the AB side, we add a generic Ethernet IP module, configure the inputs and outputs for it, set up the CPS commands in the ladder, and it should exchange the data, right?


#12

Yes, this is a well proven system and you should have no problems making it happen. You need to experiment with a controller (I bought a 1400 micrologix on ebay for not much) off-line and when you get it set up, if you run into some minor confusion, call tech support. They have at least one support member who is up to speed. Also, check all the Optominute videos, I think they cover this pretty thoroughly.