Actor Framework Documents

Showing results for 
Search instead for 
Did you mean: 

Proposal for Asynchronous Callback Messages in the Actor Framework


This article proposes an extension of the message handling in the actor framework. It will discuss the possibility to send the results of a message, subVI’s error cluster and return parameters, as asynchronous callback message to another actor from within the actual message, but not the public subVI.


The design is illustrated in the context of CS++. An InstrSimCtrl caller actor requests a measurement value from InstrSim callee actor and displays the result in a one button dialog.


CS++ is a set of LabVIEW libraries extending the NI Actor Framework with features focused on commissioning and test of distributed systems not only in Big Physics experiments. The example and CS++ library sources are published under the terms of EUPL v1.1

Active Participant drjdpowell Active Participant
Active Participant

I recognise the messaging pattern you are using here as "Async Request-Reply with Continuation"**.  The "Continuation" here is your "Async Callback Message".  It is a natural extension of this pattern to have "Register-Notify (with Continuation)", where (rather than replying just once) the Callback Message is sent whenever some defined "event" happens.   Have you considered extending your work to include such a thing?


**I describe messaging patterns here.

Member HB@BNT Member

Thank for your interest and review(?).


No, we don't plan an extension to "Register-Notify (with Continuation)". Several proposals already exist for that purpose.

Within CS++ every CS++Actor publishes its state to shared variables. Any other CS++actor can subscribe to a SV
by launching a nested CSPP_PVMonitor and registering a derived message of CSPP_PVUpdate. This message will be send to the caller actor on SV change carrying the SV value. This procedure is simplified by the generic CSPP_PVProxy and its associated configuration.


The purpose of our proposal is to asynchronously receive the return parameters of the the public VI called by message, only. Meanwhile the CS++MessageMaker was extended to generate such asynchronous messages using VI-Scripting.
Furthermore the 'Send' can be called from any non actor VI or even from Teststand and the message can be dispatched to the addressed actor, also by name, across application boundaries and network using VI-Server.


Best Holger

Active Participant drjdpowell Active Participant
Active Participant

If you already have a Shared-Variables-based system then I understand why you wouldn't want to develop a system of Register-Notify.  Though I personally would argue that Shared Variables are not Actor-Model like and thus an odd fit for Actor Framework.

Member HB@BNT Member

I agree with your last sentence. 


Our CS++ libraries extending the AF focus on easy test and commissioning of distributed systems for controls for experiments at GSI. Configuration and instantiation at runtime are important. And we want to make use of as many NI SW tools as possible, e.g. DSC Modul for alarming and trending. So, by using SV/DSC we get many features nearly for free. 


Further more we are using abstract process variable connections in the application layer. Derived classes implement the concrete communication details. So, we can support several protocols which is important in heterogeneous environment at GSI. We do support also DataSocket and DIM,, at this time. 


A 'Register - Notify' we could add if necessary. In fact, we are thinking how to include notifications in the AF to avoid message pileup in the command queues. Imagine to subscribe to high rate data/image acquisition when a statically subset is sufficient for online analysis.

We had for seen this from the beginning in our old CS, but how to implement notifications in an elegant way into the AF without to much programming overhead for the developer? Using SV with buffer size equals 1 and suitable Polling Interval solves this problem for now if data size is small enough to avoid problems with the shared variable engine. 


Best Holger 


Member Fire

I took the question concerning an implementation for the 'Register - Notify' pattern to think about in more detail.


Extensions to the functionality described in the PDF document attached to the original post made a straight forward implementation possible by extending the PVProxy-PVMonitor concept with derived classes using notification as process variables. The result can be found in the 'Notifier' branch of the CSPP_Core submodule,


Since I am about to leave for vacation this extension is not jet complete and not tested. This will be done in October 2019.