Rockwell/Devicenet/Powerflex Comms fault - please help

Hi

Just wondering has anyone had anything like this happen to them?

I have just split a safety cct which previously used a single safety relay to kill power to 10 powerflex40 inverters (connected via Devicenet 22-comm-d)), with power being restored to the inverters 5 at a time once the safety relay is reset.

I now have 2 safety relays, one killing 4 inverters, the other killing 6. Intermittently when the 6 inverter relay was operated while the 4 inv relay was ok, the 4 inverters which should have continued operating correctly, faulted to "F071" (comms fault - Devicenet).

Working on this i have narrowed it down to when one specific inverter (node 7) is killed, it causes the other 9 inverters to show the network/comms fault.

I swapped the DeviceNet adapter on the node 7 inverter - same fault.

Swapped the adapter with its neighbouring drives adapter, leaving nodes the same - fault stays with adapter.

If i remove node 7 from the network (and make it 15 for example) the problem dissapears.

If i set another to node 7, the fault goes to that drive.

Why does killing node 7 fault the network? Why does no other node have this effect? Is there a parameter for this, or is it just a quirk? Please let me know if anyone else has had this problem, or can put forward a theory as to why it does this, i greatley appreciate help or suggestions.

Thanks in advance, and all the best

Guy

PS, sorry that it's not actually a PLC question, just thought the wealth of experience on here might provide a solution.

That does sound bizarre.

The first thing I'd do is set all the 20-COMM-D modules to a specific baud rate, instead of AutoBaud. I've seen networks containing nothing but 20-COMM-D slaves fail to correctly detect the baud rate. You can tell because the "DN Rate Actual" parameter in the 20-COMM-D will show up different than the scanner baud rate.

Does the safety relay or any other circuitry use the same power supply as the DeviceNet network ? I've seen lots of problems caused by installers taking the shortcut of using the DeviceNet power supply to power other devices that are supposed to be isolated from the DeviceNet.

Thanks for the reply. The adapters are all set to auto detect, so will manually set them tomorrow. Also, i think the power supply is shared amongst all 24v ciruitry, so will look at installing a seperate PSU for the DNet too.

I am of the opinion that this could be related to the DNet scanner, as the slave devices "don't care" that a node has suddenly dissapeared (as they do not communicate to it), and the entire network (including the scanner) faults when node 7 is killed (the slave devices only communicate with the scanner(?) so the scanner must be the first thing deciding there is a fault?)

Thanks for the "That does sound bizarre" comment. Puts my mind at rest that this shouldn't be happening.

Quick follow up question... Does a daisychained Devicenet cable need terminating resistors? I just don't recall seeing any, but will check tomorrow.

Once again thank you, and when (if) i get to the bottom of this, i'll let you know.

All the best

Guy

I went back and re-read your post carefully.

...when one specific inverter (node 7) is killed, it causes the other 9 inverters to show the network/comms fault.

Click to expand...

When you say "killed", I presume you mean "input power is removed".

The fact that the problem appears related to Node #7 might just be coincidence; I've seen "node-related" problems actually due to timing and reflections and other weird stuff. This might still be due to the shared DNet/Everything Else power supply.

What's the exact error shown on the DeviceNet scanner module ? It's possible that the scanner is programmatically being shut down when the connection to Node 7 is lost.

Remember, I'm smiling when I say this.

And by the way, YES, all DeviceNet networks need exactly two 120 ohm terminating resistors.

One each must be connected between CAN-H and CAN-L at the two extreme physical ends of the trunkline.

Other common related answers regarding DeviceNet terminating resistors.

It doesn't matter how long the network is. Even short networks need terminating resistors.

One resistor is not enough, unless the network is under 20 feet and the resistor is only 60 ohms (such a network has a zero-length trunk and all wiring is considered a dropline)

Three resistors is bad. So are four, five, six, and ten resistors.

A resistor does not have to go at the scanner, unless the scanner is at the end of the network.

No, you can't use the 150 ohm or 82 ohm resistors from an A-B DH+ network.

Yes, the resistors were in the scanner box you threw away. Four of them. I'm sure.

Yes, I will send you resistors for free. I have a roll of 200 of them I bought from Digi-Key five years ago. There are 120 left.

And lastly....

I will not explain why your network previously worked fine without them, and I do not care that you never installed them before.

