Just looking for an opinion. Here is what I have:

AB 1769-SDN

- Scanner is Master for 17 nodes using a byte of I/O each mapped in as polled. Each has photoeyes, proxes, solenoids, and pb's connected. Nothing high speed reliant.
- Scanner is a slave to a robot with 64 bytes of I/O mapped in as polled.

The robot must be Polled but what about the I/O modules? A co-worker (my boss..... ) mapped all of the I/O modules in as polled and swears by it.

The issue I am having is that the robot is giving me dnet errors occasionally, like the network is too slow or something. Everything I have ever been taught and used with devicenet is this. Change of State for all I/O except for maybe a high speed counter or something. Something that could potentially communicate larger changes in I/O, like the robot when I give it a part number of 2012 for example in binary.

Larger networks that are polled are slow correct? Any suggestions are appreciated. Thanks!!

IMHO, polled will be slower and use more bandwidth.
With the polled setup, every point is examined every poll. With COS, the device says "here's what changed, and here's the values",.

I only used polled with older devices that do not support the COS configuration.

I agree with Ken, but you network doesn't seem overly complex or a high user of bandwidth. It doesn't seem that it would make whether you used polled or COS messaging. Have you taken a good look at your physical media?

COS might actually make this specific system worse if you're not careful.

I've had GE Fanuc robots with SST DeviceNet plugs give us "bandwidth" errors, which we think might have been due to the 1734D POINTBlock I/O being set for COS with no filtering, and the photoeyes being interrupted by a stream of water, which would cause floods of COS transmissions.

I put in a COS transmission delay of 100 milliseconds and didn't get the robot errors anymore.

The simplest thing you could do is increase the Inter-Scan Delay, allowing more time for the robot's 64-byte poll to be responded to by the 1769-SDN.

Alternately, you could put some of your Polled devices into the Background poll list, or set them up for COS with filtering or production delay, or set them for Periodic with a medium rate of 50 or 100 milliseconds.

It can go either way. If the rate of change is not very often, then COS has a lower bandwidth (lower load on the network), and latency (reaction rates) are much higher. If it is much more frequent, COS can overload things. If it's polled, just the opposite applies. There is a constant bandwidth used by each device regardless of whether there's an update or not.

The same arguments apply between Controlnet and Ethernet/IP.

Frankly, it depends on application. If I'm dealing with an operator push button station then COS is ideal from the point of view of very low bandwidth usage. If it's say a thermocouple, then you can use polling and set the RPI (polling rate) extremely low, say once per second. For anything else, use similar judgement calls when deciding which to use. If reaction rates are important (for example, a proximity sensor detecting presence of a part), then COS is probably the better choice.

Be prepared for the possibility that that optimizing your network won't completely solve your problem. DN, like all networks, has a bandwidth limitation, and when you can't overcome that limitation you have to separate your DN network into two networks.

It was 1994 when I attended an ODVA Devicenet 3 Day school for Devicenet Equipment designers. What I learned there may shed some light into the COS vs polled debate.

Each and every devicenet device works off the same "clock".
The amount of time is divided into "windows" and one packet of data can be transmitted in each packet.
If two devices try to use the same window the lower node device wins.
This is why Devicenet Scanners want to be node 1 for most efficient operation.
In polled mode nobody but the scanner has data to send until the scanner asks for data and then only the polled node has data to respond, because the scanner keeps quiet until it gets its response or times out.

In COS Mode it is quite possilbe that two or more nodes will have data to send in the same window. Hence the higher node devices must wait for the lower nodes to send their data.

So as you can see a "jittery" device at node 2 or 3 can keep a device at node 32 from delivering it's update in a timely fashion.

The optimal network will use a mix of polling, COS and wise assignment of node numbers.

Well after some head scratching, deep thought, and all of your thoughts, this is where I am at.

Everything is Polled still and scanned in the foreground, as it always was.

Increased interscan delay from 10ms to 20ms. No devicenet problems in 5 days!!!

Thanks again.




That is a great explanation. Why couldn't my AB Engineering rep explain it that way.......