ControlLogix to DeltaV integration

Hello,

I am putting together a system that I have never done before and I want to make sure that I am doing this right. If someone could give me a sanity check.

So, at a client facility they have both control logix and deltaV systems. We are putting in a new 1756-EN2T remote PLC extension on a L82 controller for a new system we are putting in (System A).

The issue is this. We have a second system that is completely unrelated to System A. We can call it System B. System B is an extension onto an existing system controlled by a DeltaV PLC. The thing is is that the physical location of System B is going is nowhere near the DeltaV PLC but it is very close to our new EN2T remote rack that we are putting in for System A. What I want to do is tie in all of the points to our AB remote rack then push them over network to the DeltaV system.

Now, from the research I have done, AB and DeltaV can integrate natively over Ethernet/IP. My problem is, is that I have never touched a deltaV PLC so I am unsure of how this all comes together (luckily I do not have to do the programming but I need the system requirements to be there for someone else to do the programming).

So they already have VIM2 M-series card (short black one not the fancy grey and black card). It looks like that can do Ethernet/IP. Is that all of the system requirements they need to do this? Do they just add an allen bradley driver into an IO tree similar to RSLogix?

I have "interfaced" with the Delta V a few times over my Career. Mostly DIO and Modbus. I have no real hands on programming experience with them. They seem to be a different animal than most PLC's, based on what I could see by looking over the programmers shoulder.

So will the I/O from System B be connected to your PLC or be connected to the Delta V?

It may just be simpler and cheaper in the long run to have the Delta V contractor put in their Remote I/O equipment and let them do the programming for their system. A lot of times when you have 2 different Integrators with different equipment in the same space it can get very ugly. If things don't work then the Delta V guy is pointing at you and if he does something to screw up your system then you are pointing fingers at him and on and on we go.

Hello jakeparsons03:
I have no experience with DeltaV but I have some with ControlLogix and CompactLogix, as well as with EtherNet/IP technology, so In hope my post can help with your sanity check. So you have this System A (based on ControlLogix) and System B which is a DeltaV with EtherNet/IP communication capability. If you have time, you may find this post in the PLCtalk.net forum interesting, as the use case is similar, but not exactly the same as yours. There are some tips which you may find useful.
At the end of thy post I am adding a screenshot from the post I mentioned before, showing some of the EtherNet/IP capabilities of the DeltaV system. From what I have learned, the DeltaV is from a stand-point of EtherNet/IP, a client EtherNet/IP application. This means it can only initiate communication to an EtherNet/IP device. Since ControlLogix supports both, EtherNet/IP client and server functionality, I think this leaves you few choices. Since the DeltaV supports PCCC client messaging, my recommendation is for you to create PCCC type "N" or integer tags in the ControlLogix program, and use the DeltaV to read or write to these "N" files. I think it is straight forward to have one N file for sending data from DeltaV to ControlLogix, and a different one to get data on DeltaV from ControlLogix. I would recommend you also define some heartbeats from one controller to the other and vice-versa, so it is possible to detect if one or the other has faulted or gone into program mode. In case you choose implicit messaging you do not need the heartbeat logic. But implicit messaging has limitations in the size of the connection of up to 504 bytes or so, whereas integer files are much larger (not sure the number at the moment from memory). I am assuming you do not require millisecond synchronization between these two applications, and that your use case requires data in the order of a few kilo words. I hope this information may be useful.

jakeparsons03 said:

Hello,

I am putting together a system that I have never done before and I want to make sure that I am doing this right. If someone could give me a sanity check.

So, at a client facility they have both control logix and deltaV systems. We are putting in a new 1756-EN2T remote PLC extension on a L82 controller for a new system we are putting in (System A).

The issue is this. We have a second system that is completely unrelated to System A. We can call it System B. System B is an extension onto an existing system controlled by a DeltaV PLC. The thing is is that the physical location of System B is going is nowhere near the DeltaV PLC but it is very close to our new EN2T remote rack that we are putting in for System A. What I want to do is tie in all of the points to our AB remote rack then push them over network to the DeltaV system.

Now, from the research I have done, AB and DeltaV can integrate natively over Ethernet/IP. My problem is, is that I have never touched a deltaV PLC so I am unsure of how this all comes together (luckily I do not have to do the programming but I need the system requirements to be there for someone else to do the programming).

So they already have VIM2 M-series card (short black one not the fancy grey and black card). It looks like that can do Ethernet/IP. Is that all of the system requirements they need to do this? Do they just add an allen bradley driver into an IO tree similar to RSLogix?

Click to expand...

This is going to make your life complicated, sending data to DeltaV and then executing the commands coming back from DeltaV. Buy a cabinet, install DeltaV charms, connect back to System A, and then wire it up. That's my recommendation.

We have several DeltaV controller pairs interfacing with several ControlLogix.

On the DeltaV side, we use their Virtual Interface Module (VIM). It may be called a VIM2 ... I'm not sure. In the DeltaV programming software it 'looks like' a bunch of serial interface modules. The data is 'mapped' as modbus style 16 bit registers.

On the Rockwell side, we use EN2Ts and ENBTs. The PLCs see each VIM as an ethernet rack, with 31 'slots' at a maximum of 125 registers each. This is 'type 1' messaging, or IO messaging. Multiple PLCs can 'see' a single VIM as a remote rack each. Each VIM can only talk to one DeltaV controller pair (Redundant)

The DeltaV can use type 1 messaging or type 3 messaging. Type 3 is 'mapped' messaging where the message is mapped into an array in the PLC and the data just 'shows up'.

We have extensive troubleshooting information logged on the DeltaV side and the PLC side to ensure that the data is actually getting through. There is also alarming on both sides.

Our instrument department selected Emerson's DeltaV for their process control. The electrical department selected Rockwell's ControlLogix for motor , gate and other discrete control.

If Emerson did not charge so much for their IO licensing, the whole site might have been done with DeltaV. Rockwell PLCs and IO, including yearly support, hardware, and software licensing ... was about 10% of what DeltaV was. This was in 2003.

We have several spreadsheets detailing what registers map to what ControlLogix arrays, what each register is used for, or what each bit is used for, standards for allocating the bits and registers ... how long the bits have to be on so that the DeltaV is certain to see the alarms or status changes ...

It's a lot of overhead. Like I said, install charms or a remote DeltaV rack and keep everything in one system. It's just not worth starting along this path if you are not already doing it, or you are not doing a substantial number of IO (We have 70 racks of IO, 300 VFDs, across 12 ControlLogix). Some days, I'm still not sure that it was worth it