DeviceNet reality test

I am looking at a project that, for the first time in 12 years,
looks like a decent DeviceNet application. My inexperience with
any use of DeviceNet leads me to this question, in this forum.
(I fear that those who sell these devices are quick to say "Sure"
to questions of interoperability, without having to sweat the
bullets to actually make anything work.)

So, the details:

Processor: AB SLC 5/05, ethernet

Scanner: 1747-SDN

The Network: Allen Bradley Bulletin 160 drives, fitted with the
DeviceNet pod on the front. All within 100 feet of the scanner.

The Size: 48 is the quantity

The function: start and stop these drives using DeviceNet. Set the
operating frequency via DeviceNet. No drive configuration or
data collection.

Concern:
Will a single DeviceNet network handle this, from the standpoint
of shear data throughput, or should I have two networks and two
scanners?

Thanks, in advance.

(Of course, the best response would be from a peer who has actually
performed this trick.)

Background: Years ago I attached 31 Honeywell temperature
controllers to an RS485 loop, and needed to collect data and send
setpoints via the PLC serial port. Long story short, it took over
90 seconds to update all the controllers. Not a pretty sight.
Some of this falls to Honeywell's unusual data exhchange protocal
(hello - HELLO - i'm here - I'M HERE - here's data - I SEE DATA - use data)

How fast do you want the data to be exchanged ? 20 milliseconds ? 50 ?

Generally I don't run a DeviceNet network past 32 nodes, because I'm very conservative about performance. Most of the motor control centers I've commissioned are between 20 and 30 nodes.

The main thing to be conservative about is I/O memory in the SLC. The 1747-SDN provides 31 words of Input and 31 words of Output data, and 150 words each in the M0 and M1 "module files" where DeviceNet data can also be mapped.

Usually I use an "Advanced Map" entry to put the start/stop/status data into Discrete I/O memory, then put the Control/Reference data into the M0 and M1 file memory for periodic access via COP instruction in the SLC.

That method wouldn't work for all 48 drives, as you would run out of I/O words. You might be able to use Advanced Mapping to just put the Start/Stop bits into the I/O table and everything else in the M0/M1 file, but I don't recommend getting that fancy.

I have not put this many Bulletin 160's on a single SLC scanner, but I've put 42 E3 starters and 1336+ drives on a single PLC-5 scanner. The scan time for the network was outrunning the PLC-5 (50 ms scantime average) so I didn't measure the throughput.

The 160-DN2 adapter does support Change-Of-State messaging, so you can cut the average response time of the drives way down, but you should have an idea of what your worst-case required response time is before you decide how many network segments to install.

I use my DeviceNet protocol analyzer to get benchmark scantime values for many of my networks... if you're interested I could dig up some example networks and publish the results.

Depends on the number of i/o, shear amount of data, on the network(how your scanner data table will be configured).

The distance is no problem.

I did a similar app for digital inputs only. Here are the stats

448 inputs per scanner(I have the scanner sized at 14, 32-bit arrays)

There are 28 16-input remote i/o on each scanner.

I have not seen any hiccups. My guess is that with the amount of data you'11 be moving and the short distance one scanner would do.

Here's an example network:

1771-SDN Channel B scanning at 500 kb/s, Polled I/O connections only.
(15) 1336 Plus II drives with 1203-GU6 (4 bytes in/ 4 bytes out)
(5) 193-E3+ Overload relays (8 bytes in / 1 byte out)

Because the data size of the 1336+ AC drive is identical to the default data size for a Bulletin 160 drive, we'll use them as the example.

Typical Poll-to-Response time was about 0.6 milliseconds. Total time for output data and input data to be exchanged between the Scanner and fifteen drives was 16.4 milliseconds.

If we extrapolate from the 15 drives to 48 drives, we get 52.5 milliseconds to scan all the Bulletin 160 drives. With a typical 10 millisecond Interscan Delay (that's the dead time between Poll functions to let other messages occur) you're looking at roughly 60 milliseconds to scan all 48 of your drives.

Again, just for simplicity of memory mapping I do recommend two DeviceNet segments, each with its own scanner and power supply. That will make it easiest to implement this system and give you very good performance, especially if you configure the drives for Change-Of-State instead of Polled I/O.

thanks to all

Actually, the system layout is sort of a textbook marketing
diagram for Allen Bradley.

The master is a SLC 5/05, with an ethernet link to a HMI.

Its serial port will be ported to a DH485, and two other SLCs.
(One of the SLC's will have a DH+ link to a HMI, one of the other
SLC's will have a serial link to a RFID tag reader, so I've got
DH+ and serial RS232 covered as well!)

In the main chassis will be two (based on this thread) DN masters,
and two -SN RIO masters.

The SN modules will be talking to a total of 67 slots in 7 chassis.

As to the question of response, since I'm exchanging DeviceNet for
Remote I/O, the generic response would be 'no worse than RIO'.

The replies helped to solidify what I already suspected: I'm using
two DeviceNet scanners.

And, before someone suggests that I use a Logix product, kindly
aim your suggestions to Rockwell's marketing department. The end
user is sold on the SLC product line.