Ethernet/IP or DeviceNet

Good Morning ,

I have a question.I am getting ready to start a project.
This environment is going to be somewhat harsh ,alot of stone, dirt, dust ,and some vibration.I was thinking of using Flex I/O
at a couple of locations ,and to be installed in dustproof and
waterproof enclosures. What networking method should I use
Ethernet/IP or DeviceNet or what would you recommend.I am using
a CompactLogix Controller.I was thinking about Ethernet,any concerns.

Thanks in advance,

I have used both, with compact logix. My preferred is devicenet though it has a limit on the number of devices conected and the i/o map of the 1769-SDN is not the biggest.I have never use the flat cable, I prefer the thin round cable. If you location is noisy , then you have to install ferrite cores around every devicenet cable termination.

widelto

I would go with either Ethernet I/P or Controlnet. Unless you are real careful about cable Controlnet is probably a more durable media. CNet is also a scheduled network which requires you to at least touch the network setup to get it to work. However, the plc-side data setup of E-net IP and CNet are identical. They are also faster and, I feel, generally easier networks to implement than Devicenet.Keith

Unless you really need the DeviceNet protocol to interface another device, I would not use it.

Both ControlNet and EtherNetIP are better choices for remote racks in Control Logix.

I would use ControlNet. I have had the best results using it for remote racks. You can even opt for redundant media. Once you get it running it works period. I think the RG6 media is pretty tough too.

Ethernet works well too. I would highly recomend using a dedicated network with aproved switch for your I/O. Ethernet is by far the simplest to configure. There are a lot of rules that when followed make EtherNet IP really reliable. Read ALL the AB documentation BEFORE deciding.

I would not be afraid of good old RIO either. Yes it is old I know, and there are limitations with the 1756-DHRIO. It works well and I trust it. Like ControlNet once it is up and running it works period.

DeviceNet would be my last choice. Of all the AB networks available I have spent more time chasing my A** with DeviceNet than all the others put together. Yes, I know it is almost always cabling and improper terminations/installations. I don't care, it has proven in my experience to be the least reliable of all. I only use it when I need it to link with a device that only supports DeviceNet.

RSL

RSL said:

Ethernet works well too. I would highly recomend using a dedicated network with aproved switch for your I/O. Ethernet is by far the simplest to configure. There are a lot of rules that when followed make EtherNet IP really reliable. Read ALL the AB documentation BEFORE deciding.

Click to expand...

I cannot stress RSL's statement enough. DO NOT get cheap here or you will seriously regret it. You don't need the most expensive gear on the market, but use good industrial gear and spend the money for a switch, do not use a hub. I use N-Tron swithes.

Now as for device-net. I have used it on a number of occasions and I don't have any complaints about it. It is not that difficult to do. But you need to download and religously follow AB's device net installation guide. The only short cut you can take is on power taps and drop taps. Rather than buy ABs overpriced taps I set up a group of Red, Black, Blue, and White terminal blocks and route the DN cables through the group. Its a convenient way to tap in power as well as tap in drop lines using a star topology.

Don't overlook armor point IO.

If your go for Flex I/O on ethernet, I would recommend avoiding the 32-point modules. They quickly mount up to bandwidth hogs.

A group of 16-point modules (on one adapter) can be handled as one transaction, whereas each 32-point module requires its own separate transaction. If an adapter group contains one 32-point module (or an analogue module) then every module in the group has to have its own transaction.

Refer comm methods "rack optimized" and "none".

Gerry,

You can set an adaptor for rack optimized connection and have individual input data connections where needed. You can use the optimized connection to read data from discrete I/O, and use input data connections for the analogs and specialty cards.

You can have one or two analog or specialy modules in a rack using input data connections and read all the others with the optimized connection. Analogs usually don't require an RPI near as fast as discrete data does This helps with the bandwidth.

I would agree that the 32 point modules don't really appeal to me either. They take a special base and require an input data connection that will likely be at a fairly fast RPI.

I personaly have not had issues with bandwidth on Ethernet IP I/O, but my RPI's are usually 20ms or slower. The connection usage is however a concern for me.

RSL

