Powerflex 70 - Difficulty with communicating with Devicenet ( SLC 500 )

Good Afternoon ,

We had to replace a Powerflex 70 2 HP with a 3 HP. These drives are on Devicenet . Once installed and transferring with the HIM , I was able to get rid of the flashing yellow on the STS LED . The 1747- Devicenet Scanner Module is reading 63 saying it is good.

When I turn the breaker off for the Powerflex 70 , the Scanner Module recognizes that it cannot communicate with that drive , and goes to , I think , a 73 or 78 . When powered up , everything looks fine , till I try to run it . It does
absolutely nothing . I look at it in the SLC 500 program , and I see no communication with it .

I open up RS Networx for Devicenet , I'm lost with that , When I try to go online with it , and browse , I get all these returns " Not Found at Address ## " .

A few questions....

- If Devicenet is seeing that drive , why wouldn't it be sending and receiving
information ?
- What would be the cause of not seeing the nodes on a Devicenet network ?

- Have you folks ran into this before ?

Thanks so much for your help .

On the 20-COMM-D board itself, what is the DeviceNet node number setting on the rotary switches ?

Check the data rate switch as well; if it's turned to the "PGM" position, then the 20-COMM-D will use the node number saved in Parameter 3 of the 20-COMM-D nonvolatile memory itself. I prefer to use the hardware switches to set the node number.

The fact that the 1747-SDN was left at Node 63 is evidence of sloppy engineering; I never recommend leaving any permanently installed device at the default node number that all devices come out of the box with.

What exactly do you mean when you say "I look in the SLC-500 program and I see not communication with [the drive]" ? I presume you mean that the status bits and words don't match the actual status of the drive, suggesting that the drive isn't communicating with the scanner.

In general, if there's no communication between the Scanner and the PowerFlex when both are powered up and connected, there will be an error message showing in the 1747-SDN scrolling display, alternating the Node Number and the Status Code.

Thanks Mr. Roach ,

When we changed the drive out , we used the same 20-Comm D adaptor . I really haven’t looked at the data bits , but just the instructions in the SLC 500 program . There are not bits being sent and received .

What does the 63 really mean , or the other numbers that say everything is ok ? Node 1 is what it is suppose to be . Is there a parameter in the PowerFlex 70 that you need to put the Node number in ?

Thanks Sir ,

DeviceNet uses node numbers between 0 and 63.

Virtually all devices come out of the box at Node 63, set for 125 kb/s (or set to automatically detect 125/250/500 kb/s).

The 1747-SDN's node number is often set to 0, but it too comes out of the box as Node 63. That setting is done in software and saved in nonvolatile memory on the 1747-SDN itself.

When the 1747-SDN has nothing to indicate that's out of the ordinary, it will just sit there and display its node number. So when you say that the 2-digit display just says "63", it's a safe bet that there are no broken I/O connections, the module is in RUN mode, and it's been set for Node 63.

The PowerFlex 70 itself doesn't care about the node number in the 20-COMM-D, just the DPI cable port that it's connected to.

The 20-COMM-D gets its DeviceNet node number from the rotary switchs on the module itself; they can be set to any number between 00 and 63.

If you turn the other switch on the 20-COMM-D (the Data Rate switch) to the position marked "PGM", then the 20-COMM-D uses whatever node number is saved in the 20-COMM-D in Parameter #3.

The simplest diagnostic step to be sure the 1747-SDN is scanning the PowerFlex 70 is to disconnect the PowerFlex 70 from the network.

The 1747-SDN display should alternate the drive's Node Number with the error code "72" (IO timeout), then after a few seconds change to error code "78" (Message timeout). When you plug the drive back into the network, the code should go away.

Because the worst thing that can happen in an automated machine is usually "unintended motion", DeviceNet products (and all A-B networked products in the past 20 years) use more than just a node number to verify that they are the correct thing.

They also use "Electronic Keying", in which you can have the Scanner check the Adapter device's Vendor, Type, Code, and Major or Minor Version.

EtherNet/IP secure and safety devices can even go down to serial numbers and security checksums.

A PowerFlex with 2 HP versus 3 HP will be a different Product Code.

The Electronic Keying feature is handled by the 1747-SDN's scanlist. The Scanner knows and saves the adapter device's node number and the Vendor, Type, Code, and Maj/Min Revisions. You can configure it to check one or more of those before starting the I/O connection.

