Tommie Dont Ground

DeviceNet powerflex 40 faults

18 posts in this topic

We have a devicenet network that consist of a compact 1769-SDN, 20+ PoweFlex 40 drives, and a couple compact I/O blocks.  Recently drives have been faulting randomly F71.  This has not been an issue in the past.  Drives fail occasionally and we swap them with a same HP drive.  We use a him copycat to upload and download parameters.  
 

The DeviceNet power supply is separated from other power and has been replaced recently to rule it out.  The Network 120 ohm resistors are installed at the network’s beginning and end. The Network wiring has been inspected. 
 

Has any experienced anything similar? 
 

Thanks! 

Share this post


Link to post
Share on other sites

F71 is network loss.  

Have you checked the node to node voltage drops.  

Also curious as to system age?

Might need to replace a Comm-D card.

Share this post


Link to post
Share on other sites

Thanks for responding.  The devicenet voltage is good all the way down to the last device, just a little over 24v.  The age of the system is 11 years.  It is a packaging line for tissue.  Mainly conveying and palletizing. 
 

The odd thing about the faults is it’s random.  A drive here and another there.  Nothing you can narrow down to hardware. 
 

The Powerflex 40’s are getting harder to come by.  We would like to change them to 525’s and keep the same DeviceNet communications since we may be able to do a few here and there.  There is about 100 of them on the packaging lines but only about 20+ on this network. 
 

Thanks again! 

Share this post


Link to post
Share on other sites

You might want to check with your RA distributor.  There are DNet Tools that run on a dedicated PC and can monitor the network trqffic and give you an idea why the F71 is occurring.

Share this post


Link to post
Share on other sites

Follow up:  12-30-22

We contacted Rockwell and presented our problem with the random F071 faults on the Powerflex 40’s.  They recommended changing the baud rate from 500k to 125k.  This was listed in Tech. Support document QA10784. 
 

This line ran for 12 years without this problem.  We also have a duplicate line that is running the 500k baud rate without problems.  
 

Time will tell and I will update again within the next couple weeks but this fault has not happened after the change.  Fingers crossed. 

Share this post


Link to post
Share on other sites

Comm issues are sometimes hard, especially when it’s random. More when it’s on a bus network such as devicenet. Asking the right questions helps narrow down. Do all drives fault at once or one here and there. Are the pf40s in single drive or multi drive mode?  What is the spacing on top and bottom of the drives?  Any new device been added to the bus?  If reducing baud rate fixed the issue, this probably masked the problem

1 person likes this

Share this post


Link to post
Share on other sites

Drives fault one or two at a time. Never the same.  One here and another there. 
 

Single drive mode. 
 

Spacing meets manufacturer instructions. 
 

No new devices added. 
 

It is suspected Rockwell introduced into their hardware an issue that affected running a baud rate above 125k. 
 

Share this post


Link to post
Share on other sites

That’s a difficult concept for me to accept without supporting data. Baud is just the speed at which it talks. If that were true, a single drive at 500kbps would have the issue. Are there release notes on the 500kbps issue?  Have you tried other traffic reducing means such as rpi time or less devices on the network?  If this is 11 years old, and is a hardware issue, then moving a known bad one to a good position should stay with the drive. Just giving you thoughts on troubleshooting 

Share this post


Link to post
Share on other sites
1 hour ago, VFD Guy said:

That’s a difficult concept for me to accept without supporting data.

Why?  Slower baud rates are more noise-resistant.  I can easily believe Rockwell had a manufacturing problem that made some devices more susceptible to noise, where going slower helps. :shrug:

1 person likes this

Share this post


Link to post
Share on other sites

just about all problems with DeviceNet that i have seen were due to wiring. even people that do not understand networking manage to find configuration that works, even if takes bunch of attempts. but when something is wrong with the hardware (wiring, termination ,shielding) no amount of poking at settings will get you though. 

since the line was working before, and you are backing up and restoring settings, there is no reason to doubt parameter settings. lowering baud rate is usually last ditch effort. Sometimes it may help but there are no guaranties. one example where that does work is if one or more of devices use autodetection of baud rate. on a noisy network they may have better chance when baud rate is reduced. 

as for troubleshooting tips, i would say if not already done so try following:

