allen-bradley 1791ds failures

Hi guys,

We are having a fairly large number of AB 1791DS safety block failures. Is anyone else experiencing this, and if so, what did you find?

The units are actually made by Omron (DST1-ID12SL-1, DST1-
MD16SL-1/XD0808SL-1) but relabeled as Allen-Bradley 1791DS-IB12 and 1791DS-IB8XOB8 respectively.

Other questions:

1) Can these be repaired?

2) Is there a better unit that we could be using instead?


Thanks,

John

Can you describe the nature of the failures ? Can you put a number on "fairly large" ?

Is the power supply section failing, the network section, the input, the output, the safety connection.... networked safety modules have a bunch of things that have to go right for them to work.

Have you pursued a root-cause failure analysis with RA ?

We don't use the 1791DS but we do have a couple of the 1791ES that have been running fine for two years. Not much data to go on.

How exactly are they failing? Are they losing communications, inputs faulted, outputs failed, exploding into huge fireballs?

There is a Product Notice out on these guys (466362). "These modules could fault during operation or during the module's power-up sequence. Anomalies noted include module communication loss, bus off detected fault, output power status fault, input power status fault, and other anomalous status LED events. Occasionally, power cycling these modules may temporarily correct the anomalous state. "

They also say: "1791DS-IB8XOBV4, 1791DS-IB16, 1791ES-IB8XOBV4, and 1791ES-IB16 are categorized as Repairable Product. 1732DS-IB8 and 1732DS-IB8XOBV4 are categorized as Consummable Product."

They have had quite a few with problems as the MTBF (as measured by field returns) is around 40000 hours for the 1791ES.

I like the newer POINT I/O safety modules because they are easily expandable and configurable. Don't have much more on reliability vs. block i/o.

I have not used the safety IO but have had occasions in the past where some DeviceNet modules (ie Armorblocks) have suffered repeated failures. The cause has generally been failure to ensure that the 0v line and shield are tied to each other and ground. This can lead to excessive voltages between one of the data lines and ground resulting in transceiver failures. Proper installation is always the key to a good DeviceNet system.

I haven't been out on many of the calls when one fails, but I think that the block takes down the DeviceNet network. I plan on hooking up the dead ones to try to figure out what the failure mode was.

As for connecting the ground and the shield together, just in one place, right?

As for number of blocks, I can account for six at the moment, but all told, it's probably 15 - 20 blocks.