Guy,
I was told by a Rockwell drives engineer that it was not good practice to power down drives when operating the e-stop as there are limits to how frequently you can power up a drive without damaging it. You might consider fitting output contactors interlocked to the drive enable input, have these in your safety circuit and then leave the drives powered up all the time. This works particularly well if you have a light curtain or safety gate circuit that is frequently opened.

I second EVERYTHING that Ken said. I can guarantee, without a doubt, shat you are experiencing is related to the lack of having all the 24VDC sharing the same power supply. And other strange problems due to not terminating the network properly.


I have had both cases happen to me. My panel builder used whatever resistors he could find for the DN network without regard to what their value was and created all kinds of weird and unpredictable behaivor on the network.

Another case where the Owner tried to cut costs by combining PS, caused similar type weird faults on another network.

Look at these and you will cure your problems.

David

Thanks for the replies chaps.

Just checked, no terminating resistors...

The deviceNet is supplied from a seperate 24vTelemec PSU, but i didn't have chance to trace the 0v, though it should not matter if the 0v of the DeviceNet is commoned with the other PSU 0v (should it)?

I liked your resistors speech Ken, cheers Thats not the first time you've said that is it??

Anyway, i'll be off home shortly, and am on a jolly tomorrow, so will try to look friday and rectify a few things.

John - Is a site standard that the inverter must lose supply when e-stopped. I did ask a Rockwell engineer (who is currently comissioning a Rockwell built panel which has a similar e-stop system) who said that the modern drives do not have a problem with powering down repeatedly. I think that "should the drive be killed on e-stop?" seems to have many answers, is there a correct one?

BTW. Does anyone know of a good starting point/reference for someone wishing to learn more about Servo Systems, specifically, Logix, Sercos and Kinetix?? Doing the Rockwell course later, but would help to know a little bit first i think.

Thanks again for the help

Guy

It does matter (Sort of). The Devicenet power supply should be totally stand alone with the common tied to earth at one point. If you common the commons and the normal power supply is tied to earth then that gives 2 earth points.
I disagree with the Rockwell engineer, the drives may not have a major problem with it but it does stress the drive and I have found that if a drive is going to self implode there is more chance of it happenning at powerup. I always now try and put the safety contactors in the motor leads and disable the drive as well using software.

Reference material for motion. RSLogix 5000 help. Online books. All the motion manuals.

Thats if you installed the online manuals option.

Regards Alan Case

This is from the Powerflex 70 Manual, I expect it applies to all the powerflex range:

ATTENTION:​

​

​

and reapplies the AC line to the drive to start and stop the motor can
​

cause drive hardware damage. The drive is designed to use control input
​

signals that will start and stop the motor. If an input device is used,
​

operation must not exceed one cycle per minute or drive damage will
​

occur.
​

!
​

​

​

​

Thanks John and Alan, i go with you two (and the manual), and will re-wire accordingly. I have since found out it is not a site standard, so when i get time i will rectify.

As a follow up on the DeviceNet problem, i have discovered that if you disconnect a node upstream of Node7, the fault does not occur. If you disconnect a node after node 7 (downstream) the fault will occur. Terminating resistors are now in (with no success). I think the only way to go with this problem is to obliterate it rather than solve it, and go for the re-wire (keeping inverter on and disconnecting the motor).

Thanks again for the help, it's greatly appreciated.

All the best

Guy

Hi

Just as a follow up on this problem...

Ther terminating resistor for the network was in a T-Tap between the scannner and the first drive.

The drives were set to auto baud - changed, but no luck.

Node 7 was changed to node 16, node 7 removed from the scanlist and replaced node 7's io mapping with node 16s

Problem solved.

So it comes down to the fact that this particular set-up was not happy with having node 7 removed from the network in certain situations (another quirk was that if node 1 was powered but the drive not running, the fault would not occur?!?). Call node 7 node 16 and we have a winner.

Also, an identical network set up has just been installed for an identical conveyor line, and it has the same issues!

Thanks for all your help

Guy

Shouldn't the terminating resistor be at the end of the line? I am just about to do a MCC with 8 ABB AC800 VSDs and another one with 8 DOL starters using ABB UMCs and a 90kW AC800. What sort of topology would you reccomend, looped through or a series of drops? The MCCs are about 3m long with between 2 and 4 starters in a section.

You should have a terminating resistor on each end of the trunk cable.