In a comparison table of the performance of various buses, the performance for DeviceNet was reported to be 2 ms for 2,048 I/O. Are there some limiting parameters (such as bus speed, number of nodes, bus length) on which this is based?
Answered by Matt Kuzel, Physical Layer SIG Chairperson,
A111) DeviceNet, being designed specifically for device-layer communications, has been optimized at providing high-speed communication while offering configuration, monitoring and diagnostic capability to low-level devices. Using the Producer-Consumer model for communication, DeviceNet effectively allows the user to program and monitor devices over the network without impacting device I/O performance and other time-critical events on the network. Allen-Bradley^s Universal Remote I/O network is a high speed, control-layer I/O network that allows devices to rapidly exchange data with a single network master. The devices connected to Remote I/O typically exchange much larger amounts of data than required by device-layer applications. Remote I/O, being master/slave, does not support the messaging (e.g. configuration, monitoring and diagnostics) that DeviceNet offers, yet is optimized for high speed, deterministic communication between racks of I/O, drives, motion control, HMI, etc. For an application that will use a device like an AC drive, the choice in network between Remote I/O and DeviceNet is dependent on both the application and drive requirements. If the drive will require high-speed I/O exchange with a single master without the need for remote configuration or monitoring, Remote I/O would be appropriate. If the drive will require heavy parameter uploads/downloads and if the drive will interact with other large amounts of I/O (e.g. Motion control, HMI, etc.) Remote I/O would be appropriate. If the drive requires a network capable of moving large amounts of data rapidly without the additional functionality Producer-Consumer offers, Remote I/O would be appropriate. For a drive application that will require remote configuration upload/download, monitoring and diagnostic capability while still allowing high-speed I/O, DeviceNet would be appropriate. If multiple controllers are required on the same network or if the drive needs to only have a few parameters updated occasionally, DeviceNet would be appropriate. If application requires the drive to produce data at a defined rate or report by exception (e.g. Cyclic and Change-of-State data production), DeviceNet would be appropriate. Also, if the drive(s) are to be remotely located, potentially close to other field devices such as sensors and valves, DeviceNet may be an optimal solution because those devices too can be connected directly to achieve wiring savings. Other factors to consider - overall distance of the network; number of devices to be connected; rack space or I/O image space available in the PLC. Many of the reasons for choosing one network over the other can be categorized into functional differences between the networks. Ultimately, the right network to choose is the network that best meets your application^s requirements, compliments the other devices connected to your system and offers flexibility and room for future growth and expansion.