Accessing analog channels from an AB 1746-NI4 module

How do you set up a SQLTag’s OPC Item Path to access the 4 different analog channels from an Allen-Bradley 1746-NI4 module?

In Logix500, Data File I1 is shown as follows (with a radix=decimal):
I:1.0 1746-NI4 Analog channel 0
I:1.1 1746-NI4 Analog channel 1
I:1.2 1746-NI4 Analog channel 2
I:1.3 1746-NI4 Analog channel 3
I:2.0 16-Input (1746-IB16)
I:3.0 16-Input (1746-IB16)

For example, I want to make a SQLTag for channel 2, I:1.2. When I browse to choose the OPC item, I expand the SLC 505 device, expand the “I” Input folder and can choose I:1 – I:11. If I select I:1.2, the value for I1.0 (channel 0) is displayed as the tag’s value. In fact, any selection based on I:1.*, the tag will display the value for I1.0. If I choose I:2, then the value for I:2.0 (the first 1746-IB16) is displayed in the tag. What is the correct way to address the 4 analog channels in the 1746-NI4 card?

The plc is in rack slot 0, the 1746-NI4 is in slot 1, the two 1746-IB16 cards are in slots 2 and 3, slots 4 and 5 are empty and slot 6 is a 1746-OB16 module.

A less important question is, why does the OPC browser Input folder show that I:1 – I:11 are available?

I think there’s a bug in how the browser enumerates the input table, so all your questions are related.

If you use the OPC Quick client to watch all the Input channels and monitor the same in Logix500, you’ll see what I mean.

In your instance, I’ll take a stab that the analog channels are I:1 thrugh I:4. At least until this is fixed.

I have never seen a third party driver that works well reading/writing the I and O files in the SLC. I am not sure why RSLinx can address this information properly, but we have always made it a habit to copy all I’s to Bit or Integer files to be accessed by the SCADA system. I would suggest you copy your inputs to a intermediate N register.

Thanks for the suggestions. I have been on the phone with my customer this morning and discussed that very idea of copying the analog channel to another “normal” integer for monitoring.

It’s really not a bad way to go. Normally, an analog value is scaled to a “real world” value and stored in an N or F file.

On an related note, it does the same thing for fieldbus items like DeviceNet Would be handy to get this fixed for looking at discreet I/O. :unamused:

Hey all, I moved this from Knowledge Base to Design Help, which is the more appropriate place for it.


There is not a clean method to browse the actual I/O models that a SLC processor is configured for. We can detect that a module is present but cannot determine the type of module and how many words are associated with it. Allen-Bradley keeps the details of how to obtain this information proprietary and explains why Linx has support for analog and other types of modules.

There are a couple of reasons to copy the analog values to N or F files:

  • Values can be scaled to meaningful values.
  • Optimized communications. Each analog module that values are read form is a separate request. By grouping these all into a single N or F file allows for a single request. This just helps from loading down networks especially if using DH485 or DH+ networks.