measure resistance across data lines to confirm it is 60 Ohm (pair of 120 Ohm resistors in parallel). if not correct, one of the terminators is not connected or there is a lose connection on one of the bus lines. it could also be that the bus is over-terminated (more than two terminators present). 

check voltages at each node on every terminal with respect to black wire. should be about 2.4V on blue wire, about 2.5V on white, 0V on shield and 24V on red.

check if the bus is really a bus topology. if there are dropped nodes, check the cable length of the drops. drops need to be short, do not remember the specs but if i recall they should not be more than 3m or so.

check if the bus shield is grounded at ONE place only. if the cable was damaged (jacket has abrasions, punctures by metal chips etc) because it may be acting as a second grounding point and ground loops will have terrible effect on signal integrity.

also check cable routing. communication cables should be always routed away from sources of noise.

if possible try to shorten bus (just for testing) to see of the problem persists. this is one thing that is done nicely on ProfiBus - just move terminator switch on any node in the middle of the bus and (if the bus is wired correctly) that is the only hardware change. doing so on DeviceNet is a bit more effort.

3 people like this

Share this post


Link to post
Share on other sites

Just as panic mode suggested we done all the troubleshooting by following step by step through Rockwell’s DeviceNet troubleshooting manuals. All was normal. Thanks for the input. 
 

What’s concerning in this thread is the Nay-Sayer’s who believe that lowering of the baud rate couldn’t be a viable solution.  Y’all did read this was Rockwell’s solution right?  The Knowledgebase tech note document I referenced was solutions across all networks, DeviceNet, Ethernet, ControlNet for this particular random fault. Why would they provide and recommend a solution that was masking another problem?  Only one thing is common across all networks… their drives and their firmware. 
 

BTW it has been a week without any faults.  We couldn’t run a shift without issues before the change! I am writing this follow up for the poor soul who encounters this problem in their mill and desperate for help! 

1 person likes this

Share this post


Link to post
Share on other sites

lowering baud rate does improve signal integrity. this is obvious even from reading installation guide, since it is possible to have longer bus network if the baud rate is lowered. this is not disputed. cables have capacitance and inductance so they can distort the signal. this is why bus is to be treated as a transmission line which is the reason for correct termination.

and it looks like you did receive product that is forcing you to use different settings. sometimes that is all one can do. fortunately this is pretty rare.

Share this post


Link to post
Share on other sites
On 1/5/2023 at 8:18 PM, pturmel said:

Why?  Slower baud rates are more noise-resistant.  I can easily believe Rockwell had a manufacturing problem that made some devices more susceptible to noise, where going slower helps. :shrug:

This is an easy suggestion with no data 

Share this post


Link to post
Share on other sites
12 hours ago, VFD Guy said:

no data

Rockwell provided the justification.  They just didn't admit the details of the data underlying their recommendation.  Tommie very much had data (indirectly, from a trusted source) for his corrective action.  That the action conforms to basic principles of transmission line effects makes it easy to accept, for those who understand what that means.

Did you see Tommie's followup?  Where going slower fixed the problem?  Seems like even more data in support.

Share this post


Link to post
Share on other sites

I’m just saying slower speeds doesnt mean a hardware issue. That’s the data you need. If it’s a hardware problem, then replace it. Problem goes away right? Replace it. Or are we not confident in that solution?

Share this post


Link to post
Share on other sites

Sure, replace if the hardware is still under warranty. And you can get enough new ones to swap blindly through line until you find all the bad ones. Or you can follow Rockwell's recommendation.

Share this post


Link to post
Share on other sites

It’s not a hardware problem per se.  The line ran for almost 12 years until about a year ago.  Within the last year the problems with the faults got out of hand. We replace these drives periodically and somehow introduced something into the system that a devicenet rate at 500k upset our vfd’s.   
 

Replacing the drives doesn’t solve the problem it created the problem. 
 

When Rockwell uses the word “anomaly” they are saying they don’t know why something happens. How are we going to be in a better situation than them to make a decision on the solution? 

1 person likes this

Share this post


Link to post
Share on other sites

Thanks @Tommie Dont Ground. After 12 years no warranty and I figured replacing wouldn’t help. I’m a big fan of divide and conquer. What is the time between each fault. This would help with a troubleshooting strategy. Also, you have 20+ drives. What other devices are on the network? Has anything been added recently? When you state the drives fail occasionally, you mean they are damaged or just mean you replace them when an F71 appears?

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