Transition from sync to async messaging

[railang]

Hi all.

I would like to write a VI for data acquisition that sends a message and waits for response before continue processing. Of course, I can use a sync message for this. But this forces me to do the entire acquisition using sync messages. This is not an option, as the rest of the system is designed for async communication. I have tried to create an actor that receives a sync message, remember the answer-queue and does the further acquisition using asnc messages. This is not possible, because I do not have access the reply queue of a sync actor message.

Is there any way to implement the transition from sync to async communication "the AF way". E.g. without modifying the actor framework or send my self-created queue around?

Thanks

Rainer Langlitz

[auspex]

Here's what I do.

I have various actors for data acquisition (Instrument) and an actor which manages those actors and aggregates data from them (Instrument Manager). The Instrument Manager is the caller for each Instrument, so each Instrument sends data to its caller; there's no need to provide an enqueuer reference for replies.

The Instrument class has a method Begin Acquire, which takes two arguments: a Report Data message and an integration time. There is also a message called Begin Acquire Msg for invoking this method.

The Report Data message is an abstract message for the Instrument class. The implementation of Report Data is provided by the Instrument Manager class. The abstract message just provides acquired data and some debugging information. The Instrument Manager's implementation includes when the message was sent, to which instrument it was sent, and to how many instruments it was sent; this information is not accessible from the Instruments, and is used to aggregate data.

Because of the extra information in the implementation of Report Data, I have to provide the message anew every time Begin Acquire is called. I might otherwise provide the Report Data message (e.g. with a method Set Report Data Msg) to the Instruments only once, as I believe the Measurement Utility does.

When Instrument Manager sends the Begin Acquire Msg message to each Instrument, it does not block waiting for replies. Those replies will come as Report Data messages later. When an Instrument receives the message, it stores the Report Data message and begins acquiring data. When it is done acquiring data, it uses the stored Report Data message to send the data to its caller, the Instrument Manager.

The Begin Acquire method is not the method that sends the Report Data message back to the caller. If that were so, I'd call it Acquire and my Instruments would be unable to do anything else while acquiring data. (The integration time may be milliseconds or minutes.) Instead, they have, at present, two strategies for collecting data while remaining responsive for adjustments, cancelation, etc. One is my old way, before I switched to the actor framework, so I'll not bother describing that. The other is that each Instrument also has a sub-actor just for blocking tasks. The interaction between any Instrument and its Blocking Task Actor is similar to that between the Instruments and the Instrument Manager, but much simpler. The reply message for the Blocking Task Actor never changes, and its Acquire method sends that message to the Instrument.

I hope this helps you. It helped me because I found a bug while I was writing it. 🙂

[railang]

Thank you for this detailed description. But this does not work for me. Let me explain how ist works, maybe I'll find a bug too

My system has two VIs for data acquision or provision: "Set Signal" and "Get Signal". Both have a "Signal Name" as an input. This name identifies the data point I want to read (get) or write (set). Accordingly the VIs have a data output or input. These two VIs are used in TestStand sequences or applications as the entry point to read or write data on remote RIO/PXI systems running RT.

The Get and Set Signale VIs must work sync. But the RT acquision system is async, because it is processing multiple queries on multiple TCP connections.

If I do communicate over network, the TCP connection reference is the "my queue" I pass around to switch from sync to async processing. Now I want to do some very fast processing directly on the RT system. And I want to avoid the TCP overhead because I am already in the application that controls the instruments. Consequently the implementation of my "Get and Set Signal" on RT needs to switch from sync to async within the actor framework.

The current workaround is to use TCP to localhost and live with the network stack overhead. My second option is to implement my own "Reply Message", what does not modify the AF. But I wonder if there is really no solution using only the AF.

[justACS · Accepted solution]

You're right, you do have to step out of normal AF relationships to do what you're trying to do.  You'll need to build some shim code to make it all work.

Create a proxy actor that sits between your device actor and the synchronous API.  The proxy talks to your device actor as normal, but shares a set of references (queues, notifiers, DVRs, etc.) with the API.  The API launches the proxy actor, which launches your device actor as a nested actor.

Set Signal sends a value to the proxy actor via a message.  The proxy forwards the new signal value to the device actor, also with a message.

When the device generates a new value for Get Signal, it sends it to the proxy via a regular message.  The proxy then puts that value on the queue (if you need all of them) or DVR or notifier (if you just need the most recent value).  When you invoke Get Signal from TestStand, it flushes the queue (getting several values all at once) or reads the DVR/notifier.

This scheme avoids the problem of reply (synch) messages, since the API vis never have to wait for the proxy actor to respond.

[railang]

Thank you niACS. This is a pretty elegant solution.

[justACS]

Thanks.  I stole it from Aristos Queue.