Sign in to follow this  
Followers 0
speakerman

Ethernet I/P over ControlNet?

6 posts in this topic

Hey everyone; Trying to set up an Ethernet I/P connection to an Omron PLC here, and everything looks ready, but the ENBT card is in drop 3 of the PLC, not the CPU drop. When I create the new generic ethernet module, it automatically sets it to "scheduled connection over control net" and greys out the selection so I can't turn it off, then gives the error "no scheduled connection over control net". I don't want to mess with the control net configuration, everything works just fine the way it is. We are passing 50 tags one way, as an input-only connection, and there are also 10 VFDs on the Ethernet card already passing 1 tag each, so there's plenty of room on the Ethernet card. Funny, but when I made the generic ethernet modules for the drives it didn't force me to use scheduled connections over control net. It would appear that if we don't want to change the control net configuration we'll have to connect the Omron to a new Ethernet card in drop 1, so there's no data passing over control net. This would mean pulling some more Ethernet cables between the two drops, not a big deal but in winter the cable conduits beneath the ground are usually frozen solid. Does anyone know if that's the case, or if there's another way to do this? The CPU is 1756-L62 revision 17.4 and the card is an ENBT/A revision 4.3, the Onrom is a CJ2M Ethernet PLC, and its comm is set up. Thanks for any input on this topic. Happy programming, speakerman.

Share this post


Link to post
Share on other sites
Could you clarify the "drop 3 of the PLC" statement? Is the ENBT bridge located within the CLX Local Chassis or it belongs to a ControlNet Remote Rack?

Share this post


Link to post
Share on other sites
Sorry dmargineau, yes, there are 6 control net racks. The CPU is in rack 1, and the ENBT card is in rack 3.

Share this post


Link to post
Share on other sites
I have yet to "connect" an Omron CPU to an Logix EtherNet/IP network, however, I believe that the only way you could get away without rescheduling a CNet network "passing-through" EtherNet/IP data is when you are just "listening" to Input Only devices, such as the EtherNet/IP VFDs. Since the Omron CPU's Generic Module is a "peer" of the 1756-L62 processor, the required connection will be "implicit"(produce/consume) and, since it will have to "hop" on the ControlNet network, the latter will have to be re-scheduled in order to accomodate the newly introduced data buffer. The existing, ControlNet Keeper enforced NUT (Network Update Time) will most likely need to be slightly increased by the RSL5K (RSNetWorx for ControlNet) Scheduling Tool. If you are unfamiliar with ControlNet scheduling you should get help; it is a pretty simple and fast process, however, it needs to be precisely executed. I don't see any other way to accomplish this task short of installing another EtherNet/IP bridge within the CLX's Local Chassis and patching it within the Omron's CPU subnet. Edited by dmargineau

Share this post


Link to post
Share on other sites
Take a step back: I think you've entered a gray area of functionality here. In the ControlLogix ControlNet and EtherNet/IP architecture, I/O connections can have only one network link between the device and the CPU. Unfortunately, RSLogix 5000 allows you to configure and attempt to run unsupported connections like this one. It's distressingly common to see ControlNet-based systems (redundant or otherwise) which users have attempted to expand by adding an Ethernet module to a remote 1756 chassis. In my experience, the most common reason given is "it's a long way to run cable". The worst part is that sometimes these connections work. I can't tell you exactly which buffers they're using, or what conditions on the ControlNet or the CPU will cause them to fail, but they can and will fail. I tried my best to get RA to describe or quantify these circumstances, but the problem is that if you establish guidelines for an unsupported feature, you're de-facto supporting it and are obligated to keep it working throughout any future versions. I've been through this argument before: "but the first set of drives work, why won't the new ones ?". My weak reply was always "the first ones shouldn't." And then we get into an argument about why the RA network architecture diagrams do not include examples of unsupported architectures. The practical answer is that this shouldn't work and you should make plans to put the Ethernet card in the chassis with the CPU.

Share this post


Link to post
Share on other sites
Thanks Ken; I had a feeling. Allen Bradley is not my strongest PLC type, so I'm still a newbie in many ways. Believe it or not, whoever designed this system configured it with an ENBT card in every one of the control net remote racks. There was only one installed, in rack 3, so we used it for the tiny drive network. I did read a technote saying it was unwise to do a lot through control net, as you will drive up the update times. I considered this when looking at how to install the VFDs, but they are only exchanging a total of 20 words between them, so I wasn't concerned it would pull the system down. The AB KB didn't say anything about not doing it, just about not overloading control net. This new Omron PLC system was set up sending way more words than we need, in a password protected code structure we cannot change, so I was already thinking I didn't want it on control net regardless. As it turns out we have a spare fibre connection to the PLC rack available near our control room touch screen, which has it's own 5-port switch, so I can just patch it to the card from there. We will look long-term towards moving the existing card to the CPU rack. It is a ten-slot, with only the CPU, EN2T, and CNet cards in it. The EN2T is for the HMI connection, so I wouldn't put anything else on that, but we have seven spare slots to play with. We've ordered a new ENBT card and will install it as recommended. Thanks for confirming my suspicions, and I'll avoid ever doing it this way in the future. I didn't know all this when we did the VFDs, or I'd have asked them to move the existing ENBT card to the CPU rack at that time. Good thing it worked! (even though it shouldn't...) Happy programming, speakerman.

Share this post


Link to post
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!


Register a new account

Sign in

Already have an account? Sign in here.


Sign In Now
Sign in to follow this  
Followers 0