DeviceNet Error 73

[lesmar96]

We replaced a VFD for a customer.
The old VFD was a Fuji/GE G11 on a DeviceNet network with a bunch of other equipment talking to a SLC plc.

I am not versed in Allen Bradley equipment and I know very little about Devicenet.

We replaced the drive with a Fuji Mega because it fit in the bucket etc. So the drive should be just a new generation of the old one, except we stepped up a hp to match the old frame size.

But I cannot get the plc and the drive to communicate. The DeviceNet card on the Fuji has 2 LEDs on it. The one represents hardware status and the other comm status. The hardware one is good. The comm LED is solid some of the time but then goes through a series of flashes and back to solid. According to the Fuji manual, this means the drive is waiting on a request from the DeviceNet master.

The DeviceNet card on the plc rack is flashing 73 then 10, back to 73 then 10. The drive is node 10, so, if I understand correctly, the 73 would be an alarm code.

From my research, 73 has something to do with electronic keying. Obviously the new drive is not identical to the old. is that the problem here? Do we need to get the AB programmer to update the electronic signature for device 10 in the plc program?

Appreciate your help! Thanks!

 

[plvlce]

From my research, 73 has something to do with electronic keying. Obviously the new drive is not identical to the old. is that the problem here? Do we need to get the AB programmer to update the electronic signature for device 10 in the plc program?

Appreciate your help! Thanks!

Correct, error 73 indicates that *something* about the drive does not match the stored electronic keying in the DeviceNet scanlist. I've seen even a change as minor as a firmware revision difference cause this; a different model of drive absolutely will.

You will indeed need someone with DeviceNet software (RSNetworx for DeviceNet) to update the scanlist. There may be further configuration needed -- I'm not familiar with Fuji drives at all -- but that will likely depend on whether the communication format from the drive does in fact match the old one exactly.

As a side note, the configuration does not reside in the PLC program as such, but rather inside the DeviceNet Scanner card of the PLC. The only reason the PLC program should need to be touched is if differences in the drive result in a different I/O mapping.

 

[Harrstein]

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

Page 91.

Shows that the ID of the new drive is not matching the old drive.
You need to go online with RSnetworks and go to the scanlist of the Devicenet scanner of the SLC500 rack, there it will ask you to change the ID with the new ID.

Had to do the same with a SEW drive earlier this week. Replaced a old MC31 with a MDX61.

But I dont know if Fuji tends to do weird stuff. ABB drives tend to change the way they send stuff on the devicenet, requiring more extensive work.

 

[Steve Bailey]

Ask your drive supplier if the Device Net interface card for the G11 is compatible with the Mega.
Is there a list of the parameter settings for the old drive? If not, can you still power it up and see the parameter list? My experience with Fuji drives is that they do not change parameter numbering as they add functionality. So parameter F22 (a random selection) will mean the same thing in both the G11 and the Mega. So after confirming compatibility, the next step would be to compare parameter sets paying particular attention to the parameters associated with the Device Net interface.

 

[lesmar96]

Thanks for your help.
I will get in touch with the Rockwell programmer who supports the plc.

We bought a new DeviceNet card for the Mega because the one that was on the G11 is not physically the same.

I have checked and doublechecked the parameters and I believed they are correct.

I forgot to mention one thing I had done. This drive is Blower 1. There is a Mega sitting right beside it for Blower 2 that was done several years ago by a different integrator. That drive is node 11. I switched that drive to address 10 and set the new one to address 11 and it picked up communications just fine with the plc, appearing like Blower 2, obviously.

That's why I was leaning towards a plc config conflict, which ya'll are confirming.

 

[JTCat]

Thanks for your help.
I will get in touch with the Rockwell programmer who supports the plc.

We bought a new DeviceNet card for the Mega because the one that was on the G11 is not physically the same.

I have checked and doublechecked the parameters and I believed they are correct.

I forgot to mention one thing I had done. This drive is Blower 1. There is a Mega sitting right beside it for Blower 2 that was done several years ago by a different integrator. That drive is node 11. I switched that drive to address 10 and set the new one to address 11 and it picked up communications just fine with the plc, appearing like Blower 2, obviously.

That's why I was leaning towards a plc config conflict, which ya'll are confirming.

You need to open RSNetworkx for DeviceNet and fix the issue. Make sure the resistors are in place and the baud rate is correct for the drive. Then you can right-click on the node that has a mismatch and there's an option to have Networx attempt to auto-resolve the issue, then you can download the mapping and parameter list back to the SDN.

 

[Jim3846]

Like others have said need RSNetworx for devicenet to redo that node. You already have a known EDS file on blower 1 node 11, upload that eds if you can from rslinx. Not sure if that feature works for 3rd party devices. Usually the end user should have all eds files if they are on top of using devicenet. Otherwise, you will have to get it off the vender website. Then use RSNetworx to resolve the differences and configure the parameters as they are on Node 11. Like others said download the changes to that node. I am not sure if you need to download to the scanner module, if the mapping is the same for In and out.

 

