How to use Request/Reply communication pattern in LabVIEW RTI DDS Toolkit for LabVIEW

This solution is only a workaround until the Request/Reply API is available in LabVIEW. This will only work for one Requester and one Replier.

The Request/Reply communication pattern is pretty useful for industrial applications. It is quite normal to have an application requesting an action to another one and waiting for a response (requester role).

RTI Connext provides a Request/Reply API for many languages. However, that API is not available in LabVIEW yet. To work around this limitation, we can develop our own Request/Reply application. 

The current solution will only work in a one-to-one Request/Reply situation. This means that only one Requester and one Replier are allowed.

Example code requires LabVIEW 2013 SP1 or later and RTI DDS Toolkit for LabVIEW 1.1.0.88

Example application: Remote calculator

In the example provided, we have created a distributed calculator. The requester will send a numeric operation and an operator. The replier will do the operation between a sent operator and it's current value. Then, it will send the result back in the reply.

We are going to define our requests as an operation and an operator. Our reply, on the other hand, is going to be composed of an operation number, a flag indicating whether the operation was success or not, and the result of the operation if successful.

In the application, therefore, we have two main components:

Requester

This application (RequesterMain.vi) will request for a numeric operation to be computed in the replier side and wait for its response. Since the replier may not be alive, we need to provide a timeout time.

The requester is composed of a Writer of requests and a Reader of replies. Thus, in the subVIEW CreateRequester we return a reference to each of them:

In the main loop of the requester, whenever an operation button is clicked, we will create a new request and send it to the replier. To do this, we use the Event Structure from LabVIEW and we associate it with the "Value Change" of all operation buttons. Then, we use the Case Structure to select the operation depending on the button text and use that to create the request.

Once we have the request, we send it to the replier and wait for a response for a given time using the subVI (SendRequestAndWait.vi):

To end the execution, click stop. This will release all the resources used (requestWriter, replyReader and other internal DDS entities, for instance).

There is a very important detail to take into account, when we send a DDS request, it could live forever in the Writer queue, depending on its durability. If we send a request and the replier is not available, i.e. we need to wait longer than the time out, we should make sure that the request is deleted from the Writer queue. Otherwise, it could be sent to a late joiner request Reader and produce and unwanted result. In other words, we need to modify the durability of our requester DataWriter to be volatile. In the XML file provided, we have declared the following QoS:

<!-- Profile to be used with the RequestReply example-->
<qos_profile name="TimeOutReliableProfile" base_name="ReliableProfile">
     <datawriter_qos>
        <durability>
            <kind>VOLATILE_DURABILITY_QOS</kind>
        </durability>   
     </datawriter_qos>
</qos_profile>  

Since strict Reliability is not currently supported by the RTI DDS Toolkit for LabVIEW, we have also defined a ReliableProfile in our QoS. See this post to learn how to load a personalized QoS profile from LabVIEW.

Replier Application

This application will wait until a new request is received. Then, it will compute the operation between the current value stored locally and the operator sent. If the operation is success, it will send the result, a flag indicating success and the number of operations executed until the moment.

In this case, we need to create a Reader of requests and a Writer of replies.

It is important to make sure that the type name is the same between the request's Reader and Writer and between the reply's ones. In this example we have take care of this inside the Create subVIs.

In the main loop, we will have two parts. First, we will wait for a new request using ReadRequest.vi.

Then, whenever a new request is received, we perform the operation and reply using SendReply.vi. After that, we will go back to wait for a new request.

To end the execution, click stop. This will release all the resources used (requestWriter, replyReader and other internal DDS entities, for instance).