Using program on chassis with inhibited modules in I/O list

Hello Everyone,
I wrote a program that I need to use on two different chassis configurations, where one has one less I/O Module than the other. I am using a compactlogix L24ER processor and RsLogix 5000 version 20 one both of them.

My expansion I/O configuration in RSLogix 5000 Expansion I/O on the larger Chassis
(4) 1769-OW8
(5) 1769-IF8
(6) 1769-IF8
(7) 1769-OF8C

The chassis that uses one less card doesn't have the number (6) I/O card. I was told by Rockwell that you can inhibit the (6) module and it won't look for it. The only issue I am having is that the (7) module is coming back with an error that says

(Code 16#0022) An invalid reply was received. Reply service code does not match the requested service code.

I have looked on the knowledge base and made sure the keying was set to compatible for that 1769- OF8C module, and the RPI was larger than it was supposed to, and even set it larger to no effect. This same module works fine in the program on the larger Chassis. It just doesn't on the smaller one where we need to inhibit the card.

I am trying to make sure I am not

1. mistaken that I am supposed to be able to inhibit a card in the middle of the I/O configuration list and it will work ok. The knowledgbase suggests it works for controllogix, in article 119883, and the guys I can immediately talk to from Rexel/Rockwell seem to think it should work, but they don't program all the time.

2. There isn't some other issue that could be causing the error unrelated to the whole module inhibiting factor.

I don't have another module to test with right now.

Any thoughts? Thanks.
Alfred

bump

This would work with a 1756 series ControlLogix chassis, but not with a 1769 I/O bus.

The 1769 I/O bus modules are numbered in sequence. When you remove the -IF8 module, the -OF8C becomes the module in Slot 6.

There's actually a module meant for exactly this circumstance, called a 1769-ARM Address Reserve Module.

But in your case the simple workaround is to have two different programs for your two different I/O configurations.

Can you swap your modules around?

If you can put the module that only exists in the one system as the last module, you will stop receiving errors for any following modules caused by the missing module in the other system.

A few minutes with search/replace (offline) in the tag database and ladder can have all of your I/O tags re-aligned, or do it in excel by exporting the tags to a csv file.

I'm not sure if you get the "I/O Not Responding" error for a missing inhibited module in CompactLogix, I can try it in ControlLogix, but that doesn't answer the question properly.

I wrote a program that I need to use on two different chassis configurations, where one has one less I/O Module than the other.

Click to expand...

Then I guess your program will be addressing the I/O whether it exists or not?

You can make that code conditional on the module actually being present. That will stop the processor doing things that are completely futile.

Thanks for the response Ken and Daba.
Ken - Thanks a lot for your answer. I wish that had been a little more clear in the manual for the compactlogix. I mentioned to Rockwell it would be nice for that to be more explicit rather than to hide it in the manual for the 1769-arm. We will end up going that route, since we already have one machine out there with the code for that card order. Unfortunately it isn't a simple workaround to have two different programs. The experience has been that it is too easy to fix a problem in one chassis type and to forget to fix it in another and realize too late that several machines you can't access now have issues on them, one in South America, another in Russia, etc. These two particular machines that have the two chassis types will number in the hundreds. And it gets exponentially worse when you realize that we actually have 5 models in the line. In any case, it is far better for us to have one code that will work for multiple machines. Also, although it stinks, it is actually far better for us to never alter the design of the system once we have the base. For example, if the original machine configuration works, we will stick with it because it is too easy to get engineering masters mixed up and wiring done wrong when there are multiple versions of the machine, and versioning is always a problem when troubleshooting. These things shouldn't be a problem, but after working at the OEM I do for 3 years now, I know it is just wishful thinking that it won't.
Daba- Thanks for your insight as well. Had I realized the problem was going to happen before the first machine with the first chassis had shipped I would have changed the card order, but not now that we have a working machine in the field. Again, having one off code is bad, and we would honeslty rather put an 88 dollar 1769-ARM card in to take the space of the missing IF8. Now that I know this will happen I would take the now obvious step of putting the cards that would not be needed on smaller machines at the end of the stinking list so this wouldn't happen. You don't actually get a I/O not responding error for inhibited modules, which is nice. No, the code won't address the missing card addresses if it isn't there. Everything is pretty modular in the code so it only accesses what is necessary to run the parts the machine actually has. In this case temperature and humidity sensors. If the sensors aren't there it doesn't look at those addresses or the code for those sensors that don't exist..

Thanks again for your insight.
alfred