Sign in to follow this  
Followers 0
Rod_Hackney

Contronet and Devicenet Tools

8 posts in this topic

I wanted to see what Allen Bradley and/or 3rd party tools my distinguished PLC colleagues are using on their Devicenet and Controlnet networks for troubleshooting. All comments are appreciated

Share this post


Link to post
Share on other sites
Knowing the limits of ControlNet is a problem I see alot of from many users. What are the limits on controlnet? Here are some below when I run a schedule on controlnet what do I look for in the config? Some of the parameters are debatable, but its a target and people throw darts. I have a scanning procedure too, but these are things to look for not a procedure. Prescan Setup of ControlNet 1 Just INFO! What is the peak scheduled usage  in ControlNet? What is the range of usage percent which can be considered as "correct" for a ControlNet network? The range that is considered correct is 0-100%. As a rule of thumb, if peak is > 80%, network traffic is considered heavy but should not pose any problems for the scheduled communications. Unscheduled communications will suffer as there may not be sufficient bandwidth available to accommodate more than one unscheduled node from transmitting per NUI.  At least 1 unscheduled node is allowed to transmit per NUI. 2 Analog Cards set to 40mSec with the ControlNet Rack Card set to 20mSec 3 Example settings: If NUT = 5mSec, then ControlNet Head Card set to 10mSec all other cards are 20mSec RPI 4 Example settings: If NUT = 3mSec, then ControlNet Head Card set to 6mSec all other cards are 12mSec RPI 5 ON the (1756-CNB THIS DOES NOT WORK ON THIS CARD BUT MUST WORK ON OTHER TYPES OF CARDS) General tab with the Comm Format = Rack Optimization, set the Chassis Size = the amount of cards configured underneath the CNB card 6 If the Network BandWidth is exceeded by 100%, then give the CNET SQUIRREL more NUTs between RPI setting 7 Try to configure all CNB and IO modules in rack optimize mode, this ensures that all the IO is sent back in one packet. 8 If using Diagnostic modules or card setup for INPUT data these add to the connections but these have to have a separate RPI setting than the CNB 9 Configure all CNB modules with the correct RPI where sampling will give you 2x the program scan. 10 Remote Racks with Input modules: Do you need the COS (change of state) to be checked? This being checked creates unscheduled packets and goes against the Unscheduled Bytes Per Second parameter. UNCHECK always if not using COS!!! 11 At this point all remote ControlNet 1756-CNB set to Comm Format=Rack Optimize, individual Diagnostic cards, individual cards set to Comm Format=Input should have an RPI setting configured in the module properties before running the ControlNet Offline configuration. 12 Also the entire ControlNet configuration should match either the IO list or the electrical prints. 17 Results should show the following maximum percentages Unscheduled Bytes Per Sec: No less than 100k, should be around 400k Ave Scheduled Band: <80% Peak Scheduled Band: <80% Connection Memory Usage: ?% Peak Scheduled Usage: <85% <<< double click on CNB then look at the CNB in local rack on ControlNet Tab Double click on Sorter Processor, go to Device Usages, make a note of how many Connections = ? 18 General Facts on hardware used or there maximum connections Remember total connections for the processor can not exceed 250 connections. Debate on connections versus system overhead timeslice needs to be looked at closer if connections are closer to the maximum. As the connections reach the maximum the processor might have CIP connection faults depending on how many uncached connections are communicating on the processor. Remember that the PLC can only have 3 uncached connections 1756-CNB connections can not exceed 64 connections 1756-CN2 connections can not exceed 128 connections Double check results by using the Logic5000 Task Monitor Tool by downloading the plc processor and check the connections.

Share this post


Link to post
Share on other sites
RSNetWorx for ControlNet and/or DeviceNet with the Diagnostics add-on is probably all you will ever need (for AB systems). Of course experience helps a lot as well, since errors are not always as they seem.

Share this post


