Sign in to follow this  
Followers 0
phuz

CLX DeviceNet Error 71

10 posts in this topic

I am being told by a customer that the DeviceNet card keeps faulting. It is attached to a bunch of Powerflex 40 VFDs and this has been in place for about 7 years. Randomly, the card started faulting with code 071 and they are getting a message about invalid data in scan list. Nothing has changed programatically and the only way for them to clear the fault is to cycle power several times; however, it returns less than a day later. Is it possible for the scan list to suddenly become corrupt or is it more likely that the module needs replaced? I don't work a lot with DeviceNet, so I am trying to get as much info as possible as it looks like I may be making the 3 hour drive to them some time over the weekend. At worst, I suppose I will upload the module config and download it to a new module.

Share this post


Link to post
Share on other sites
Is the 1756-DNB showing an error 71, alternating with the node number of the affected PowerFlex 40 drive ? "71" happens to be an error code that could appear on either device. On the PowerFlex 40, it means "Net Loss Error". On the 1756-DNB, it means "illegal data in scan list". Degraded wiring (loose terminals, a failing power supply, missing termination resistors) could definitely cause PowerFlex 40 network loss errors, but I can't think of anything but a configuration problem that would cause Error 71 on the 1756-DNB. I've only ever seen that error message during commissioning and product testing.

Share this post


Link to post
Share on other sites
From what I heard, the error is on the DNB module and I am not sure if it is flashing a node number or not. I am still waiting for more info. So I have to wonder if it is the module itself.

Share this post


Link to post
Share on other sites
Update: customer just responded that the error code is on each of the VFDs and NOT the DNB module. I'm having them check the wiring and termination resistor.

Share this post


Link to post
Share on other sites
Have the customer go through a quick-and-dirty electrical check: so many folks just stare at the wires. 1. Using a digital voltmeter, measure the voltage between the black and red wires. It should be a nominal 24 volts. 2. At the very farthest point away from the DeviceNet Power Supply, measure the voltage between the black and red wires again. It should be at least 19 volts. 3. Disconnect the network power and measure the resistance between the blue and white wires. Because the termination resistors are 121 ohms each, this measurement should be about 60 ohms. If it's 120 ohms, or 45 ohms, or something else entirely, there are missing (or extra) termination resistors. Be sure the network power is disconnected; a device trying to transmit will distort this measurement. 4. Before reconnecting the network power, verify that the network has a dedicated power supply for the DeviceNet, and isn't sharing that power supply with other loads.

Share this post


Link to post
Share on other sites
Did the customer Change any devices on the network such ad a drive. Newer firmware will not be recognized my the scan list if the device keying is set to monitor that. Find out if there are any newer drives in the network and if so look at the firmware revision number and compare it to the older drives.

Share this post


Link to post
Share on other sites
See kb 45065 if you have tech connect. On power flex 40 the major firmware rev has to match or you have to turn off the option that monitors firmware revs in on the device keying in the scanner card setup. Or you have to upgrade your scan list with the new device. Major tip, check your device net mapping before you load any new eds files. Sometimes integrators decide to modify the mapping instead of using the default i/o map. Especially if using multiple drives. I once had the same issue you are dealing with, maintenance had always been able to change out their drives until they finally got a couple with the newer firmware and "boom" the whole network down and no one wanted to tell me what they did, I had to find out the hard way. Then I updated the eds only to find out it had custom device net mapping that I had overwritten. So check that also.

Share this post


Link to post
Share on other sites
See 19931 - DeviceNet Electronic Keying - Description of functionality and example also

Share this post


Link to post
Share on other sites
DeviceNet has a feature called Electronic Keying, which when disabled, allows the network to still function regardless of a devices series, revision, product code, vendor or device type. Sorry for the multiple posts, I am typing on my phone.

Share this post


Link to post
Share on other sites
Electronic keying would only be a problem if the drive or the comm module had been replaced. And the problem would be persistent and unclearable and limited to the changed drive. This sounds like an ordinary loose wire or noise problem.

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