Data table structured address
A data table structured address is a data structure that some RSLinx Classic functions use to define a communication path.
All RSLinx Classic functions that accept a structured address parameter use the DTSA_TYPE structure.
The following types of structured address are defined in the DTL.H file for use with CIP:
- DTSA_AB_CIP_CONN (RSLinx Classic only)
- DTSA_AB_CIP_PATH (RSLinx Classic only)
- DTSA_AB_DH_CIP_PATH (RSLinx Classic only)
DTSA_AB_CIP_CONN
This structured address identifies a CIP application connection in a CIP system. The structure's template is:
struct {
unsigned long
atype
;long
driver_id
;unsigned long
dwConnection
;};
where:
atype
is the address type. The atype
constant for this structure must be DTSA_TYP_AB_CIP_CONN.driver_id
is a small integer assigned as a handle to an RSLinx Classic driver via a DTL_DRIVER_OPEN call made by the client application. Valid values range from DTL_DRIVER_ID_MIN to DTL_DRIVER_ID_MAX as specified in DTL.H.dwConnection
specifies the CIP application connection identifier, which is obtained via a DTL_CIP_CONNECTION_OPEN call made by the client application, or via a DTL_CIP_APPLICATION_CONNECT_PROC callback.DTSA_AB_CIP_PATH
This structured address defines a communication path to a module in an CIP system. The structure's template is:
struct {
unsigned long
atype
;long
driver_id
;unsigned short
wControl
;unsigned long
dwLength
;unsigned char
baPath
[1];};
where:
atype
is the address type. The atype
constant for this structure must be DTSA_TYP_AB_CIP_PATH.driver_id
is a number assigned as a handle to an RSLinx Classic driver via a DTL_DRIVER_OPEN call made by the client application. Valid values range from DTL_DRIVER_ID_MIN to DTL_DRIVER_ID_MAX as specified in DTL.H. If RSLinx Classic itself is to be addressed, then DTL_GetRSLinxDriverID should be called to get the driver_id
instead of DTL_DRIVER_OPEN.wControl
is a bit mask used for device- or network-dependent information. For current versions of RSLinx Classic, this should be set to zero.dwLength
is the number of bytes in baPath
.baPath
is a buffer that contains a sequence of path segments or symbolic segments which define the port and link address for each link in the path to the target module. The format required to specify this system address is described in the Logix 5000
5000 Data Access Programming Manual (publication 1756-PM020-EN-P). See also Understanding CIP Paths.As defined in the DTSA_AB_CIP_PATH structure, this buffer is only one byte long. If more than one byte is required to specify a path, the buffer must be extended, in which case some means must be used to guarantee that nothing important gets overwritten (via a union, for example, or an adequately sized
malloc
).DTSA_AB_DH_CIP_PATH
This structured address combines a CIP communication path to a 1756-DHRIO module with a PCCC offlink route for the 1756-DHRIO module to use. The structure's template is:
struct {
unsigned long
atype
;long
driver_id
;unsigned short
wControl
;unsigned char
bLocalDST
;unsigned char
bDLSAP
;unsigned short
wDLink
;unsigned short
wDstn
;unsigned char
bSLSAP
;unsigned short
wSLink
;unsigned short
wSStn
;unsigned char
bLftm
;unsigned long
dwLength
;unsigned char
baPath
[1];};
where:
atype
is the address type. The atype
constant for this structure must be DTSA_TYP_AB_CIP_PATH.driver_id
is a number assigned as a handle to an RSLinx Classic driver via a DTL_DRIVER_OPEN call made by the client application. Valid values range from DTL_DRIVER_ID_MIN to DTL_DRIVER_ID_MAX as specified in DTL.H.wControl
bLocalDST
bDLSAP
wDLink
wDstn
bSLSAP
wSLink
wSStn
bLftm
These members are all essentially identical to those in a DTSA_AB_DH_OFFLINK. They define a PCCC offlink route originating at the 1756-DHRIO module.
dwLength
is the number of bytes in baPath
.baPath
is a buffer that contains a sequence of path segments or symbolic segments which define the port and link address for each link in the path to the 1756-DHRIO module. The format required to specify this system address is described in the Logix 5000
5000 Data Access Programming Manual (publication 1756-PM020). See also Understanding CIP Paths. An additional byte must be appended to this path to specify the DH+ channel on the 1756-DHRIO module for which the offlink portion of the DTSA applies: for Channel A, this byte must be a 2; for Channel B, this byte must be a 3.As defined in the DTSA_AB_DH_CIP_PATH structure, this buffer is only one byte long. Because more than one byte is required to specify a path, the buffer must be extended, in which case some means must be used to guarantee that nothing important gets overwritten (via a union, for example, or an adequately sized
malloc
).Provide Feedback