Just a word of caution.. The 1794 Flex I/O Ethernet com modules had a problem meeting European noise standards. The fix was placing a 2" by 1" metal shield on the underside of the module that contacts the din rail. I experienced serious com problems when Powerflex drives were running on the same ethernet network. Removing the clip cured the problem. I understand that a redesign of these modules is scheduled for the future.

RSL said:

Gerry,

You can set an adaptor for rack optimized connection and have individual input data connections where needed. You can use the optimized connection to read data from discrete I/O, and use input data connections for the analogs and specialty cards.

You can have one or two analog or specialy modules in a rack using input data connections and read all the others with the optimized connection. Analogs usually don't require an RPI near as fast as discrete data does This helps with the bandwidth.

I would agree that the 32 point modules don't really appeal to me either. They take a special base and require an input data connection that will likely be at a fairly fast RPI.

I personaly have not had issues with bandwidth on Ethernet IP I/O, but my RPI's are usually 20ms or slower. The connection usage is however a concern for me.

RSL

Click to expand...

It's my understanding that if you set an adapter with 32-point modules to 'rack optimized' then you only get access to 16 points of the 32-point module.

Yes that would be true.

My point was that if you have only one 32point module and several 16 point modules you can use a rack optimized connection for all the other modules and only 1 direct connection.

You only need to establish an input/output data connection with that one card. You can do both. Then the rack would only cost you 2 connections not 8.

You can use a combination, you don't have to use input/output connections on all the modules just because one requires it.

Does that make any sense?

RSL

You can set an adaptor for rack optimized connection and have individual input data connections where needed. You can use the optimized connection to read data from discrete I/O, and use input data connections for the analogs and specialty cards.

Click to expand...

This is the bit that I didn't realise was possible. Has it always been that way? I'm sure I read somewhere that you had to set the adapter's comm format to 'none' if you had analogue or 32-point modules.

I read in the documentation that it can be done this way. I think I have a system here in the plant I configured using both com formats with a mix of analog/dicrete I/O in a rack. I just need to remember what it was.

I may be remembering this wrong? I will post again later after I look around here a little more,

RSL

Maybe someone else can chime in here?

Nope, I am at work now and found it. I do have a system running with several rack optimized connections which contain at least one analog or HSC card in the racks. Those cards are on Input Data connections or Data Connections. It is up and running right now with a solid green I/O LED on the controller. This system is using 1756-L5562, 1756-ENBT, and 1794-AENT's on version 15.?? firmware.

I researched a little more and jogged my memory a little. When I have had trouble in the past was using listen only connections in a mixed rack of analog and discrete. I believe I ended up having to use only direct Input/Ouput data connections with the owner controller and listen only Input/Output connections for the consumers. If I remember right, the owner controller cannot have a rack optimized connection to the rack if the consumer needs data from a specilty card in the same rack. The consumer can establish a listen only rack optimized connection, but I was unable to establish a listen only connection to a specific card in the rack. Again, it has been a while since I configured it. I may be off but I think that was the deal. This was an odd configuration that most systems don't require.

In general I think the producer consumer modeled I/O in CLX is incredibly flexible. It offers more flexibility than 99 out of 100 people would ever need. I prefer ControlNet to EtherNet for I/O and produced/consumed tags. I am warming up to the idea of doing more control on Ethernet though. Right now as a matter of policy we only use EtherNet for HMI's, and data collection (including remote analog and counter cards). All critical systems have local processors or are on ControlNet. Our plant is spread out and our control network is a VLAN sharing hardware with the office network. I just don't trust it that much.

RSL

use C-Net. I still personally do not think ethernet is suitable for an industrial environment. In an office its OK if an networked application hangs and you have to reboot your PC, but in the industrial world , a system reboot is unacceptable esspecially in a 24/7 environment.

D-NET is great in static environments such as MCCs , but in a harsh environment with lots of vibration or high humidity or high temps, I have seen nothing but grief with D-NET apps. Unfortunatly with D-Net if one node has a hadrware issue it can bring down the entire D-Net loop very similiar to the old style Christmas tree lights where if one fails, they all go off, and how do you find which one caused the problem ?