1756-DNB Seeing no devices

I am working on converting some machines from SoftLogix5800 to ControlLogix. The original system used PCI ControlNET cards and CN2DN for deviceNET. The CN2DN have been replaced by 1756-DNB cards in a controlLogix chassis.

Three of these machines have been converted and all work fine. The last machine has 2 cells that refuse to communicate over deviceNet. The deviceNet was working with the CN2DN modules, but will not work with a DNB card. We get everything from "Bus Off", "No TX", and "No Rx" displayed on the card. The baud rate is set to the same baud rate used by the CN2DN. We even tried the other 2 baud rates without success.

We made up a short deviceNet cable and connected directly from the DNB card to one of the 1794-ADN modules. As soon as it is plugged in, the card displays Bus Off Detected. The ADN is a series B which is the same as in the other 3 machines that work without problems. We replaced the ADN with a new series C module and it works.

We then took our deviceNet cable and plugged it into the PanelView. It gives us a No TX error and will not show up in RSLinx or RSNetworx. We even conneted the isolated cable to an Engel servo drive, it would no communicate either. We put in a new DNB card, no difference. Even tried a series D and series E DNB module, no difference. Restored DNB card back to factory default, still no difference.

It seems that all of these deviceNet nodes have been configured in a way that will not allow it to work with a DNB card. Could this be possible?

Bus off errors, indicates problems on the outer wires...power supply, or wiring itself.

Many severe errors require power cycling the device, and one device can kill a network so you may find simply one of hte devicenet nodes is faulty and the other errors may clear when it is "unplugged". Note that you must move termination resistors if end nodes are involved.

You said "we then took our Devicenet cable", and problems followed it...tell us more about the cable.

The original cable is a thick deviceNet cable and that was the very first suspect so we pulled about 15 feet of AB thin deviceNet cable off a new spool to use for testing a single node at a time.

This machine consists of 2 press cells, a finishing cell, and a central cabinet for hydraulics. The finishing cell and central cabinet work fine, but neither press cell will work. To validate our thin deviceNet cable we were testing with, we plugged it into a node in the central cabinet and it worked. To eliminate power supply or grounding problems, we had taken the 1794-ADN completely out of the press cell, powered it from the finishing cell power supply, and it still would not work.

Once we put a new ADN module in the press cell, that one node would work, but none of the others work. The press cell has 3 ADN modules, a panelview, 3 Engel servo drives, and a vario IO block. We used our test cable to isolate nodes and no matter which one we plug into, it doesn't work.

Everything you are describing is consistent with mis-matched Data Rate settings. When you have a number of devices from different workcells or areas and start plugging them into one another without being certain of their data rate configurations, you can have this sort of goose chase.

Fortunately the 1756-DNB clearly states the data rate it's set for when you boot it up. So you can be certain about that.

The PanelView terminal also will show you what data rate it's been configured for.

The 1794-ADN can be tricky, because the default is "Autobaud" but that feature can be turned off and a hard data rate set using the DeviceNet Object (usually the Node Commissioning Utility). Even when a -ADN adapter is set for Autobaud, it will detect a data rate and keep it until the next power cycle, so moving a network from one Scanner to another can cause baud rate conflicts.

If you plug a 1756-DNB at 125 kb/s into a 1794-ADN at 500 kb/s, you'll get a mix of No Rx, No TX, and Bus Off faults (usually a few of the No Tx/Rx, until packets actually collide and generate a Bus Off).

A large number of the 1756-DNB's I've found purchased on the aftermarket were damaged with high voltage and quietly sold instead of scrapped. These followed similar narratives; modules of unknown history generated Bus Off errors immediately upon being connected to the network, no matter what the slave devices were.