1756-IF16 Scaling Issue

Join Date
Jun 2005
Posts
54
Hello Friends,

I am using 1756-IF16 modules in a chassis with CNBR module to communicate with L63 CPU.
I did my channel configuration for 4-20mA for Float Data-Single Ended Mode - No Alarm.

My channel scaling is 0 to 160 DegC. I can read current scaled value as 30 DegC. But when I change this scaling range to 0 to 100 or 0 to 500 or anything other than 0 to 160, the scaled value 30 DegC is never changing. This is the case for all channels.

I tried to recycle the power for this rack, but same problem persists.

Could any one help me out here?
I appreciate all your help in advance!

Best Regards,

Pramod
 
I had same problem with IF8 card, so it may or may not help.

*Make sure the property setting on IF16 card w/ "disable Keying"
*.InRawMax for Ctrlogix 5000 software scaling should be 30800.
*In your case, .InEUMax should be 160.
Make sure .InstructFault is 0. If 1 is found, change to 0 for reset.
On Function Block programming, make sure to have alarm setup to take faults and reset it.
I hope it helped...
 
1756-IF16 Scaling Problem

Hello Doylen,
Thanks for your reply.

For scaling i have written PLC program as below:
IF INH_AI[0].AI_CONFIG_REQUEST
THEN RIO_01:1:C.Ch0Config.HighEngineering := INH_AI[0].AI_HI_SCALE;

RIO_01:1:C.Ch0Config.LowEngineering := INH_AI[0].AI_LOW_SCALE;
end_if;

IF INH_AI[0].AI_CONFIG_REQUEST
then
msg(RIO_01_S1_ModConfig_MSG);
end_if;

By this logic, I get new values upadated at 1756-IF16 module's properties-> Configuration tab -> High Engg and Low Engg.
Anyhow the Scaled value remains unchanged.

Best Regards,
Pramod
 
The scaling parameters are contained in the ":C" tag for the module, and are only ever written to the module once, when the controller makes its "connection" to the module (i.e. at power-up).

Therafter, any online changes to the data in the :C tag will not cause the module to be reconfigured.

If you must change channel scaling online, then you will need to use the Configuration tab in the module's Properties dialog box, remembering to click on "Apply" when done. This will cause the ":C" tag to be re-transmitted to the module, and the changes will be permanent.

If you want you can change the parameters offline, then download the whole program again to the controller, then the new values will be transmitted to the module, and the channel scaling will perform as expected.

If you need to change parameters programmatically (i.e. with program code), then you will need to set your parameters, then execute a special CIP "Module Reconfiguration" message to the module, which has the same effect as hitting "Apply in the configuration dialog.
 
Or if you are really desiring to rescale on the fly, set the card for maximum resolution and scale the value in code.

You could use an AOI to create a SCP instruction to do this.
 
Or if you are really desiring to rescale on the fly, set the card for maximum resolution and scale the value in code.

You could use an AOI to create a SCP instruction to do this.

Whilst I agree with this idea in principle, I believe it dramatically detracts from one of the best "features" of the 1756 Analog modules, that everything is (or can be) done inside the module, and everything else you do, (i.e. Process Alarms, Rate of Change Alarm), is specified in Engineering Units, and appears in the module tag as engineering units.

By doing what you suggest as an AOI, then all of the module's configuration parameters would have to be up-scaled, and the numbers appearing in the module's tag would be pretty meaningless without a dig into the AOI and its parameters. Anybody taking a casual look at the module tag would have a harder job understanding what is going on.

For clarity, I suggest the module is used as designed, then it will be a familiar scenario for anyone who has worked with them before. The MSG instruction for module reconfiguration would be transparently documentable, enabling all to see what is being attempted.

OP's code for reconfiguration looks as correct as i can tell.

halburgepramod are you monitoring the MSG tag to see if it is .DN ?
 
Last edited:
Being that the original poster did not specify what they were doing, I was offering another potential solution.

But I do agree that the module has much more to offer.
 
IF-16 Scaling

Hello Friends,

Actaully the logic is to scale the AI channel from HMI.

I missed to give correct connection of IF-16 module in the network for the MSG instruction for Module Reconfigure. Correcting this the scaling is working fine.

Thanks all!
 
Whilst I agree with this idea in principle, I believe it dramatically detracts from one of the best "features" of the 1756 Analog modules, that everything is (or can be) done inside the module, and everything else you do, (i.e. Process Alarms, Rate of Change Alarm), is specified in Engineering Units, and appears in the module tag as engineering units.

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 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"
 
mellis, I've just had other thoughts on this subject.

Your methods will preclude the use of using module data state change to trigger Event Tasks, because your channel data will not be scaled when the ask executes. To overcome that, you would have to put your scaling code in the event task itself, AND in normal code, so that the channels are always scaled for all the code to see. Now you've got 2 places to modify if necessary

Your methods will also make it impossible to use the CST or rolling timestamp features of the modules, where the data-change can be logged to mS resolution.

And lastly, as a programmer, you should always have in the back of your mind that yes, you may be totally at ease with what you are doing.

But the end-user, who will have to maintain the system for many years to come, may only have cause to go into the system sporadically. He will inevitably consult A-B documentation when he has a problem, and will scratch his head trying to figure out what you have coded, and even why !

You should be making his life easier, not yours, although I suspect you are having to do so much rung and tag documentation that you are out-weighing the "benefits" you get from being ablr to Copy/Paste your module configurations. (At least I hope you are fully documenting it !).
 
Last edited:
The config button doesnt show up for my module. I have 6 of them and it shows up for the first 4 but not for my last 2 modules. Is there something I need to do have this available?
 

Similar Topics

https://literature.rockwellautomation.com/idc/groups/literature/documents/um/1756-um009_-en-p.pdf In the above 1756-IF16 document on page 43, it...
Replies
8
Views
4,857
Hello folks, If I am using the 1756-IF16 Analog Input card to sense a 0 - 20mA input signal, in RSLogix 500, under the Module Properties -> High...
Replies
10
Views
7,158
I have a 1756-IF16 analog card setup for “Float Data, Single Ended, No Alarm”. The device connected to the analog gives a 4-20ma signal which...
Replies
7
Views
4,844
Hi Guys, Hoping that someone could please confirm if the 1756-IF16/B is/isn't compatible with the 1756-L1 5550 processor(13.24). I'm sure I...
Replies
2
Views
91
Hello, friends my 1756-if16 differential connection, has been used again (almost 10 years), the measurement value of each channel of the entire...
Replies
4
Views
949
Back
Top Bottom