But if your system had been configured to use Electronic Keying to verify the Code number (which means the voltage / current rating) of the PowerFlex 70, then it would be showing an Electronic Keying Mismatch error code (#73), alternating with the Node Number of the drive.

You mentioned an Error 73 earlier in your post.

Watch the error codes carefully on the 1747-SDN scanner. It can be tricky to keep track of because they alternate with the node number every second or so. If I remember correctly, the Node number shows up first, and the Status/Error code comes *after* it.

The error/status codes are all listed in the back of the classic 1747-SDN User Manual:

https://literature.rockwellautomation.com/idc/groups/literature/documents/um/1747-um655_-en-p.pdf

Yes. The error 73 , or whatever it was , it on purpose by turning the drives breaker off , to see if it really was really part of the network . I’m very weak with Devicenet, but it seems like once it would recognize it , the “pipeline “ of information would flow , but apparently it doesn’t.

Thanks again for the help.

Do the test by removing power to the PowerFlex drive again.

If status codes 72 and 78 are all that appear, and they disappear after the drive is re-powered, then it's not an Electronic Keying problem.

If status code 73 appears and does not clear, then it's an Electronic Keying problem.

If neither one appears then maybe there's a problem in the parameters of the PowerFlex drive itself, like a Start Mask or Reference Select issue related to the migration of the parameters between the drives.

Good Evening Mr. Roach ,


Could anything in Digital Inputs 361 thru 366 cancel out any
communication from Devicenet ? In 363 In 3 we have Jog 1 10.


There is actually no wires on the terminal blocks on the drive and never was.


Thanks Sir ,

As a general principle, A-B drives that use discrete inputs for control require you to wire a negative-logic STOP input; the input must be True for the drive to be started by any source, and if the input is False, the drive stops.

The PowerFlex 70 comes out of the box with the digital inputs configured that way. Digital Input 1 (Parameter 361) default configuration is for "STOP - CF", meaning that cycling the input from 1 -> 0 -> 1 will stop the drive and clear any faults.

Generally if you set that parameter up incorrect or mis-wire it, the discrete input asserts a STOP, and the drive shows "STOP ASSRTD" on the HIM display.

When I set up a PowerFlex to run on the network only, I configure all the digital inputs to Not Used.

Ok. That is what me and my colleague was thinking . Would this cause a conflict with Devicenet , and not allow it to control

Having a Digital Input set for "Stop" or "Stop-CF", but not wired to anything, will cause the digital inputs to assert a STOP command.

This will prevent any other source, including DeviceNet or the HIM module or a digital input configured for Jog, from starting the drive.

But it will also very clearly indicate "STOP ASSERTED" on the HIM module, and flash the yellow status LED.

Good Evening Mr. Roach ,

I wanted to give you an update on our PowerFlex 70 issue . It was a jog in Digital In Par 363 . Changed it to “ Not Used “ and it ran . I guess anything selected would cause a conflict with Devicenet.

Thanks so much for your help .

I am glad to hear you got it running.

I invite you and anyone reading this thread not to take away from it the lesson that "a digital jog input will conflict with DeviceNet".

Please direct your attention to the 20A-UM001 User Manual for the PowerFlex 70, page 68, which describes the software configuration of the Digital Inputs.

A digital input on a PowerFlex 70 that is configured for "Stop-CF" or "Enable" and is physically false will conflict with *any* start command from any network, digital input, HIM module, or other function. It will also show an amber status indicator and the message "Stop Asserted" on the HIM.

But a digital input configured for "Jog" should not. "Jog" is a momentary input, and should not conflict with network control.

If Digital Input 3 was tied high and the Jog Speed was set to zero, that would override the network speed command, but not if Digital Input 3 was physically not wired to anything.

If you configure digital inputs that conflict with one another (like Start with no Stop, or both Jog Fwd and Run Fwd) the drive will report a Digital Input Conflict alarm.

If the Jog command was a directional one (Jog Fwd or Jog Rev) and you were sending a conflicting direction command over the network, that might have caused a conflict. I haven't attempted to troubleshoot such a conflict.

Again, I'm glad you got it working and appreciate the update for the PLCTalk forum community.

First you should have a copy of RSLinx for Device net It would make things easier

With the scanner reading the drive at node 63 tells me that the drive has not been configured. I believe the factory node address is 63
the address need to be changed
if this is a replacement then you need to set the node address to the same as the one removed then every thing should read the same
in the 500 the Device net scanner maps the node date to a memory on the scanner module. the PLC reads / writes to the memory if they don't match up then you have problems