1756 Digital I/O modules v2.x

I was going through our spare parts to put together a 1756 rack of I/O to replace an old 1771 rack. About 5-6 of my spare digital cards are firmware V2.x. I understand from TechConnect ID494609 that because of ASIC differences, V2.x firmware cannot be flashed up to v3.x and vice versa.

That said, is there any issue with reusing these v2.x cards in my rack? My main concern is having to change the module definition if one of these cards ever breaks because it's a bear to take this system offline to download the program.

Thanks in advance.

If you disable keying, or perhaps even set keying to "compatible module", it won't matter what revision you put in, right?

rupej said:

If you disable keying, or perhaps even set keying to "compatible module", it won't matter what revision you put in, right?

Click to expand...

I'm pretty certain "Compatible Module" only allows for minor revision differences, not major rev., so that's out.

We could disable keying but that leaves us susceptible to Bubba. Haven't gone down that road before.

Also wasn't sure if there were quality issues with v2.x cards...

I could be wrong, but I always thought "disable keying" is still a keying of some sort. You can't plug an output card into a slot where there was an input and cause any more mayhem than just leaving it unplugged. The tree will still flag a compatibility issue.

I think with disable keying the data size and type still must match, if not it will still reject the module.

Also compatible keying should allow higher revisions to be accepted.

Compatible Module keying allows for any revision that is the same as, or newer, as defined in the General tab. That includes major revisions.

Using compatible keying and then defining a module as Rev 2.x will allow a replacement module to be Rev 3.xx or newer. The thinking being that you are likely to have an older module being replaced by a newer module and you want to be able to do that without any fuss.

Be aware though, that this setting forces the newer module to operate as if it were the older revision. What that means is that if there were any new features in Rev 3, those features would not be available.

If the module was defined as Rev 3.xx but the actual module was Rev 2.xx then the only option would be to disable keying. And yes, the "type" of module must match or else it will reject the module. An output for an input will fail.

Years ago I was working on a system that had been developed using some DC inputs and outputs. I was using the same system but using AC I/O and devices instead. The program I was given was for the DC system. I went in and disabled the keying since I was using the AC equivalent modules (IA16 versus IB16). The ControlLogix system was just fine with this. No errors whatsoever. But oddly, some of the AC input tags were flickering on and off on their own. I chalked it up to possibly a difference in the tag structure, possibly of the Configuration data. Once I had nailed down the reason for the problem, I just redefined the modules rather than investigate further.

OG

Folks, thanks so much for the feedback. I learned something new (to me) so that is always a good thing!

I came across the 1756-rn632_-en-p Digital I/O Release Notes which confirms what all of you said above. Looks like I'm good to go with compatible keying.

Onward & upward!