Helliana said:
... For your 1734, if your 8bit card was installed in slot one, the address of input0 would be "Lift:1:I.0"
Not quite Helliana. These Point I/O configurations can be tricky.
jimlongusa said:
We have added a 1734 AENTR point I/O EIP Adapter with a 1734-IB4 8 Input Module. IO adapter is labeled "Lift". What should the addressing format look like?
Would my first address be Lift_In:I.Data[0].0?
Careful...
1734-IB2 = 2 Input Module
1734-IB4 = 4 Input Module
1734-IB8 = 8 Input Module
So you either have a 1734-IB4 Input Module and it's actually 4 Inputs you have or you actually have 8 Inputs and it's a 1734-IB8 Input Module you have?
Either way...
You also have to be careful with the module-defined tag structures when defining 1734 Distributed Point I/O. Depending on the "Chassis Size" configured for the 1734-AENTR adapter, the module-defined data types for the adapter will vary. For my working example, I have a 3 Slot Distributed I/O configuration which includes the adapter (0), a 1734-IB8 (1) and a 1734-OB8 (2). So the adapter's Module Definition is set to Chassis Size: 3. This automatically creates the specific module-defined data types:
AB:1734_3SLOT:I:0
AB:1734_3SLOT:O:0
Both these module-defined data types contain two single DINT members for "SlotStatusBits0_31" and "SlotStatusBits32_63" respectively. But we'll not worry too much about those here. There are also certain Configuration data types created but likewise, I'll not mention those in detail here. The above two module-defined data types also contain a SINT[3] array member called "Data". This is what we want to focus on.
Because the Chassis Size is set to "3", both the Input and the Output module-defined data types are given a "Data" SINT[3] member. When we now look at the module-defined tags for the actual I/O under Controller Tags, we should see, and to use your example:
Lift:I (Data Type - AB:1734_3SLOT:I:0)
Lift:O (Data Type - AB:1734_3SLOT:O:0)
Again, you may see other Configuration (C) tags there but ignore them for now.
If we expand Lift:I we should then see:
Lift:I
[+]Lift:.SlotStatusBits0_31 (Data Type - DINT) < just showing for clarity
[+]Lift:.SlotStatusBits32_63 (Data Type - DINT) < just showing for clarity
[+]Lift:I.Data (Data Type - SINT[3]) < this is what we want
If we expand Lift:I.Data we should see...
Lift:I.Data
[+]Lift:I.Data[0] (Data Type - SINT)
[+]Lift:I.Data[1] (Data Type - SINT)
[+]Lift:I.Data[2] (Data Type - SINT)
These are the three SINT[3] members added to the module-defined data type for Input data for the 3 Slot Chassis.
Now for the important part...
Because the adapter is in the Slot 0 address, any Input data the adapter itself may have will be mapped to the Lift:I.Data[0] SINT.
Because the Input Module is in the Slot 1 address, any Input data which it may have will be mapped to the Lift:I.Data[1] SINT.
And because the Output Module is in the Slot 2 address, any Input data which it may have will be mapped to the Lift:I.Data[2] SINT.
Therefore, whichever Slot an I/O module is located in; its Input data will be be mapped to the corresponding SINT member within the specific Chassis Size module-defined data type.
The same can be said for the Output data.
It's not always immediately obvious to some where your actual I/O data is within the Controller Tags. So knowing the above will help to narrow this down for a newly created configuration. Once found, you can of course name the I/O SINT member something meaningful, such as "Actual Module Input Tags" or whatever suits.
Quick working example (I've not expanded the SINT members to show the individual I/O points)...
Regards,
George