1756-DNB, error #72 for no reason

Hi guys,
First post here but i really need your help on this Devicenet communication error. I have 5 electrical panels wired the same way, but one only of them is giving me this issue.

From RsNetworx diagnostic:
(No Read) Address 22, Indramat DeviceNet Slave DKC06.3-3, Device ID Check: Device ID Check error detected. [1]

The 1756-DNB shows at the same time errors #72 then #78. Couple seconds later, communications comes back OK.

The PLC is coded so if this error occurs, production line stops, and it's happening 4 to 5 time/day, sometime more. And it's never the same node. Sometimes there is more then 1. There is 6 Indramat Ecodrive 03 on this network. Nodes are 11-12-21-22-23-24

It's been like that for the last 3 weeks. I isolated the power of the loop on a powersupply. I raised the RPI of the 1756-DNB from 5ms to 10ms (all other 4 panels are at 5ms). The interscan delay is at 10ms also.

Pleasy any help would be appreciated.

dbernatchez, Welcome to the forum.

Perhaps this DeviceNet troubleshooting guide will help you.
http://copperhilltech.com/content/DeviceNet_Troubleshooting.pdf

dbernatchez said:

1756-DNB, error #72 for no reason

Click to expand...

That is, for no "apparent" reason. There will undoubtedly be a reason, or root cause here. Finding it is a step-by-step approach...

Are these 5 systems existing or just newly commissioned?

What Series hardware is the 1756-DNB compared to the other systems?
What firmware is the 1756-DNB running compared to the other systems?
Was anything "updated" to do with just this system?

The random error 72, followed by 78 is indicative of devices "falling off" the network where the are not responding to the scanner's polling rate in a timely fashion.

Depending on your answers to the above, one possible solution is to increase the Inter-Scan Delay (ISD) from the default 10ms to say 15 or 20ms. This should give devices on the network more time to respond in between polls.

Regards,
George

Check your power supply. if its less than 24V with a meter it might have lost some filtering. 24V has to be pristine on devicenet.

It is i double checked. I'm now monitoring as we speek to see if there is any drop when the fault occurs.

Thanks!

dbernatchez said:

...Should the RPI and the Interscan Delay should be the same?...

Click to expand...

No, not really. The Requested Packet Interval (RPI) in the 1756-DNB determines how often the scanner will exchange I/O data across the backplane with the 1756 controller. So the RPI is a delay interval on the controller side of the scanner.

The Inter-Scan Delay (ISD) is an idle period assigned in between each full scan of the network devices. When the scanner has finished polling the last device it will wait for the duration of the ISD before starting the next scan at the first node address device. This allows devices time to "gather their thoughts" before the next scan. If some devices are a little slower at responding or the network bandwidth is loaded then increasing the ISD in small increments may help. So the ISD is a delay on the network side of the scanner.

There is also the Expected Packet Rate (EPR). This assigns a timeout value for which each device that the scanner polls must reply within or else the device will be flagged as non responsive or missing. This timeout triggers error 72. At the next scan the device is polled again. If it remains missing, the error will change to error 78 for the device node address or addresses, as you are experiencing here. The EPR is default set to a value of "75" in the scanner and is, or should be, rarely adjusted. It is multiplied x 4 and converted to milliseconds which gives a default EPR of 300ms.

Another similar consideration is the baud rate for the network. Make sure that all device nodes, including the scanner, are set to the same baud rate. But this should not have changed if originally set correctly.

As your 1756-DNB is Series A and running firmware 4.x, it is somwhat older. So that would rule out some of the possible causes I was thinking of.

What LED indications are you seeing on any of the Indramat drive DeviceNet modules during this dropout period?

While we have been focusing on the hardware components and settings, have you double-checked the network cabling and in particular the terminations? Have you check any terminating resistor for good values? Have you consulted the link kuulkuum provided?

For similar support you can reference here...

15075 - Troubleshooting a DeviceNet Network
Access Level: TechConnect

Is it possible to swap the 1756-DNB out with a spare or one of the working scanners from another panel? (Careful if the Scanlists are not identical).

Can you likewise swap the DeviceNet option modules (DKC06) on the Indramat drives? (Careful if the node addresses are different).

Regards,
George