Futuretech: Troubleshooting industrial network communications
An industrial end user usually decides to implement a networked automation solution because of the promise of increased efficiency and productivity. An open system offers the added benefits of interop...
September 1, 2001 | By Donald Bildfell and Andrew Carrothers
An industrial end user usually decides to implement a networked automation solution because of the promise of increased efficiency and productivity. An open system offers the added benefits of interoperability and interconnectivity. The ultimate motivation is the desire to generate greater profits. However, the ease of implementation and ongoing maintenance does not always meet the expectations of the user.
Typically, the decision to install a DeviceNet system is made by a senior member of the engineering department, and not by the maintenance staff. Problems arise when the system arrives on site; the maintenance staff has a tacit expectation that the network will work, and if it does not, then it is the responsibility of someone else.
Maintenance staff need to gain basic troubleshooting skills, and be given an understanding how the network operates. Network failures result in downtime, and generally the system integrator and manufacturer representative will not be on site to fix the problem. The cost of training maintenance staff is a small investment to avoid large lost profits that result from downtime. The following advice points to problems that can be encountered by the maintenance team and provides basic solutions.
f you have experienced communications problems with your DeviceNet network, there is a good chance you have experienced “noise” on the system and most often the culprit is wiring related. The ODVA (Open DeviceNet Vendors Association) estimates 90% of DeviceNet errors are caused by wiring and noise problem.
When a control process stops, it shuts down a line and causes production loss, resulting in costs of thousands, or possibly millions, of dollars. It is imperative for a successful manufacturer to quickly and efficiently troubleshoot a control process and return the line to production.
Troubleshooting is the process of systematically analyzing the performance of a system to detect or isolate a problem (hardware or software related) to a specific component or area. Many times when a problem develops within a system, the majority of downtime is related to finding problems. The actual repair of components or system software is the last step in the troubleshooting process and usually takes the least amount of time. A good troubleshooting process minimizes the time to repair or correct the problem and return the system to its normal operating condition.
Device level control problems range from a loss of power, to a device failure, to an entire network shutdown. In the vast majority of cases, device failure is the cause of the problem; in such cases, the user can rapidly correct the situation. Occasionally, the cabling, controller, or software may be the root cause. In these cases, an easy, reliable troubleshooting procedure will save a significant amount of time and effort in restoring the system. This, in turn, will save money.
Standard troubleshooting practices
When the system experiences errors, use common sense. If the system fails with no indication of the source of the problem, there are some easy, time-saving troubleshooting methods for quickly identifying the failed unit:
1. Start with the power side and verify that everything is energized, including devices with alternate power supplies. The DeviceNet Network should operate between 11 and 25 VDC.
2. Disconnect nodes from the system and see if the network energizes. By removing a node that has the failure on it, the system will re-energize. Use the halving rule to quickly isolate the problem area. First split the network and see which side energizes then continue to halve the failed side until you isolate the failed component.
3. When installing new devices, change the MAC-ID number (most devices are manufactured with the MAC-ID preset to 63). Duplicate MAC-ID numbers will generate an error. Some device IDs are set in software while others use rotary or dip switches. Many times these switches or software get changed accidentally and can cause errors to occur.
4. If the problem is isolated to an individual device, read that device’s instruction leaflet or product manual for specific solutions for that item. Occasionally, interfaces may be damaged and may need to be replaced. Be careful to set a new device to reflect the settings in the old unit.
5. Verify that the system is intact and that no damage has occurred. Walk the network if possible to determine its actual layout. This will help you visualize where trouble may lie and may reveal obvious problems.
Other things to check include wiring connections, cabling, the power supply and grounding.
All T and Phoenix style connections should be tight — there should be no intermittence caused by wiggling the connectors.
The connection to the scanner card must be firm and the card must be properly attached.
Phoenix connections must be terminated correctly: V+ (red), CAN_H (white), Drain (bare), CAN_L (blue), V- (black).
The power junction connection must be properly wired and grounded.
Cables are not to be constrained so that an excessive tension is placed on connections.
Only two 120-ohm terminating resistors should be installed on the ends of the trunk line.
Resistors are to be connected between CAN_H and CAN_L if Phoenix connector are used.
Check the network resistance by measuring between CAN_H and CAN_L for 60 ohms. If greater than 60 ohms, fewer than two resistors exist; if less than 60 ohms, then more than two resistors exist.
Ensure that the overall length of the system is less than the maximum allowed.
Verify that each drop is less than 6 m (20 ft) and ensure branch drop length is also less than 6 m.
Total the length of all drops and ensure that the total, cumulative drop is less than the maximum allowed.
Cables should not be put in a cable tray or conduit which also contains higher-voltage cables, unless they can be physically isolated (the DeviceNet cable rating is 300 V).
Check that cables are not draped over electrical motors, relays, contactors, or solenoids, as both trunk and drop lines carry data and should be at least 7.5 cm (3 in.) from power cables.
The count number of nodes should not exceed 64 per sub-network, including the Master node.
Check for shorts of CAN_L and/or CAN_H to shield or V-. CAN_H and CAN_L with respect to V- should read about 2.5 VDC with the bus off. When the bus is active, CAN_H should be about 2.5-4.0 VDC and CAN_L 1.0-2.5 VDC (depending on state).
Check the cable for proper internal wiring (continuity pin-to-pin).
Check that the power supply is rated at 24V (1%).
Check all fuses for condition.
Ensure that the sum of the current demand does not exceed the power supply’s rated current.
Make sure you de-rate the power supply for temperature, using the manufacturer’s guidelines
Check device distance from the power supply for current drop over the same distance
The maximum cable length to the power junction is 3.3 m (10 ft).
Some devices will require separate power supplies (i.e., 120 VAC, 480 VAC, etc.). Ensure that these devices are properly connected.
The shield of the cable system and the V- and the ground conductor of the power supply should be grounded at the same location.
You must ground your DeviceNet cable system at only one location.
Break the combined shield/V- connection to frame ground and verify that the impedance is greater than 10 MW to the frame ground.
Break the shield/V- connection at the power supply and verify that the impedance is greater than 1 MW shield to V- with 24V off.
Intermittent network problems
For intermittent network problems, spot-check the power for noise with an oscilloscope. Check the most obvious points first (three-phase motors, power supplies and cables, elevator shafts, etc.).
When the sections have a voltage drop (Common Mode Voltage or CMV)) of less than 4.65 V, your configuration will operate properly, otherwise the transceivers may fail. Ideally, the voltage drops for each section should be within 10% of each other.
To test for CMV problems, measure the V- vol
tage with respect to ground at several points in the network. If the readings vary more than 4.65 VDC, then message errors may occur.
If one section has a substantially greater voltage drop than the other, you should attempt to balance the load of the cable system. This can be done by moving the power supply in the direction of the overloaded section, moving nodes from the overloaded section, shortening the network length, moving high current loads closer to the power supply, adding a power supply, or breaking the network into two sections.
DeviceNet troubleshooting tools
There are many tools available for troubleshooting DeviceNet, including multimeters, oscilloscopes, hand-held tools, and PC-based tools.
The good old multimeter is a handy tool for measuring the network resistance, Common Mode Voltages, V+, V-, CAN_H and CAN_L voltages with respect to ground or V-, as well as current draws on the network. For advanced troubleshooting of noise on the network, an oscilloscope can be used to capture waveforms and spikes.
Hand-held tools such as the DeviceNet Detective by Synergetic, the Net Alert products from SST, and network analysis tools from Fluke Electronics, can be used to measure many of the same bus parameters as the multimeter, but add features such as node commissioning tools, bus off indicator counts and fault monitoring.
PC-based software tools are available from DeviceNet Interface card vendors such as SST, Synergetic (Hilscher), Rockwell, and others. These can be used for node commissioning and network message traffic analysis.
DeviceNet training and outsourcing issues
An industrial end user usually decides to implement a networked automation solution because of the promise of increased efficiency and productivity. An open system offers the added benefit of interoperability and interconnectivity. The ultimate motivation is the desire to generate greater profits.
Sometimes the ease of implementation and ongoing maintenance does not meet the expectations of the user. The gap between expectation and reality is usually related to a lack of knowledge and understanding of the system and its capabilities.
The user must take some responsibility for adequately preparing for this new technology. This is where training becomes crucial in ensuring the maximum return on the investment for this new system.
There are three main areas where training is important:
Design: System design is typically the responsibility of the in-house engineering department, a third-party consultant or a system integrator. In the case of a contracted third party, it is essential that the end user clearly define the responsibilities, both pre- and post-design, of the system integrator. Otherwise, there is significant risk that the user will assume the role of integrator and troubleshooter for the inevitable issues during installation and commissioning.
The ODVA and vendors offer specific training courses related to system design. Attention to detail at the design stage results in a smooth installation and start-up. It is quite common to encounter difficulty in integrating products from different manufacturers; the simple solution is to insist on conformance-tested products and qualified (experienced and trained) design people.
Installation: The user must decide if the installation is the responsibility of in-house resources or a contracted installation/commissioning system integrator. A third option is to include installation and commissioning of major assemblies, such as motor control centres, as a separate item on the bill of material from the manufacturer. Whatever the choice, the user must make sure that the individuals responsible for the installation are properly trained on network design rules such as proper grounding practices, power supply installation, physical media installation and network termination.
Training issues: The ODVA, manufacturers and system integrators all offer DeviceNet training courses. As well, manufacturers and integrators will provide system maintenance training customized for the specific system installed at a location.
Installing a new networked solution is a large capital investment. Surprisingly, many users are unwilling to buy some insurance in the form of training for their personnel. This relatively small cost is a key element in the successful implementation of this new technological purchase. MRO
Donald Bildfell, CET (donaldbbildfell@ eaton.com), is a technology application engineer and Andrew Carrothers, P.Eng, MBA (firstname.lastname@example.org), is a market segment manager. Both are with Eaton/Cutler-Hammer Canada, Burlington, Ont. Product information can be found at www.cutler-hammer.ca or www.eaton.com, or obtained by using the reader reply number here.