Faults on Rockwell 1719 IO modules

[patjdixon]

I have Rockwell 1719-AENTR/A IO modules that are working and all the IO is tested. However, channels are reporting faults even though the IO is working. For example, the attached image shows a 1719-IBN8/A where a de-energized input shows OpenWire fault and an energized input shows Short Circuit fault. I don't see anything in configuration to fix this. It doesn't cause operational problems, but I don't like faults that aren't faults. Any ideas for addressing this?

 

[ASF]

I'm not super familiar with the 1719 series, but I'd take guess that both these inputs are "dry contact" type, e.g. a pushbutton switch, rather than e.g. a three-wire PE sensor or proximity sensor?


Open Wire fault is likely a feature designed to be able to tell the difference between "the proximity switch does not see an object and is therefore sending a 0 signal" and "someone has run into the proximity switch with a forklift and smashed the plug off the back, you have no proximity switch connected to your input any more."

Likewise, short circuit is likely trying to tell the difference between "your proximity sensor sees an object and is therefore sending a 1 signal" and "someone has run into the proximity switch with a forklift and your electrician has bridged out the input to get the machine up and running again, I now have short circuit between 24V and the input, instead of the proximity sensor I should have".

Of course, a pushbutton or switch is nothing more or less than an open wire or a short circuit, and so these diagnostics are of no real benefit to you. I'd be surprised if you couldn't disable those diagnostic features, if not at each individual point then at least at the whole card level. If you can disable them per point, you can just turn off the ones that don't have a suitable sensor connected to them, and retain the ones that do, to make use of that diagnostic feature.

 

[patjdixon]

I see no configuration options on the modules or channels. It is like these are designed to be in permanent fault condition. Very bad!

 

[robertmee]

I see no configuration options on the modules or channels. It is like these are designed to be in permanent fault condition. Very bad!

Sounds like you don't have them wired properly. From the manual

1719-IBN8B or 1719-IBN8 digital input module
If the input is used, for example, with a mechanical contact, an additional resistor circuit must be installed to ensure that the line fault detection function can work
correctly. Using the additional resistor circuit, the electronics can distinguish between a closed switch and a short circuit.

 

[ASF]

Ah, I just googled the part number and reminded myself that these are intrinsically safe I/O. That makes more sense. Yes, in the case of intrinsically safe I/O, it makes sense that you can't disable this feature.

A big part of being intrinsically safe is knowing that the circuit is intact and correct. Namur sensors have this functionality built into them, and if you use a dry contact type device, a resistor is used instead. You should put this resistor at the further point in the circuit - i.e. at the switch contacts in the field. This means that if there's a fault anywhere on the circuit, your module can tell you about it.

The basic premise is, if you have a switch, you put one resistor in series with it, and a different resistor in parallel. When the switch is open circuit, the input sees the resistor in parallel, and knows that the circuit is healthy, at least as far as the position of that resistor. If the switch is closed, you won't just see a short circuit; you'll see the resistance of the resistor in series, so the circuit knows it's not just been short circuited, it's been operated correctly. The attached screenshot from the manual shows exactly this, and gives you appropriate values for the resistors.

 

[cardosocea]

That makes more sense. Yes, in the case of intrinsically safe I/O, it makes sense that you can't disable this feature.

A big part of being intrinsically safe is knowing that the circuit is intact and correct.

Your picture begs to differ as plenty of barriers allow you to use them safely without line monitoring.
The premise of the intrinsically safe circuit is precisely that it won't spark when the two ends of the circuit touch (there's a slight caveat that two circuits may spark between themselves). Hence why a switch is considered simple apparatus when powered from a barrier.

I'd say a big part of explosion protection is knowing the installation is in good condition... and in that aspect, intrinsically safe systems are the least onerous on the maintenance side at least.

I'm a bit disappointed with the lack of configuration of this feature as it means that you have to fit resistors inside the case of the switch to make use of it (it's pointless fitting them in the panel) and a lot of switches aren't made for this or are fiddly as is to wire up, much less with two resistors in place.
Edit:

After pulling up the manual it states:

"Line fault detection can be enabled or disabled by checking or clearing the Enable Diagnostics checkbox in the Add-On Profile."

I don't think this will be per channel though, but don't have Logix open here to see.

 

[ASF]

Your picture begs to differ as plenty of barriers allow you to use them safely without line monitoring.

You're right of course - and likewise here, as your edit states, you can disable it (I checked and the "enable diagnostics" checkbox is per input, not per card).

My statement about it being important to know the circuit is correct and intact was a bit of a broad sweeping statement, but at the end of the day it's moot because you can, as we discovered, turn off the diagnostics if you don't agree with my sweeping statement!

 

[cardosocea]

Sorry, I didn't mean to sound rude or arrogant. Your statement was perfectly correct about IS but also every other type of protection other than perhaps positive pressure or immersion.

Quite chuffed that it can be disabled per channel... I'm looking at installing a few of these in the next couple of years.

Do you know, or even considered, whether the actual modules can be swapped with P+F branded ones? It's Rockwell, so the answer is likely no, but I've always wondered whether the module is the same (with a different external colour).

 

[ASF]

No offense taken! I should know better than to make broad sweeping statements on a forum like this anyway. I'm surprised Geospark hasn't shown up yet to provide an even more in depth analysis of my post and the issue

I didn't know P&F had equivalent modules - I've used a lot of P&F IS equipment, but it's always been standalone rather than a whole I/O rack. Most of the IS work I do is small scale and doesn't justify whole IS I/O racks. If you do find out more, I'd be interested to know!

 

[cardosocea]

I didn't know P&F had equivalent modules - I've used a lot of P&F IS equipment, but it's always been standalone rather than a whole I/O rack. Most of the IS work I do is small scale and doesn't justify whole IS I/O racks. If you do find out more, I'd be interested to know!

The Rockwell modules are just rebranded P+F. I believe they took in CEAG and their remote IO. I've used it repeatedly with siemens as they make a network adapter that talks Profibus and Modbus (ethernet and RS485)
My doubt is whether Rockwell provided the know how for the network adapter and the remote IO backplane bus is still the same as used in the P+F units or if they enforced compatibility to Rockwell branded parts.

It does give me a lot more hope that Rockwell won't just end that family of products since theres little work for them and the development is done by P+F who are leaders in this particular field.

I will definitely have to install these in a project next year and have some friends with P+F... so I'll definitely have a go at it.