Up to FDT Specification
6.1 DTM Peer To Peer Communication 6.1.1 Establish a Connection between DTM and Device 6.1.2 Asynchronous Connect 6.1.3 Asynchronous Disconnect 6.1.4 Asynchronous Transaction 6.2 Nested Communication 6.2.1 Generate Systemtopology 6.2.2 Establish a Connection between DTM and Device 6.2.3 Asynchronous Transaction 6.3 Topology Scan 6.3.1 Scan Network 6.3.2 Cancel Topology Scan 6.3.3 Provisional Scan Result Notifications 6.3.4 Scan for Communication Hardware 6.3.5 Manufacturer specific Device Identification 6.4 Registration of Protocol Specific FDT Schemas 6.5 Configuration of a Fieldbus Master 6.6 Starting and Releasing Applications 6.7 Channel Access 6.8 DCS Channel Assignment 6.9 Printing of DTM Specific Documents 6.10 Printing of Frame Application Specific Documents 6.11 Propagation of Changes 6.12 Locking 6.12.1 Locking for Non Synchronized DTMs 6.12.2 Locking for Synchronized DTMs 6.13 Instantiation and Release 6.13.1 Instantiation of a New DTM 6.13.2 Instantiation of an Existing DTM 6.13.3 Instantiation of a DTM User Interface 6.13.4 Release of a DTM User Interface 6.14 Persistent Storage of a DTM 6.14.1 State machine of instance data 6.14.1.1 Modifications 6.14.1.2 Persistence 6.14.2 Saving Instance Data of a DTM 6.14.3 Reload of a DTM Object for Another Instance 6.14.4 Copy and Versioning of a DTM Instance 6.15 Audit Trail 6.16 Comparison of Two Instance Data Sets 6.16.1 Comparison Without User Interface 6.16.2 Comparison With User Interface 6.17 Failsafe Data Access 6.18 Set or Modify Device Address With User Interface 6.19 Sets or Modifies Known Device Addresses Without User Interface 6.20 Display or Modify All Child Device Addresses With User Interface 6.21 Device Initiated Data Transfer 6.22 Starting and Releasing DTM User Interface in Modal Dialog 6.23 Parent Component Handling Redundant Slave 6.24 Initialization of a Channel ActiveX Control 6.24.1 Supports IFdtChannelActiveXControl2 6.24.2 Does Not Support IFdtChannelActiveXControl2 6.25 DTM Upgrade 6.25.1 Saving Data from a DTM to be Upgraded 6.25.2 Loading Data in the Replacement DTM 6.26 Usage of IDtmSingleDeviceDataAccess::ReadRequest / Write Request 6.27 Instantiation of DTM and BTM
| 6.21 Device Initiated Data Transfer
Some protocols support data transfer services that are initiated by the device and not by the DTM. In order to support such services, following approach is recommended:
- the infrastructure (filter, service queue) for such services is initiated by a protocol-specific transaction request of the DTM, dependant on the protocol this service may be acknowledged or not
- the device initiated data transfer is transported by transaction responses to the initiating request (they carry the same invokeId)
- the infrastructure for these services is terminated by a protocol-specific transaction request of the DTM, which may carry the original invokeId as an attribute of the request xml-Document.

Device initiated data transfer needs management by the communication infrastructure.
That is why it is necessary to unambiguously to identify the request to initialize and terminate this type of behavior.
The TransactionRequest()s to initiated or terminate device initiated data transfer will transport protocol specific XML-Documents.
The terminating TransactionRequest() will contain the information necessary to terminate the device initiated data transfer.
This may include the invokeId of the initiating TransactionRequest().
If a DTM initializes such services, it is required to terminate these services.
The termination has to occur, before the DTM can go offline (DisconnectRequest() / Abort()).
If the connection is terminated by IFdtCommunicationEvents::OnAbort(), this service is terminated automatically.
The support of such services is protocol specific and device specific.
If a communication channel is not able to support this type of service, it will return a protocol specific error document in the OnTransactionResponse(), indicating that it is not able to support this feature.
|