SLC500 Devicenet error 77????

Hi,

I'm looking for a bit of help regarding a devicenet problem on one of the machines at my workplace.

Basically one of the inverter drives has stopped opperating.

On the SLC 5 plc rack there is a 1747-SDN devicenet scanner module, this is showing an error 77 at node 2

Node 2 is an Allenbradley 160-DN2 devicenet communication module connected to a AB160C drive.

If I swap the card with Node4(i.e. addressing Node4 to 2) the fault clears. But the new card will not work on Node 4, it now shows 04,77!?!?!

What are the chances of me recieving 2 broken 160-DN2 cards with the same fault?

I have no experience of devicenet, so any help would be most apreciated.

Best regards, Colin

Not following your logic. You have a broken DN comm module on Node 2. You take a working one from Node 4, readdress it to Node 2 and put it on the drive and now Node 2 works. That's to be expected. But what are you putting on Node 4? If you put the broken one on Node 4 (readdressed from 2 to 4) then of course you'll now get 4, 77. If you leave nothing on node 4, you'll also get an error on node 4. So what exactly are you doing?

From the manual for the 1747-SDN card the error 77 means

Data size expected by the device does not match scanlist
entry. The solution is
Reconfigure your module for the correct transmit and
receive data sizes. Was this an operating system that now has issue or has something been changed? You will need software like RSNetWorx to check and configure the DNet system. If you are trying to change a part with a spare part it may need to be configured and/or commissioned. Are the versions the same? Each module must be setup in the 1747-SDN with matching configureation in the module. May need new or updated EDS file for the device?​

robertmee said:

Not following your logic. You have a broken DN comm module on Node 2. You take a working one from Node 4, readdress it to Node 2 and put it on the drive and now Node 2 works. That's to be expected. But what are you putting on Node 4? If you put the broken one on Node 4 (readdressed from 2 to 4) then of course you'll now get 4, 77. If you leave nothing on node 4, you'll also get an error on node 4. So what exactly are you doing?

Click to expand...

I have recieved a brand new DN module, taken it out the box and addressed it to node 2.
I still get the same error (77)

As an experiment, I re-addressed Node 4 to Node 2, I did this to prove that the Drive was ok.

I did read on the net about configuring with RSnetworx, but the company I work for don't have this software.

The machine in question has been in opperation for about 3 years with no known Devicenet problems and no changes/modifications have been made to the machine prior to this fault.

Colin

doctord said:

From the manual for the 1747-SDN card the error 77 means

Data size expected by the device does not match scanlist
entry. The solution is
Reconfigure your module for the correct transmit and
receive data sizes. Was this an operating system that now has issue or has something been changed? You will need software like RSNetWorx to check and configure the DNet system. If you are trying to change a part with a spare part it may need to be configured and/or commissioned. Are the versions the same? Each module must be setup in the 1747-SDN with matching configureation in the module. May need new or updated EDS file for the device?​

Click to expand...

Do I need to program the DN module prior to fitting, I was told it was plug and play, but then it seems that in this factory, everybody has as little knowlege of AB systems as me!

I did read the definition of the fault in the manual, but as I said, I've no knowlege of AB devicenet systems, so it looks like my employer might need to bring in a third party!

If you are replacing the module with an exact duplicate down to the revision number and EDS file that is used and the system was setup to reconfigure modules on replacement then yes it is plug and play. Otherwise it will take some work to get it working.

Yeah, what doctor said....Likely, the newer module is not of the same revision as the older module, or the I/O messaging size was changed on the modules in the original setup and you'll have to do the same for the new module. You really need to start hunting down RSNetworx and the original DN configuration file used to commission the network. Also, see if they have the 1770-KFD module either installed in the network or sitting on someone's shelf. You'll need that to connect into the DN network. Unless you have a 1784-PCD (I think that's the model) card for a laptop.

doctord said:

If you are replacing the module with an exact duplicate down to the revision number and EDS file that is used and the system was setup to reconfigure modules on replacement then yes it is plug and play. Otherwise it will take some work to get it working.

Click to expand...

They do have different revision numbers, oh well, it's out of my hands as we don't have RSnetworx software or any backups of the old code.

Thanks, for the info.

Colin

Very likely what has happened is that the Bulletin 160 drive itself has failed or had its parameters reset to defaults. I've seen this happen when a drive was hit with a large static discharge from an ungrounded conveyor section that went through the drive's ground conductors.

The amount of data the Bulletin 160 exchanges with the 1747-SDN depends on which I/O Assemblies are selected for the DeviceNet port. These are set by parameters in the drive.

Status code 77 on the 1747-SDN indicates that the amount of data it's been configured to exchange with the Bulletin 160 drive is different from what the Bulletin 160 drive has been configured to exchange. Since your scanner has not been changed, you can be certain the problem is in the parameters of the Bulletin 160.

