PLC-5 Output Card 1771-ODD/B

Good day, all.

My Client has a PLC-5/20, in a 16-slot rack, single-slot addressing, DH+ network.

Rack 0, Group 0 has a 1771-AF fiber optic converter module.
Rack 0, Groups 1-6 have 120V AC/DC Input modules (1771-IAD).
Rack 0, Group 7 is a filler module.

Rack 1, Groups 0-2 have 120V AC/DC Input modules (1771-IAD).
Rack 1, Groups 3-4 are filler modules.
Rack 1, Group 5 has a 120V AC Isolated output module (1771-ODD).
Rack 1, Group 6 has a 120V AC Isolated output module (1771-ODD).
Rack 1, Group 7 is a filler module.

Here is the issue:

I can force all outputs (0-7 and 10-17) on the 1771-ODD in Rack 1, Group 5, no problem. In Rack 1, Group 6, I can force outputs (0-7) but I can NOT force outputs (10-17). We tried moving the module to R1/G4, 5 and 7 with the same result. We swapped the module out with another one straight from a new box with also, the same result. Short of removing the screws from the module and looking at the board itself, there do not appear to be any switches that would need to be set. The R1/G5 output module that i can force the outputs on also works in the other slots...

Also worth mentioning - The rest of the inputs and outputs in Rack 1 tested out fine.

Very strange that a module of the same catalog number in the same logical rack functions as intended, yet this one does not. Am i missing something very trivial here?


Please, if you have any idea what i can try or what this might be, let me know your thoughts.


Thanks,

Justin

Hello all. I was just giving this some additional thought. i am doing my forcing from the data table. is it possible that the logic that i have written could be preventing or interfering with the force from going through??

Can you Force the respective addresses via software (RSLogix 5)?

hello, dmargineau.

Yes, I tried applying a force at both the data tables and the actual coil in the logic, to no avail.

It is quite unusual...It really seems that you are the proud owner of two (expensive) duds...
Forcing is a software->controller->I/O immediate action.
If the module is functional under "normal" operation (application logic only), however RSL5 cannot "force" but half of the memory addresses no matter what R and G, it looks like a hardware issue or RSL5 version partial compatibility to the spare 1771-ODDs firmware.
When you say "I cannot force it" you mean that the output points do not turn on/off electrically or that the online software does not respond to the user's "Enable Forces/Force ON/OFF" commands?

I cannot say whether the module is functional under normal operation. i should have mentioned that I was attempting to force the I/O during a checkout procedure.

When i say i cannot force it, I mean the physical equipment, valve actuators in this case, do not open or close and the output status lights on the top of the module do not light up indicating an active point. The online software DOES respond to the enabling of the forces and the force on/off commands, but that is all that happens.

Well, in this case, it might be a wiring issue after all...
"Forcing" in automation world, means "bypassing" the application's logic results and using the user software in changing the states of exising I/Os (Data Table for Inputs, and Physical Output Points for "forced" outputs).
Is the field wiring arm used with the troublesome modules wired ap according to Page 5 of http://literature.rockwellautomation.com/idc/groups/literature/documents/td/1771-td146_-en-p.pdf ?
If using only one "hot", is the landing terminal "jumpered" to all L1-0 through L1-17 high side terminals?
Is the 120 V Neutral (Low) used to power up the non-functional field devices the same one as the one for the 120 VAC supply power used to energize the respective outputs?
The last question is very important: if Out 12 is powered up by PS Alpha then the very PS Alpha Neutral wire needs to be connected to the respective output device in order for the circuit to "close".
Isolated modules tend to be fed by diferent power supplies (that's the reason for "isolation"); I have seen "whites" randomly picked up in the field which did not belong to the same PS generating the "hot" applied to the solenoid.

I will have to verify your wiring questions when I return to the site. It appeared to be wired up correctly, but it is definitely worth another look. However, not to say that this is the "be all/end all," but when I force the outputs on the one card, each of the corresponding indicator lights on top of the module lights up. When i do this on the "troublesome" card(s), only the lights for outputs 07 light up and 10-17 do not. This, to me, says that the signal is not even being fired within the module, much less making it to the wiring arm. Am i mistaken in assuming this?

No you are not...And you are correct that there is no conditionality between the state of the field circuit and the point's indicator; the respective point's indicator is related only to the state of the respective memory address...
If the programming logic related to these points is True and the subroutine is being scanned, the outputs' indicator should be on...
Duds they are....

justin, have you tried the module from slot 6 in slot 5 ?

are you able to force outputs 10-17 when the apparent duff module is in slot 5, that we know works with the original module ?

if the module forces are ok when it is in slot 5, but not when it is in slot 6, it would indicate a chassis fault, not a module fault.

daba,

Yes, i have tried the module from slot 6 in three other slots (including slot 5) and still could not force outputs 10-17.

Does anyone else have any recommendations as to what this might be or what could be tried to resolve my issue?

Thanks,

Justin

Looking at the 1771-ODD Installation Manual, this module has an internal fuse for each output. There is also a Fuse Blown Jumper on the top right edge of the module printed circuit board that selects which mode, the STD standard preset default mode which turns on the module red LED for each blown fuse, or the CSI (Customer Side Indication) mode. In the CSI mode, the module "Input Image Table" also indicates the fuse status.

If the jumper happens to get switched to the CSI mode, and the module is used in complementary mode, then it will not operate properly.

!!! ATTENTION: Do not put the module jumper in
CSI mode when you use this module in a
complementary mode. Your system will not operate
properly.

Click to expand...

Thank you for your response, Lancie1. I definitely missed this when I was going through the manual. The fuse status for each output appears to be OK, but I will verify what the current setting of the jumper is for both the working and non-working modules and I will report back. Thanks again!

Lancie,

I had the folks at the Plant send me some pictures of the jumpers on the cards. They are all set to "STD." Complimentary I/O is not configured. All of the fuses tested out "OK."

I feel like I'm running out of options. Is it too far-fetched that two output modules would exhibit the same failure, or should we try to get a 3rd module to test? Is there anything else that could possibly be configured wrong on the module or in the software that would essentially disable outputs 10-17?


Thank you,

Justin