Devicenet

A

Thread Starter

Allan Dow

Good day to fellow listers,

The question for the day is "How far can you push DeviceNet"?

Its capacity is 63 nodes but is it like "older" networks that quote 64 nodes available but officially do not go over 25 and unofficially do not go over 16.

We are developing a process at the moment that is reasonable intensive in I/O and we are using the DeviceNet for the first time. Has anyone pushed
the network in a REAL environment?

Look forward to responses and thankyou you all in advance for your responses.

Cheers
Allan Dow
Embedded Systems & Solutions
 
M

Michel A. Levesque, ing.

We have used DeviceNet on many installations and you can push this network fairly hard.

The key is the amount of information coming from each node. Think about it, each node could potentially have a rack of I/O's behind it. We use AB products almost exclusively and one 1771-SDN scanner can have over 16000 I/O's on it's scan list (64 nodes X 8 cards per node X 16 points per card). This saturates any AB processor (except ControlLogix).

Typically, what you do is configure the information to come on a Change of State or Cyclic, this saves lots of bandwidth compared to polling.

The DeviceNet network is superbe on drives, starters, switches, etc. I would not use it on instrumentation (transducers). The amount of
real-time info coming from transducers is too much for a DNet.

As for the number of nodes to use, keep in mind that the network itself uses arbitration, thus the lowest numbered nodes have priority. You can
usually assign nodes that rarely change states at the higher numbers and the fast state change items on the lower numbers.

Other than this, your biggest problems are power balancing and connections. Most of the problems we run into are these two.

Hope this helps.

Michel A. Levesque eng., mcp
Directeur Bureau Montreal
AIA Inc.
[email protected]
 
C

C. Thomas Wiesen

There are a number of factors that affect the "True" number of nodes that can be practically used on a DeviceNet Network.

Some scanners (Masters) have memory limitations which may limit your node count. If your nodes consume 30 bytes of input and output (such as an HMI), you can eat up a whole AB SLC scanner with one node. Using multiple scanners on a common network can be done, but that can be tricky and problematic. If you run out of memory in the scanner, add another scanner and split your
network (I have had to do this). Some input devices only provide input data. Some input devices provide several status bits for each input bit, doubling or tripling the number of bits consumed by a single node. Some memory can be wasted since 8 bits is usually the minimum number of memory consumed by a single node. If your nodes only have a few bits per node, you can waste a lot of memory.

There are some tricks that can be done to minimize memory and network traffic as well. For instance, Eaton PanelMates on DeviceNet can be configured to pick up data from other nodes. This allows the HMI to get data directly from other components on the network and not have to consume extra Output on the Master for that data. I worked on a system that used multiple PanelMates on the same network and all but the first of the PanelMates "Listened" for the data going to the first one for all common display data. Common data viewed on all the PanelMates was sent out only once each network scan for all the displays.

The type of communication selected will affect the actual traffic on the network and will affect how many nodes you can practically have. If all the nodes have a high I/O count and are all Polled, there may be some significant slowdown. If all the nodes are Change of State, there could be very little traffic for a high node and/or I/O count.

Chosen network speed may affect operational speed. Some masters are slow in moving data from the network and will cause delays if the I/O count is too high. Some PC based Masters are very fast in moving the data in and out of the
card allowing the 500 KB rate to be beneficial. The AB SLC backplane is slow enough that increasing the network speed past 125 KB has limited performance improvement. Additionally, you may be required to keep the network speed at a
minimum due to distance requirements.

What it comes down to is the specific matchup of components on the network and how you configure the components. You can "Load" up the network with 62 nodes (leave node 62 for programming and node 63 for component replacements) and have
sufficient performance as long as you can use 500 KB speed effectively, use Change of State devices and/or use moderate to low I/O per node.

To optimize network performance for high I/O count, use nodes with 8 bytes of data per node. Try to group less active devices on common nodes and have them configured as Change of State.
 
M

Mike Schoonmaker

63 working nodes (+1 for the controller itself = 64) works perfectly fine for DeviceNet. We have 1 system that actually runs 98 nodes (56 on one
network, 42 on another) which are comprised primarily of VFD's and RFID tag read/write systems.

This sytem is for a check clearinghouse sortation system that processes in excess of $1,000,000,000 (that's right, over 1 BILLION dollars) of checks
each night in a 3-4 hour process. You can get application information on this installation at http://www.thinkndo.com/application/appstory.html

Regards,
Mike Schoonmaker
Think & Do Software, Inc.
http://www.thinkndo.com
 
S
Allan:
We have a network at one of our plants with 17 total nodes. 11 of those nodes have 1 1794-ADN, 1 1794-IB16, and 1 1794-OB16 per node. 1 node has a 1794-ADN, 2 1794-IB16, 1 1794-OB16, and a 1794-IE4 (analog input). The other 5 nodes are A/B 1305 AC drives. The total cable length is about 150 - 200 ft. We are running at 125 K Baud. I have all nodes set up as polled every
scan, with a 10 ms interscan delay. This configuration uses 27 of the usable discrete input data words, and 22 of the usable discrete output words. I mapped the ADN's to the M1 file.

We have had really good luck with this network.

We did have some speed problems on a single turn clutch which required a pulse to be less that 25 ms. I also tried to set the AC Drive to be polled
with a background/foreground ratio, so they weren't scanned everytime, but this didn't seem to work. The 1203-GK5's we are using would fault
intermittently.

The best I can tell, our network is refreshing the PLC about every 30 ms or so.

Hope this helps.

Scott Brown
Gemtron Corporation
 
If you are running into performance, traffic or number of node problems you may want to reseach shared memory technology. It can handle hundreds of nodes, it is real time in the nano second per node range and can pass data at 16 MBytes/sec. If you are willing to try something new there are a couple of suppliers of it, one being a product called SCRAMNet by Systran Corp, www.systran.com

They have PMC cards for embedded applications

WjO
 
Top