I have recently heard a story that a colleague of mine is using Ethernet for HMI's, Devicenet for drives and ControlNet for remote IO. My thoughts were to extend the DeviceNet to cover the IO as well. Is there a reason for using ControlNet to interface to the IO instead of DeviceNet? I thought ControlNet was a rival of Ethernet, now I am confused!
The problem as I see it with the AB networking story overall is that there's overlap between the three elements, and none is entirely free from problems.
DeviceNet is low cost, and hence attractive to third party vendors as a way onto the AB backplane, but lacks the bandwidth for fast I/O operations, particularly when the node count starts racking up.
ControlNet is a good medium level network, but not massively well supported outside AB - the last time I looked, the chipset was very expensive.
AB's Ethernet route is going to be expensive for remote I/O, particularly given the requirement of the ControlNet on Ethernet stack for nodes running a capable and resource hungry VXWorks style real time executive. And of course the de facto Ethernet standardisation is running away from AB into Modbus on TCP/IP (to the evident glee of Modicon, who, having nailed their colours firmly and stubbornly onto one of the fieldbus non-starters, i.e. Modbus Plus, now find themselves owning the most likely contender to dominate on Ethernet!).
Personally, I wouldn't look further than Profibus DP to link PLC's to drives and remote I/O - you can do this easily with the excellent SST module for AB PLCs - with HMI on Ethernet. But AB will never ever admit that this is a sensible approach, so you're locked into to either supporting three different networks, or trying to pick one of DeviceNet or ControlNet so that it can be bent to fit.
(All views personal, as usual)
Tim Linnell (Eurotherm)
That's about my take on the situation as well. I have used and am very impressed with the ease of use and performance of Profibus DP. I did a couple of recent jobs where the customer's management decided on DeviceNet against my recommendation for Profibus. I am now fairly familiar with all the pitfalls, and can do DeviceNet fairly well, but I feel it has more learning curve than it really needs to. Insofar
as any of us have anything like a "standard", I concur with your recommendation for Profibus (using the SST cards) as a remote I/O bus, and ethernet for HMI's. DeviceNet is best when used for isolated sensors and actuators spread evenly over a large area, as it has the sensor power built in (and length limitations make it not even especially good for that).
The Ethernet is a natural for the HMI's. Once the data is in the PC's and available on the network, it can be used by other HMI's, data historians, and many other systems.
The Devicenet on the drives is OK if the drive does not have Controlnet capability. The Devicenet takes a little longer to set-up, is slower, and does not have as much bandwidth as Controlnet.
Controlnet is an excellent network for interfacing to drives, between remote racks, and to I/O. Controlnet has the advantage of being deterministic over ethernet. This basically means that communication packets are verified before action is taken. Controlnet has an advantage over Devicenet in speed and the amount of data that can be passed. For simple I/O, Controlnet may be overkill.
The newer AB PLCs use the CIP (Control and Information Protocol) as the top three layers (ISO) of Ethernet/IP, ControlNet, DeviceNet and the backplane comms. This gives seemless bridging between the networks which I see as a distinct advantage to the ABs.
Ethernet/IP (CIP over TCP/IP) and ControlNet(CIP over ControlNet, excuse my recursion) are not so much rivals, but the same protocol over different media.
Rockwell's line on this is Ethernet for high through non-deterministic comms (HMI), ControlNet for solid middle thoughput deterministic comms (IO), and DeviceNet for wider distributed IO comms. You use any of the three for any purpose you want, that's an engineering decision (flexible is good).
I haven't yet used ethernet for IO, yet. I do use dual redundant ethernet rings(ie. two seperate networks, two ethernet cards per device) for HMI-PLC comms, and PLC-PLC comms on every decent sized system if the client let's me. I am tempted to used a mixed system with ethernet between subs and ControlNet within subs on the next big greenfields site.
I would not use profibus in an AB unless I had to talk to a device that could not support native AB protocol. AB IO through ControlNet works and fits in well with their CPU's.
We have been very sccessful with Controlnet used with Flex i/o and Panelviews but have found it to be rather slow connecting to drives. Also watch out for the maximum number of devices. You may need to adjust scan times and even add another card.
Is Rockwell EtherNet DLR a deterministic Network?
>The newer AB PLCs use the CIP (Control and Information
>Protocol) as the top three layers (ISO) of Ethernet/IP,
>ControlNet, DeviceNet and the backplane comms. This gives
>seemless bridging between the networks which I see as a
>distinct advantage to the ABs.
---- sniped by moderator ---- read the entire post above.
>Is Rockwell EtherNet DLR a deterministic Network?
Long story short, it's not technically deterministic, but it is suitable for real-time control applications, with some caveats. I've run quite a few servo drives on one ring. I've got a system running 50+ VFDs on a ring. The 50+ drives I had to slow down my RPI to 100ms, and it doesn't have any CIP Motion, but it works reliably. 50+ nodes is above the recommended limit, and you don't want to put IP cameras on the same ring as your servos. Still, it's a decent system.
Sage Automation, Inc.