[widelto]

I am retired now, when I was working I taught a Dnet course to my engineers and technicians , It was in spanish if any one wants to have it just let me know. It´ll be my pleasure and for free of course.
Send me a PM with email.
I guess it will be easy to translate it to english.

 

[JTCat]

I am not sure if you need to download to the scanner module, if the mapping is the same for In and out.

Yes. All changes should be downloaded

 

[Ken Roach]

It looks like the older Fuji G11 had a DeviceNet interface called an OPC-G11S-DEV. The user manual shows that it was built by HMS Fieldbus, which is good because that company is very experienced and reliable for this sort of interface.

The modern Fuji Frenic-MEGA has a DeviceNet interface module called an OPC-G1-DEV.

Page 25 of the older user manual shows the different I/O Assemblies that can be chosen, and the subsequent sections of the manual show how the data is arranged inside those assemblies. These are very common I/O assemblies for AC variable frequency drives, except the Fuji Custom one. Most vendors (including A-B) have such a custom/vendor-specific assembly, usually for similarity in data format with legacy networks.

• 20 Required Output Basic Speed Control Output
• 21 Optional Output Extended Speed Control Output
• 100 Optional Output Fuji Drive Assembly Output
• 102 Optional Output User Defined Assembly
• 70 Required Input Basic Speed Control Input
• 71 Optional Input Extended Speed Control Input
• 101 Optional Input Fuji Drive Assembly Input
• 103 Optional Input User Defined Assembly

If you have the older project file, you should be able to open the offline configuration for the G11S, and see which Assembly objects have been selected to be used by the drive. The user manual suggests that parameters o31 and o32 select the assemblies, and that's pictured (a screenshot from 20+ years ago in DeviceNet Manager) on Page 20.

The modern interface looks like it was built by Fuji in Japan, at least the user manual includes some Japanese and English together.

The Assemblies on the modern one look very similar, and even parameters o31 and o32 are used to designate which ones are to be used.

From that user manual:

• o31=20 Output Basic Speed Control Output (2 Words)
• o31=21 Extended Speed Control Output (2 Words)
• o31=100 Fuji Drive Assembly Output (2 Words)
• o31=102 User Defined Assembly Output (4 Words)
• o31=104 Request for Access to Function Codes (4 Words)
• o32=70 Basic Speed Control Input (2 Words)
• o32=71 Extended Speed Control Input (2 Words)
• o32=101 Fuji Drive Assembly Input (2 Words)
• o32=103 User Defined Assembly Input (4 Words)
• o32=105 Response to Function Codes Access (4 Words)

It also says that if you leave o31 and o32 both = 0, that the assemblies will be the default 21 and 71.

If the I/O assemblies are set up the same, then the only thing that might be necessary is for the Electronic Keying in the I/O connection to be resolved to the new Identity object values.

 

[Ken Roach]

background:

Every device in a CIP network (not just DeviceNet) has an Identity Object, which includes things like the Vendor Number, and the Product Type, and the Product Code, and the Major/Minor firmware revisions, and the Serial Number.

In DeviceNet and other RA networks, these are used to implement "electronic keying". The idea is that before starting an I/O connection to exchange blocks of data with a networked device, the controller checks to be sure that it's the *correct* network device, and not just a device that is set for the correct network address.

The default in DeviceNet is to key on the Vendor, Type, Code, and Major Firmware Revision. While similar devices might have the same Vendor and Type (like Allen-Bradley AC drives), different sizes or voltage classes of drive would have a different Code. And because the functionality of a device might change between firmware revisions, the Major Rev is also used as part of the keying.

When your 1747-SDN module tries to connect to the older G11S interface, it's looking for Vendor 90, Type 2, Code 18. (I got that from Page 23 of the User Manual, and it will be part of the EDS file too).

But because you've replaced it with a modern G1 interface, the user manual (page 28) and EDS say that its Identity values will be Vendor 319, Type 2, Code 2403.

Because those aren't the same between the currently-installed equipment and the old Scanlist and the old *.DNT file, that's where the 1747-SDN gets Error 73 when it queries the drive before starting its I/O connection, and where RSNetworx gets the blue not-equal icon when it queries the drive during its network browse.

In RSNetworx, you can resolve that identity mismatch with a right-click: there should be a "Resolve Mismatch" or similar labeled function.

That should then let you re-configure the Scanlist with the identity values for the new drive. Once the new scanlist is downloaded, the 1747-SDN should be able to run that new drive.

I think the order of operations is:

Determine the I/O Assembly numbers in parameters o31 and o32

Resolve the EDS identity in RSNetworx

Resolve the Electronic Keying in the 1747-SDN Scanlist