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 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.
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.