Sign in to follow this  
Followers 0
Chris Elston

Device net = polled, change of state, cyclic?

3 posts in this topic

I am getting ready to write some new code for a device net project I've got going. Here is what I got: AB Device NET Scanner Numatics 2002/2004 series Com Modules (5 NODES) with about 100 I/O each. Numatics says that they support all configuration of device net. In the past, I've only used POLLED. I've come to wonder if CHANGE OF STATE is better, seems like it would not tie up the network traffic so much. Has anyone got any words of wizdom configuring my device net for CHANGE OF STATE vs POLLED, like I always have before? In past, most device net capable devices that I have used, for example some SMC valve stacks, ONLY support POLLED, so I was forced to use POLLED configuration. Using Numatics 2002/2004 series com modules opens up a new door to try CHANGE OF STATE configuration. My device net system is running a digital I/O layout with a bunch of air driven valves for automation. Just mainly watching for an input, then turn on an output. Thanks for your comments regarding CHANGE OF STATE vs POLLED.

Share this post


Link to post
Share on other sites
Change-Of-State can really open up your DeviceNet bandwidth, though on a 5-node system the variation might not be that noticeable.   I typically use it on 30 or 40 node MCCs. The #1 "gotcha" in a COS setup is the trigger mechanism used by the slave device, especially with analog values.   For example, you could have an analog value (like the frequency feedback from an AC drive, for example) that changes just by one or two of the least significant bits in a word, but does so often. If the COS trigger is "any change at all", such a node can fill up the network with a message every time the feedback changes by 1 part in 32767. Most well-designed devices give you one of three ways around this: 1.   Time filters.   The COS message production gets delayed by X milliseconds every time there is a change, to keep the node from filling up the network with messages.  This is also handy on discrete I/O where two inputs might come on very close to each other in time. 2.  Value filters on specific elements of the data.   This helps filter out the small changes in analog values.   A-B drives use this, for example, allowing you a "COS Fdbk Change" parameter so you can dampen the effect of the feedback changing by small amounts, as well as a "COS Status Mask" to change what discrete bits of the drive Status word cause a COS production. 3.   Non-IO triggers.   Some devices use events that aren't necessarily in the I/O data to trigger a COS data production.  Allen-Bradley E3 overload relays are like that;  you select Inputs, Outputs, or Warning, Trip, or Current Feedback bits to trigger a COS data production.  Usually these things are part of the I/O image, but not necessarily. Your application is entirely discrete I/O, so COS connections will probably give you what you expect;  a message produced by the valve manifold only when an input point changes state, and a message produced by the Scanner module only when an output bit changes state.   Unless you're running a pulse train into your inputs, this should result in better overall network throughput. One more thing;  it takes a scanner module longer to declare a node offline when you're using COS or Cyclic messaging.   The timeout is in fact 4x the heartbeat time.  By default, the COS heartbeat is 250 milliseconds, so if a slave device goes off the bus, it will be a full second before the scanner module knows about it.   Not a big deal in some instances, but important in others.

Share this post


Link to post
Share on other sites
Thanks for the detailed reply Ken. I don't have an analog or "Trigger" events on device net, so I am going to give it a run for the money. I understand what you mean about 5 nodes not amounting to much traffic. And 1 sec to know that we lost the heart beat on a slave device is not that critical on this project, but valuable information and pointers should I require to have a slave device that can't stand 1 sec of comms loss from the scanner. Again thanks for your "AB" insight and wisdom.

Share this post


Link to post
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!


Register a new account

Sign in

Already have an account? Sign in here.


Sign In Now
Sign in to follow this  
Followers 0