IFdtCommunication::TransactionRequest() method information

M&M FDT 1.2.1 Online Specification
IFdtCommunication::TransactionRequest() method information

Interfaces and Methods - Schemas - FDT Specification - Quicklinks - Abbreviations

4.5.3.8 IFdtCommunication::TransactionRequest()

This method can be called in the states:

HRESULT TransactionRequest (
[in] FdtUUIDString invokeId,
[in] FdtXmlDocument fieldbusFrame,
[out, retval] VARIANT_BOOL* result
);

Description:

TransactionRequest performs asynchronously exchange of a data structure with a device specified by the fieldbus frame.

Parameters:

invokeId	Unique identifier for the request
fieldbusFrame	Fieldbus-protocol-specific information to be transferred, specified by a fieldbus specific schema e.g. like FDTHARTCommunicationSchema or FDTProfibusCommunicationSchema

Return Value:

result

TRUE Request sent FALSE Request refused

Behavior:

The method passes an XML document with communication parameters specified by a fieldbus specific. Based on this information the method sends the request for data exchange to the next communication component or to the connected device and returns without waiting for the result. In case of more than one pending request the association of request and response is done by the passed invoke id. The client is responsible to pass a unique invoke id for the specified communication link. The response will be provided by OnTransactionResponse(). If a TransactionRequest() is called as part of a sequence definiton and the given SequenceTime is expired, the return Value has to be false.

Comments:

It depends on the fieldbus protocol which internal communication methods are implemented at the communication channel. For example HART supports data exchange methods while Profibus offers read/write services. Developers of Communication channels should not expect that there will be only one pending request for a certain device at one time. For instance several clients (e.g. frame application and Device-DTM’s) are trying to retrieve information from same device. Developers of Device-DTM’s should consider that the used communication infrastructure creates delays in the communication. So the Device-DTM’s should limit the number of communication requests. Also the Device-DTM must be able to handle a refused request, since there may be a variety of reasons to refuse a transaction request. Even if the underlying fieldbus protocol allows sending only one request at a time to one or more devices, Communication channels must be able to manage a number of requests. It is expected that the requests are processed by the Communication channel in the order received if not specified otherwise by the protocol.

© by M&M Software GmbH, parts of this website taken from FDT Interface Specification Version 1.2.1, © by FDT Group, AISBL.
This website is published for support of M&M products as granted in license conditions, chapter 2.1.
Last updated 2015-02-05 15:17
Email: FDT Technical Support Line.