I respectfully disagree that doing everything inside the module is desirable. I admit, on my first ControlLogix project I did the scaling on the card in engineering units. It seemed really cool.
Problem is, it's a pain to enter the data and it's a pain to modify later. As the OP found out, if you want to configure scaling from the HMI, it really makes life complicated. The same applies to alarm trip points etc. Triggering module updates is not simple or desirable . The whole module stops communicating, not good . Besides, it's self inflicted complication , just avoid it.
After many projects, this is my preferred setup. Scale on the card to 4.0 to 20.0. Scale in software to engineering units.
Benefits:
Makes it easy to setup so scaling can be modified from HMI. I like to use a UDT. You can make an AOI if you like, I don't have a problem with a CPT for each channel.
Intial setup is much easier because you setup one card then copy the configuration to all other cards. No more tedious keying in the values for each channel. And then doing it over during checkout when things invariably change.
During checkout, the raw value is in milliamps. If you are going to set the card scaling to the same value for all channels, this is by far the most useful scale.
My two cents
I'll deal with the higlighted comments above.
0. "it's a pain to enter the data and it's a pain to modify later" - can't see that myself - having configured several hundred controllogix analog channels over the last 10 years, i don't find it a pain to set them, or modify them if need be.
1. "Triggering module updates is not simple or desirable" - what could be simpler than to trigger a "Module Reconfiguration" message in the code after setting the values to the
Location:Slot:C tag elements. And what is undesirable about it, they've enabled the update feature via CIP service codes just for the purpose.
2. "The whole module stops communicating, not good" - no it doesn't. From the help text - "
Use the Module Reconfigure message to send new configuration information to an IO module. During reconfiguration :- Input modules continue to send input data to the controller. Output modules continue to control their output devices"
3. "Besides, it's self inflicted complication" - i believe the opposite, that hiding the scaling in code is a self-inflicted complication. If I want to see a channel's scaling, I would naturally look at the channel scaling parameters in the module configuration dialog. Besides, if you are doing scaling in the code, you will stop reading analog inputs while in program or fault modes. That information may be being MSG read by another controller !!
The issues you raised with "on-the-fly" reconfiguration are non-existant, and your methods will involve a lot of unnecessary code, which is obviously wasteful in terms of memory used (not much of an issue i agree), and scan times, which may be more of an issue in time-critical applications, such as motion.
Your methods will also detract from one of the most useful techniques in Logix5000, that is
Aliasing to the real I/O tag.
A maintenance engineer, who may not be as adept as you at deciphering your scaling code, will have a hard time debugging a fault like "The temperature reading has gone high". With aliasing he can simply look at the "Temperature" tag in the code, or in the tag database, and see exactly which channel on which card it is wired. He also knows (or may read in the manuals) exactly where to go to find channel scaling or alarming data, and can cross-reference from there to see where in the code it may be updated.
In short : "self inflicted complication"