The machines in general are controlled by a Allen-Bradley SLC500/03 processor.
Have a Device Net Controller 1747-SDN connected to several Beckhoff BK5200 Device net modules.
I have checked the configuration of the A-B 1747-SDN module for error handling and proper control for safety shutdown in the event of Device Net errors.

The RSLogix control program reflects this also.
However we have discovered that in the event of a BK5200 experiencing physical separation from the connected I/O that the I/O remains in last state and the processor never gets an error over the Device Net. The only way to get a Device Net error is to unplug the Device Net Bus plug.

During this the I/O "ERROR LED" on the BK5200 is blinking at a "panic" rate.
The machine vibration tends to "disconnect" the modules. Pulling and reinserting usually clears the error.
We have had a couple of mistimed indexes resulting in equipment damage. Heat circuits to run to dangerous levels.

I have Purchased Beckhoff's KS2000 software and tried different configurations for resetting inputs and shutting off outputs, however I would feel much better if I could "see the error" at the SLC processor.

 

Unless the BK5200 stops responding to I/O polls, there's no way for the 1747-SDN to detect a failure of the Beckhoff I/O bus.

Does the BK5200 have any status data that is included in the I/O connection, or is accessible via explicit messaging, which would indicate I/O module disconnection?

Many I/O platforms do; A-B FLEX has a module status word included in the Input Data Assembly that most people find annoying, but does indicate if a module gets disconnected from the adapter.

I did find a Beckhoff application note, APP-NOTE 500017, that describes setting an outputs-OFF safe state with the BK5200. That might be the simplest thing to do right away.

 

I have installed over 400 Beckhoff modules with there DeviceNet. Some are installed on mobile equipment which really gets bounced around. I have never seen a problem even close to what you describe on a running system. I suggest you look very closely on the contacts on the BK5200 module and all the others in the stack for damage, corrosion, etc.

Most often I have seen the I/O error when a module is not plugged all the way in after assembly or being replaced. Perhaps there is something about your DIN rail that the modules are not clamping to it properly.

I also find it interesting that you found that output modules remained in there last state. We changed from Automation Direct to Beckhoff for DeviceNet drops because of this problem. I have never seen Beckhoff make this mistake yet when there is loss of communications or any of several different problems.

As for the scanner reporting errors other than loss of communications this problem is not unique to Beckhoff. Not reporting errors seems to me to be more of the rule than the exception. I always tie an input to an output on the drop, toggle the output, and run a watch dog clock on the input.

 

The Automationdirect Devicenet slave card has a dip switch option as to what you want it to do when the slave gets no updates from the master, shut off the outputs or have them remain in their last state.

 

I am not sure about how the Beckhoff I/O works on a DeviceNet network. However, there should be a status byte that you can monitor via DeviceNet. By monitoring the bits in this byte, you should detect if the node is having any problems.

This will not solve your problem of the outputs staying on when there is a failure. Once there is an I/O failure, the node should go off-line and you will not be able to write to the outputs. There are I/O systems out there that can be configured in the initial setup that will help to solve your problem. This configuration can consist of:

1) Leaving the outputs hold their current state,

2) Turning all the outputs ON or OFF,

3) Setting a predifined state for the outputs (ie, setting some of the outputs ON and some of the outputs OFF).

Setting up this configuration is actually quite simple when using the RS software.

Also, I am aware of the issue of the modules losing communication with the buscoupler in the past. This issue was prior to 2000. If your modules are older than the year 2000, you may want to replace the modules and the buscoupler.

[email protected]

 

I have looked at the Beckhoff EDS file and unfortunately they do not have very many options like many of the other DeviceNet products that are available. The only thing that I can come up with is for your DeviceNet Master to monitor the status byte that should be coming back from the Beckhoff device. When there is fault at the node, a bit should change within the status byte. This will mean that you will have to make some programming changes.

[email protected]

 

This is a summary on the issues with the K-Bus Fault. I am not sure if this is a normal report to a posting, as this was my first. I have used this site many times in the past and always found an answer in reviewing other questions and replies that were similar to mine.

It was a twofold problem. The OEM had built some machines prior to 1998 when the BK-5200 coupler did not report K-Bus faults. As new machines were built a "cut and paste" approach too much of the programming and layout was applied to the new machines. Therefore, no programming was in place even if the BK-5200 supported the error report. The issue, with not being able to "see" the breaks on the machine was due to "looking" in the wrong area for the K-bus status byte. After reviewing, some of the Beckhoff application notes and how this area is mapped shed much light on the subject. The Scanner card was in slot 2 of the machine and the NetWorx software default view is for slot 1.

This has been a very educational experience. Setting up and correctly mapping a Device Net network with different vendors products; throw in some older firmware issues with the BK-5200 coupler on a few units and you have my dilemma.

One machine has been programmed and tested for K-bus faults. Additional programming and HMI reporting has been added. This machine had one coupler to be replaced due to old firmware. Now if a K-bus fault occurs the machine stops and reports the fault location.

The issue of the BK-5200 couplers finding their way into a fault mode remains. The general quality and fit of the I/O seems to leave a bit to be desired.

Thanks to each response on this issue.

Wesley H. Moore