Devicenet error

[rwraley 1]

Does anyone know off hand what the error code "F78" on the devicenet module indicates?. I did some research in the Knowledgebase and the only thing I found was that the code indicates "Slave device in scan list table does not exist" but this is in reference to a 1747 SDN. Are the codes the same for Control logix devicenet modules?

[TimWilborne 108]

All the Devicenet error codes are the same as far as I know. I think THIS manual will help you. Is it erratic or a constant error? What do the indicators on the device say? What is the device?

[pseudoquas 1]

I recall that the most likely cause of a "78" error on DN is that a DN node is simply powered-off somewhere. On the scanner module, the offending node number should follow the display of "78" in an alternating fashion. If several devices are turned off, then a succession of "78"'s followed by each of these node numbers will display. Probably, you have a Motor Control Center containing Variable Frequency Drives, each of which is connected as a DeviceNet Node. A Drive is either tripped or powered off, I'll bet, which would as a consequence power-off the associated DN slave module. Perhaps somebody has locked-out a DN remote rack somewhere, or locked-out a Drive. A less likely cause is that a DN slave module has died, which I have seen a few times as well. The fun part is finding the offending node, especially if your plant electrical schematics do not indicate node numbers. Hopefully, it is just a tripped Drive, which is easy to find. Side Bar: Each Slave Node Module/Card has up to 3 LED's, all of which should be steady green, especially the comm LED. I vaguely remember that Slave may go into a "bus off" condition which, though green, will be indicated by the comm LED flashing green (though I'm less sure about this one -- been a couple of years since I had to deal with DN). Anyway, a Bus-Off condition can be cleared by cycling power on the slave. Red LED's or unlit LED's on the Slave means a sick Slave. Edited 16 Aug 2006 by pseudoquas

[Ken Roach 194]

The error number and the node number are displayed in sequence on a DeviceNet scanner. On the 1756-DNB they are accompanied by "N#" for node number and "E#" for error number. There is never an "F". Error # 78 indicates that the scanner module is trying to establish or re-establish communications with a slave device. Usually Error 72 occurs first, indicating that an I/O connection has failed, followed several seconds later by Error # 78 when the scanner cannot re-establish communications. Of course, the most common cause for this error is simply that a device is unplugged from the network.

[TimWilborne 108]

Another mistake I made one time was not properly setting the address with the rotary switches on a replacement. I swapped the most signifigant and the least signifigant digit.

[rwraley 1]

I don't recall seeing the node number flashing in sequence behind the error code. The problem is very intermittent and occurs 3 or 4 times each day. Ken, it must be E78 and not F78 the scanner is above my head by about 2 ft and I probably didnt see the bottom segment in the "E". I have checked all the nodes and adapters for solid connection and all seems well. The issue is probably that this is rotating equipment and sends the comms over slip rings (wich seem ok) .

[TimWilborne 108]

Need to know the node number to narrow it down. If it is too erratic then add code to monitor this tag Local:X:S.DeviceStatus[Y] X = Slot number Y = Node Address. When you get the E78 on the display the corresponding tag from above will have a value of 78. Is this a new or existing machine? Any changes been made recently?

[pseudoquas 1]

comms over slip rings?.....Ohhh...very bad. One big problem with devicenet is that if the signal is not clean, clean clean and/or if the power is not tightly regulated and/or if shield grounding is not absolutely perfect, then the network will give you all sorts of trouble. Been there....done that. I'm surprised, though that you are not getting alternating error and node info on the scanner LED. 7X type errors I recall always refer to scan list node problems. I have to go home and dig up my handy DeviceNet quick ref manual to confirm. Edited 17 Aug 2006 by pseudoquas

[rwraley 1]

It's not a new install. It's been running now for about 3 years. We have had various problems in that time with the devicenet comms due to grease on the rings, bad adapter modules and also a bad Devicenet cable but this internittent problem is something new. The only way that we can recover is to cycle the processor out of run and back again. When we do this the problem clears and all is well for another few hours. The other thing that is strange is that it only occurs after 2:30 in the afternoon so I was thinking it might be related to the incoming Edison service dropping voltage a little as the demand increases. I will throw a recorder on that today to see if it is a possibility. On a different note what would be an alternative to running the network over slip rings for rotating equipment?

[Ken Roach 194]

Cycling the run mode of the controller should have no effect on the communication status of a slave device. The 1756-DNB handles all of the connection establishment and recovery on the network and all it does with the controller is bridge messaging and exchange the I/O and status data files. You also describe a display behavior that is not normal, that is, a static error display with no alternating error number. You're going to have to get a good look at the 1756-DNB display when this happens. Looking inside the status tags would also be helpful to find out if this is one slave node that is failing to communicate, or a network-wide failure.

[rwraley 1]

The reason we have to cycle the processor is because the system monitors the devicenet status tags and when the error is detedted it shuts down the process with related code. The processor is actually being faulted and that is why we need to cycle run mode. Being that the comms are over slip rings I think that when the equipment returns home due to gravity after the fault the comms are re-established (maybe?) and all is normal, but if what you are saying is when the comms are re-established the 1756-DNB should return to a run state regardless of the processor that is not happening. It did not happen today before I left work so I didn't get a chance to observe the DNB display but I instructed the night guy to not clear it until he writes everything down. As far as it being a single node or system wide the panel view is communicating via devicenet and it seems to be fine. Edited 17 Aug 2006 by rwraley

[TimWilborne 108]

By the processor faulting do you mean the Red fault LED on the PROCESSOR is lit? We need to determine which nodes are doing this. What are the other devices connected to the network?

[rwraley 1]

It jsut dawned on me why the panel view is fine there are two 1756-DNB,s in the rack and they are handling different parts of the system. The only devices on the bad network are 2 flex I/O adapters(nodes 1 and 2). The good network has 4 drives and a panel view. The problem is that you can't get anywhere near the Flex I/O adapters until the equipment is stopped and by that time everything is cool except the processor and the DNB displaying the E78. I am leaving on vacation for a week and wont have time to post further until I return and I will dig in and go online to monitor tags and have the exact display data for you all. I really appreciate all the responses and we can pick it up next week.

[TimWilborne 108]

Have a nice vacation