DeviceNET problems/questions

maverick33

Member
Join Date
Dec 2005
Location
USA
Posts
36
Hello all,

I am having some trouble with a device net node and am hoping that someone can point me in the right direction. I am trying to interface a radio remote to a Control Logix processor. I am using a 1756-DNB rev 6 card and the radio remote is the only device on the network. I have used RSNetworx (revision 6) to set up the scan list and map the data but cannot seem to get the communications to hold. The communications seem OK for about 10 seconds then go off and I get a "Device Failure" bit in the processor and an identity failure in RSNetworx. The comms then go back to good for 10 seconds then fail again. I have checked and replaced the calbe several times and have ensured the terminating resistors are in place but still have not had any luck. I also checked out the ground connections and have tried several combinations of no grounds, grouded power supply (0 VDC) with and without the shield and drain grouded but am still unable to fix the problem.

Do anyone have any suggestions of things to check and or try?

Thanks in advance for any help.

M
 
What's the error code that shows on the 1756-DNB ? Is it 72, or 78, or something else ?

You might have to get a 1784-PCD card and the DeviceNet Traffic Analyzer to figure this out thoroughly.
 
Check and experiment with your I/O connection's Electronic Keying, too. It could take as much as ten seconds to establish a connection then tear it down when the keying doesn't match.
 
The error code on the DNB is 72. I will play around a bit with the IO connections to see if that makes any difference. Won't be able to get a chance until Monday but I will let you know if anything works out.

Thanks for the suggestions.

M
 
So I have tried to adjust the IO connection and electronic keying parameters but have not had any luck. The other thing that I noticed was that the fault only occurs when the processor is in run mode. I believe that this tells me that the cable connection is OK...Ken can you confim this? I assume that there is something not right in the DeviceNET config file that is causing this but I cannont seem to figure out where the problem is... any other ideas?
 
So this is getting a bit stranger... I was working with Logix version 15. I changed the firware back to revision 13 just to see if it would work and it did. Not sure why but I am still investigating. The other odd thing is that the node was working when the processor was in program mode and test mode but did not work while in run mode. The problem only seems to occur when I have the processor in run mode and the commandregister.run bit set. I am going to try rolling back the firware on the DNB card to see if it is specific to that as version 13 of logix doesn't have firmware rev 6 for the DNB card. I will disable electronic keying and set it to firmware rev 5 and see if there is any difference... will let you know...
 
The firmware revision of the controller should make no difference in the function of the DeviceNet bridge module, at least I've never seen a difference. Unless the controller is being programmed to do something unusual like Autoscan, I can't imagine any difference between V13 and V15.

The difference between Program and Run modes, combined with the Error 72, does tell us something.

Error 72 tells us that the I/O connection is being established, but then is failing when the slave device is not responding to the master polls.

Usually Error 72 indicates that a device has been unplugged from the network, and it is usually followed after about 4 seconds by an Error 78, which indicates that the slave device also is not responding to explicit messages.

The fact that you do not describe Error 72 followed by Error 78 means that your slave device *is* accepting explicit messages, and re-establishing the I/O connection.

The only difference between Idle and Run modes for a DeviceNet scanner is that in Idle mode the Output data length is zero. When you go to Run mode, the actual output data gets sent to the device.

Is there a chance you're sending a "reset yourself" command in the output data ?

I'd try increasing the Interscan Delay on the module from 10 milliseconds to 20, 30 or even 100 milliseconds. Maybe your slave device can't handle output data as fast as the controller is sending it.

Does your device have an ODVA DeviceNet certification ?
 
I will try increasing the interscan delay. I bumped it up a little bit but only to 50ms. I will put it a bit higher and see what happens. I have never seen an error 78 so it seems that this is related to the output data. I actually unmapped the output data to test things out but it did not affect anything...

I checked the programming and there isn't anything that is being sent to the device like a reset command. The only output bit is the commandregister.run bit. I have compared the programs from version 13 and 15 but did not find any differences so I am not sure why things were working when I changed it. I guess I will have to keep digging to find out why.

Again, thanks for you help, suggestsions and information. I will keep you posted on how things go...

M
 
This is definitely an abnormal occurrence. I really am stumped by the difference between V13 and V15 behavior; it shouldn't matter at all to the 1756-DNB.

Can you mention what version of -DNB firmware you are using, and what I/O size the connection to the slave is ?

Are you working with Rockwell technical support on this ? Have you talked to the slave device vendor ?

Send me an e-mail through my profile if you want to look at this in depth.
 
Two little technical details I'd like to mention in this discussion.

1. Modifying Interscan Delay can give slow slaves some extra time to react or stake out some extra bandwidth for COS connections or explicit messaging. But the downside is that you can get close to the Expected Packet Rate (EPR) for the connection. If a device doesn't see an I/O packet for longer than the EPR x 4 milliseconds, it will declare a timeout. For most I/O connections the default EPR value is 75, so they can go 300 milliseconds without a reply before a timeout is declared.

2. Mapping I/O to the image table of a Rockwell DeviceNet scanner (1756-DNB, 1747-SDN, etc) actually doesn't change any of the behavior on the network. As long as a connection is configured, the scanner is going to exchange that data with the slave device. If the data isn't mapped, it is simply discarded.
 
I am using a DNB with version 6.002 firmware. To get around this in logix 13 I disabled the electronic keying and put the DNB in as having firmware version 5. I increased the interscan delay to the maximum of 300 but this still didn't have any affect on the problem. The IO connection of the slave is 14 input bytes and 98 output bytes.

I have been working with tech support and the vendor but they are feeling stumped as well. They are supposed to be getting back to me today sometime with more information...

M
 

Similar Topics

Good day. I am a newbie and I need your help, I have a project but the problem is that I have never used the panelbuilder32 and I do not know how...
Replies
13
Views
3,183
Hello all! Our process controls guy took a job with another company and I'm the lucky guy that gets to try and fill his shoes. We have been...
Replies
8
Views
2,797
I'm currently working on a project that involves a device called a CAN-HET2 CANOpen to DeviceNet converter. This is for a wireless pendant belly...
Replies
0
Views
1,663
Greetings, I am new to this forum and I have a problem that may be trivial to most of you, however, it is eating my lunch. I tried to replace a...
Replies
4
Views
2,277
We have an AB SLC 5/03 that's been running since 1999 with a Beckhoff BK5200 connected to it. Just in the last month or so the BK5200 has been...
Replies
0
Views
1,532
Back
Top Bottom