Link to post
Share on other sites
I have a ControlNet/DeviceNet toolbox that is pretty well equipped: 1784-PCD 1784-PCC A-B ControlNet Traffic Analyzer utility A-B DeviceNet Traffic Analyzer utility Woodhead DeviceNet NetMeter A-B 1788-CNCHKR ControlNet signal checker Cleverscope USB oscilloscope The item I use the most is the Woodhead DeviceNet NetMeter. It does what I really need to prove the physical installation of a DeviceNet; low-level signal quality readings, min/max captures, and statistics on traffic and errors. I use the oscilloscope mostly to provide pretty pictures to compare "before" and "after" when I do media and shielding remediation. Sometimes the difference is dramatic, sometimes less so. The 1788-MCHKR media checker is only good for doing bulk installations of CNet and DNet media, not doing troubleshooting. Most people don't realize you need to calibrate it to a spool of co-ax if you're going get accurate TDR length readings. In the near future I'm going to trade up to the modern USB/CNet and /DNet adapters and the FTE NetDecoder software suite, especially if I end up with a laptop that lacks a PCMCIA port or an operating system (Windows 7, probably) that won't support the 1784-PCD/PCC.

Share this post


Link to post
Share on other sites
Is there any performance difference between the PCD and KFD? Is there any advantage of 1 over the other? I have a 4 slot chassis with an ENBT, DH/RIO, CNB, and DNB could this be a replacement for all of the other adapters?

Share this post


Link to post
Share on other sites
The 1784-PCD is 4 to 8 times faster than the 1770-KFD, in my experience. It also is the only card that supports the A-B DeviceNet Traffic Analyzer. Ordinary bridge cards can tell you about their own interfaces with the network, but the generally can't diagnose issues with other nodes or the network overall. The 1756-DNB Series C has some network monitoring objects that you can get to with CIP Generic Messaging. These are handy, especially for exclusion purposes, but are not nearly as useful as the DeviceNet NetMeter. Woodhead has a new Ethernet-connected version of the DeviceNet NetMeter that you can permanently install in a network and monitor remotely.

Share this post


Link to post
Share on other sites
Ken If you where to buy networking tools out of your pocket what would you buy? I am a novice in the networking diagnostic world but hope to be getting into it more and more. I ASSuME that the USB/Dnet adapter will support the A-B DeviceNet Traffic Analyzer is that correct? I think I need more new toys/tools

Share this post


Link to post
Share on other sites
There's always an investment required to tool up for serious network troubleshooting, which is why it's sometimes more practical to leave it to the experts. This is true of all industrial networks; you would need just as expensive a set of tools to troubleshoot Profibus or Interbus-S. If I had to buy just one of these tools out of my own pocket, I'd get the Woodhead DeviceNet NetMeter. If you have more than a hundred DeviceNet nodes in your facility, you need one of those tools to keep from falling into the trap of maintenance guys blaming the network for every blown fuse or snapped belt. If I had a dollar for every time I've heard the network blamed for loss of communications to a drive that was actually powered off...... well, I could pay for a NetMeter. Since we're talking strictly about DNet/CNet troubleshooting here, my oscilloscope is the second most useful device. This is principally because it helps me generate pretty pictures of the DeviceNet waveform, which go into the service reports that get submitted to the maintenance managers who pay my invoices. While the DNet NetMeter does the real CAN-level troubleshooting, the managers remember the impressive graphics in the service report. In fact, I personally purchased my CleverScope during a budget freeze. I've used the CNet Signal Checker for serious noise remediation work maybe a half-dozen times. More often, I use it to verify that I have good signal, then proceed to do the wiggle test on all the connectors. Useful and easy, but most really bad connectors will indicate their condition by pulling apart in your hands. If I had to give up my in-depth ControlNet troubleshooting to somebody else, I wouldn't go hungry. The 1784-PCC and 1784-PCD work with the A-B protocol analyzer, and you just don't need them unless you're a hardcore A-B network guy. I've used the analyzers for product development and compatibility work, but because they only work on the data that passes up through the interface successfully, they are of little use for analyzing noise, signal, or media issues. The A-B traffic analyzer software will work only with the 1784-PCC and 1784-PCD (and the PCI-bus versions, even less common). The 1784-U2DN and -U2CN are the "next generation" DeviceNet and ControlNet analyzers. The existing A-B traffic analyzer (9220-WINTA) will become an antique and these modules will be used with RSLinx Classic and with the Frontline Test Equipment NetDecoder. NetDecoder isn't for casual users or occasional troubleshooting. It is a full-blown, high-power, feature-rich main battle tank of network analyzing goodness. If I wasn't a professional control systems engineer specializing in Rockwell Automation networks, I wouldn't need or want it.

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