If I were in your plant and was fixing this problem, I would connect to the DeviceNet using a 1770-KFD (serial) or 1784-PCD (PCMCIA) interface from my laptop, then open up RSNetworx for DeviceNet software.

One of the major functions of RSNetworx is the EDS-based Parameter Editor. This gives me access to the parameters for all the Bulletin 160 drives.

I'd go online with one of the drives that is functioning correctly, and would determine the values of the parameters that affect the I/O connection:

Parameter 107, Output Assembly =
Parameter 108, Input Assembly =
Parameter 109, Assembly Word 0
Parameter 110, Assembly Word 1
Parameter 111, Assembly Word 2
Parameter 112, Assembly Word 3

Then I'd go online with the drive that is malfunctioning and set its I/O connection parameters to match. The diagnostic code "77" should go away.

Next I'd compare the other parameters (speed, accel/decel times, current limit, etc) among the drives to determine if the drive that malfunctioned has retained its operational parameters.

Ken Roach said:

Very likely what has happened is that the Bulletin 160 drive itself has failed or had its parameters reset to defaults. I've seen this happen when a drive was hit with a large static discharge from an ungrounded conveyor section that went through the drive's ground conductors.

The amount of data the Bulletin 160 exchanges with the 1747-SDN depends on which I/O Assemblies are selected for the DeviceNet port. These are set by parameters in the drive.

Status code 77 on the 1747-SDN indicates that the amount of data it's been configured to exchange with the Bulletin 160 drive is different from what the Bulletin 160 drive has been configured to exchange. Since your scanner has not been changed, you can be certain the problem is in the parameters of the Bulletin 160.

Click to expand...

Ken,

I don't think the drive itself is the issue, but correct me if I'm wrong. If you read the OPs earlier post, when he moves a working DN module to the 'bad' drive, the 'bad' drive works and the error clears. That indicates to me that the drive parameters in the 160 drive are okay and configured properly for the DN comm module. It's confusing since '160' refers to both the comm module and drive, so just trying to be clear here for the OP....did you mean the 'drive' or the 'comm module' when talking about checking the parameters?

I hope that you will appreciate that maintaining programmable control systems requires either having software tools of your own or having contractors who have those tools. If A-B hardware is a fraction of what you have in the facility, it makes sense to contract out the work.

For this specific case, you might be able to get it done with no additional software purchases because:

1. RSLinx Lite communication software includes a "1747SDNPT" driver that passes through the SLC-500 controller and the 1747-SDN scanner module, rather than requiring a 1770-KFD or 1784-PCD connection directly to the DeviceNet network. Setting up this driver requires specific firmware and specific settings in RSLogix 500 which might have already been done, or might not. If you don't have RSLinx or RSLogix 500, then your odds of success drop quite a bit.

2. RSNetworx for DeviceNet will run without activation and work on nodes 0 through 5. Just your luck, Node #2 is the faulty one. Of course, you have to get the RSNetworx for DeviceNet software download first, which comes from a toolkit, a starter kit, or a friendly RA distributor.

3. Another way to access A-B variable frequency drives is Drive Explorer software, which is a free download. I have not used Drive Explorer with Bulletin 160s for a long time, so I'm not certain they can use the 1747-SDNPT driver, but it's worth a shot.

Robert, I think you and I are reading the same O.P. and getting different things from them.

With the Bulletin 160, all parameters are stored in the drive itself; the 160DN2 adapter has no stored parameters of its own. The settings of the DIP switches on the 160DN2 are read by the drive on powerup and stored as parameters.

The problem should follow the Bulletin 160 drive itself, not the 160DN2 adapter.

Ken Roach said:

Robert, I think you and I are reading the same O.P. and getting different things from them.

With the Bulletin 160, all parameters are stored in the drive itself; the 160DN2 adapter has no stored parameters of its own. The settings of the DIP switches on the 160DN2 are read by the drive on powerup and stored as parameters.

The problem should follow the Bulletin 160 drive itself, not the 160DN2 adapter.

Click to expand...

But as the OP indicated, the problem with the drive goes away when an existing adapter is used and configured for Node 2. That would indicate that the drive setup and ScanList in the SDN adapter are intact.

Also, from the DN2 manual:

An EDS file defines all the parameters in the
Bulletin 160 drive and the 160-DN2 module.

To me that indicates that there is some configuration associated in the DN2 module beyond the baud rate and node address set by the dips.​

So, are there any programmable parameters on the 160-DN2 module.

I am convinced that the Drive is fine as I can get that to run when I readdress one of the exsisting cards and fit it to said drive.

Also, If I get the original installation files from the Machine OEM and a demo of RSnetworx, I should be able to modify the parameters on node 2(the faulty node)?

This is the only machine in my factory that has AB Devicenet.
My employer is willing to pay for the program, my only worry is that even with the software, I might not be able to work out how to fix it!

I have no problem configuring and installing Siemens Profibus networks, is it any harder than that?

Colin