View Full Version : DeviceNET problems/questions
July 21st, 2006, 06:30 PM
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.
July 22nd, 2006, 01:14 PM
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.
July 22nd, 2006, 01:26 PM
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.
July 22nd, 2006, 03:23 PM
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.
July 24th, 2006, 10:55 AM
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?
July 24th, 2006, 04:34 PM
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...
July 24th, 2006, 04:57 PM
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 ?
July 24th, 2006, 05:49 PM
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...
July 24th, 2006, 07:07 PM
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.
July 24th, 2006, 07:10 PM
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.
July 25th, 2006, 10:22 AM
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...