1769-IF4 Not working but no faults in module properties

Hello. I'm dealing with a 1769-IF4 module with the "OK" light OFF. Data is not updating in RSLogix5000 - no change when inputs are connected or removed. (we're using 4-20mA in % range and verified the 4-20mA inputs are live). There are more modules past this one on the bus and they are working.



However, in RSLogix 5000, there are no faults in the module properties screen and no PLC major faults and only some unrelated overflow minor faults.













There is a Fault register associated with the module, but the manual doesn't seem to describe this register, and I'm not sure how to read it. Some of the bits are set, but I'm not sure how to determine their meaning.





Is the module actually bad? or does the system just need to be power-cycled? Why aren't the faults being reported?



Any suggestions welcomed.
Thanks

Not sure if it is unrelated, but could you share what the faulted rungs are doing? There might be something causing the controller to put the card offline.

The faults are being reported, but they're minor faults, so it's not halting the processor.

Hi Robb. I'll check but I'm almost positive these faults are caused by unrelated math operations (flow totalizers etc) not related to this analog module.

Robb B said:

Not sure if it is unrelated, but could you share what the faulted rungs are doing? There might be something causing the controller to put the card offline.

The faults are being reported, but they're minor faults, so it's not halting the processor.

Click to expand...

There is nothing* you can do in your ladder logic that will cause the card to go offline.

In the manual you linked it states the following with regard to the OK LED:

On: module has power, has passed internal diagnostics, and is communicating over the bus

Off: Any of the above is not true.

Click to expand...

Make sure the module has power on the +24V dc and dc NEUT terminals (and while you're at it, mentally slap the engineer who decided that "dc NEUT" was the correct way to label that terminal). If it does, the card has either failed internal diagnostics, or is not communicating over the bus. In that case, you've most likely got a faulty card.

If you suspect a faulty card, I would first remove and reinstate the card, making sure the connection levers have fully engaged on each side. I'd also check that the rack arrangement is correct as far as power supply distance ratings and power supply loading is concerned. If all of that checks out, I'd order a new module.

*OK, so it is possible to use SSV tricks to inhibit modules or possibly even configure them into a state where they might be considered "offline". But that's a very deliberate action, not one that might inadvertently be done with some dodgy math instructions.

Ok, I will start off by saying it's an input module, which *could* be attached to multiple controllers. I'm sure that is not the case here, but if it is there's tons more you need to know.

If the OK led is off, it means that the module has never made a connection to any controller since power-up. Check the configuration of the module in the I/O Config section of the project organiser.

If the OK led is flashing, it means that the module is no longer "connected" to any controller it was previously connected to. On a working network, the only way I have seen this happen is if you pull the controller who "owns" the module.


Your fist port of call is the online module "properties" dialog, this should show what the issue is, it might just be a bad electronic keying setting, rendering the module invalid.