ControlLogix Redundancy Mode Ethernet/IP w/ NET-ENI

[usfilter 0]

Has anyone ever tried to connect a 1761-NET-ENI with ControlLogix running in redundancy mode(Two racks with the following: Slot 0 - 1556-L62; Slot 1/2 - 1757-SRM; Slot 3 - 1756-CNBR; Slot 4 - 1756-ENBT)? We've done several jobs using NET-ENI(node addr 45) with single ControlLogix(Slot 0). Normally the DF1 Full-Duplex device connected to ENI is polling ControlLogix. AB's ControlLogix Redundancy System manual says: In a redundant system, use an EtherNet/IP network only for HMI/workstation communication and messaging. Do not use an EtherNet/IP network for: • communication with I/O modules. • communication between devices via produced/consumed tags. My understanding of ENI module is it's using "message", not produced/consumed tags, nor I/O module. So it seems OK. But AB's tech support told us we need to get another CompactLogix between ControlLogx(ControlNet) and ENI(Ethernet/IP) which is kind of expensive. Since I don't have all equipments in office to test, I hope someone here has tried the similar thing before.

[BobLfoot 301]

I've done ControlLogix Redundant Setup in Version 13. We had the CPU, The SRM, The ENBT and then Several CNBR. I'll only talk about what happens to the ENBT for sake of time and space. You have two racks call them A and B. 1. Rack A is primary and has ENBT at Ip of 192.168.2.101 2. Rack B is secondary and has ENBT at Ip of 192.168.2.102 3. HMI is communicating from an IP of 192.168.2.103 with 101. 4. Your System Fails over for any number of reasons 5. Rack A is now DEAD but will have an IP of 192.168.2.102 when brought back to life as the secondary 6. Rack B is now Primary and has ENBT at Ip of 192.168.2.101 The above described Ip rollover is handled by the SRM modules. They cannot change the ENI IP, hence RA's advice to interpose a compactlogix. Is there a reason why you can't use two ENBT in the Controllogix racks?

[usfilter 0]

The current ENBT in each rack is designed to communicate with ENI(connected to a 3rd party DF1 full-duplex device) only. The DF1 device needs to read some values from ControlLogix through ENI. My understanding of a redundancy system is the 3rd party device/ENI only needs to talk to one IP(the primary one-192.168.2.101) and we don't care the down time because of IP switchover. There is no need to change ENI's IP. Are you suggesting we talk to both IP's at the same time? The main issue is that we were told once ControlLogix is running in redundancy mode, it can NOT talk to ENI through ENBT(that's why they recommended CompactLogix as a bridge). I just want to know whether this is true or not since I can't confirm it based on their manual.

[BobLfoot 301]

MEA CUPLA - I missed that ENI was connected to the 3rd party device, I assumed that the ENi was connected to the Contrologix Serial Port to provide ethernet. I have no experience upon which to disagree with RA tTech Support, but if your 3rd party device can tolerate the 30 seconds of comm loss during the IP rollover then I'd give it a test and expect it to work.

[Ken Roach 194]

I get it now; the third party system is the DF1 Full Duplex message originator and usually it communicates with a simplex ControlLogix via 1756-ENBT. The same configuration should work fine with a redundant ControlLogix because the -SRM module handles the swap of IP addresses between modules. The 1761-NET-ENI connected system will always be communicating with the Primary controller. I've used some switches that will resolve the IP/MAC swap in a couple of seconds, others that take three minutes. I've been reading appellate court decisions for fun today and I think we should start using their lingo: "I concur and remand".

[paulengr 44]

It is correct that it is using solicited (not produced/consumed) communications. The underlying hardware of the ENI module is actually a Lantronix "IA" or "UDS" type device. I'm not really sure what protocols they specifically implement in it. The trouble is that there are at least 3 or 4 variants of the DF-1 commands (depending on PLC version). I don't know specifics but I have been told that the 5 variants are "untyped" (PLC-3), PLC-5, SLC, Micrologix (yes, ENI includes it's own variant), and ControlLogix. The first 3 variants are well documented. The last 2 have NO documentation on exactly how they work. In addition, there are at least 3 "encapsulation" methods for Ethernet. There is the original PCCC protocol, the CSP protocol, and the PCCC or CSP over CIP protocol (making 4 total protocols). Needless to say, you can mix and match any of these 4 encapsulation methods with any of the 5 command sets for a total of 20 different variations of a "message" protocol, and we haven't even touched any producer/consumer CIP stuff! Of course each major PLC family only recognizes a handful of these, but which ones they recognize is not altogether clear either (although there is a chart in the DF-1 documentation that purports to show at least partial information about this). So...what AB is telling you may indeed be correct. No way to find out except to try it. I have two suggestions though. First, you could use a Micrologix 1100. This gives you the needed Ethernet/DF-1 conversion for about half the price of a NET-ENI, and includes some other ports that you could use as well, and it implements a much more complete set of protocols compared with the NET ENI, and you don't need that pesky configuration program, and it is not as finicky about power quality issues. Just make sure to flash the firmware up to the latest release as it seems that some of the earlier releases had some really buggy IP protocol stacks. I know this really isn't the intended purpose of this little PLC but I'm finding all kinds of "not really intended" purposes for them to serve. Out of the last 6 or 7 I've bought, only one actually ended up serving as a "real" PLC and not some port/IO helper function. The second suggestion is to use a serial port server directly at the PLC. Many brands of these devices (Digi One comes immediately to mind such as a Digi One SP) allow you to "link" them...any data communication on one is sent to the other and vice versa, duplicating the configuration stuff you did with the NET ENI, but these cost even less than the Micrologix 1100. They won't tolerate "IP address swapping" and you'd need an extra IP port available close by the PLC but this may not be a major issue. The disadvantage here is that you tie up the PLC's serial port. The big advantage is that protocol compatibility is a non-issue...you aren't trying to fight compatibility...just out right copying the bit stream from the serial port to a remote location.