Scripting Reply Messages

[Jonzarwal]

Hi all,

I've been using the new functionnalities for the actor framework in LabVIEW 2015. The shortcuts are really awesome and really well integrated in the environment.

I often use those two shortcuts :

- On an actor VI :

- On the message that call the method :

When I create an actor VI with inputs on it, then create an associated message, it automatically create the same inputs on the send message vi. That's great!

Now what I don't understand :

Why if i have outputs on my actor VI, the script does not generated an associated message of the class "Reply Message", with my outputs on the send message vi ?

Is there a good reason to not implement such a script into the LabVIEW environment ?

Because It's very painful to modify the inheritance and everything needed each time you want to use a reply message...

Thank you to share your point of view on this.

Jonas

[AristosQueue (NI)]

I do not believe we do a service to users by making it easy to create Reply Msgs. Most of the time, the outputs of your method should be created as a different method *for the receiver*. So if the method has outputs, the scripting tools do not know the intended recipient. Let the scripting tools create the message for triggering Method A. Then go create a method on the receiving class and then add a send in the Do.vi of Message A to send that new message.

OR add a parameter to your method up front that is a Message input of some specific type that inside the method you will send back to the caller and do away with the output parameters entirely.

Both of these require more coding, no question. Both of them are the things I strongly recommend every program do in the vast majority of cases rather than create a Reply Msg. If there's a good way to automate the scripting of one of those two solutions, we should do that, but making it easy to generate a Reply Msg without making it easy to do one of those two just leads people to bad solutions.

(Note: I have no problem making Reply Msg creation easy as long as the other two solutions are easier.)

[Jonzarwal]

Thank you for your answer. I trust you (even if i still don't really get why) that using Reply Msgs is not a good way to use the framework.

I understand the first solution but it couldn't be used in every situation as it is an async response.

Could you detail a little bit more your second solution ?

Also how you handle the situation in which you have Actor A that need to know (for example) the state of Actor B to decide which action to perform ?

Finally, the problem with that is that sometimes, my 'Actor A' isn't an actor, but just standard LabVIEW code, and my actor B is encapsulated into an API to be used by developpers that do not know anything about AF.

My API has to provide informations to the main VI (the caller), which is not an actor. How could i do that whitout Reply Msgs ?

[AristosQueue (NI) · Accepted solution]

Jonzarwal wrote:

Thank you for your answer. I trust you (even if i still don't really get why) that using Reply Msgs is not a good way to use the framework.

Have you had a chance to read the white paper that is included with the template projects? It goes into some detail about why Reply Msgs are discouraged. The short answer is

a) it means your actor is stuck waiting on someone else and can't respond to messages sent to it in a timely fashion, which can have ripples through your whole software's responiveness.

b) it opens the doors to deadlocks if you have multiple Reply Msgs in the system (A waits on B while B waits on A).

Jonzarwal wrote:

I understand the first solution but it couldn't be used in every situation as it is an async response.

Both of them are asynch responses. Asynch responses are what I am encouraging you to use. 🙂 Let me come back to this question in a moment.

Jonzarwal wrote:

Also how you handle the situation in which you have Actor A that need to know (for example) the state of Actor B to decide which action to perform ?

The goal is for A to not have to ask B because B has already told A when B's state changed. As long as B tells A "I just changed state" and A remembers that fact, then whenever A gets around to needing to know B's state, A already knows the state... A doesn't have to query anything.

This works even when "actor A" is actually other code. When you created Actor B, give it access to an event refnum or a notifier refnum or a control refnum or a global VI or <your favorite thing>. Whenever it changes state, it can report that state change through <your favorite thing>. When "actor A" actually is an Actor, that thing is the enqueuer.

Going back to the earlier question, there are a few variations on the second method. Here's one way:

1. In your current method X, you have inputs 1, 2, and 3 and outputs 8 and 9.
2. Create a new method Y that has inputs 1, 2, 3, and 4 and no outputs.
3. Inputs 1,2,3 are the same as on X. Input 4 is an Enqueuer of the actor who wants the reply.
4. The block diagram of Y calls X using inputs 1,2,3. and then takes the outputs 8 and 9 and calls "8 and 9 Results Msg.lvclass:Send.vi" and uses input 4 as the enqueuer.
5. Where did this magical "8 and 9 Results Msg.lvclass" come from? On your other actor, add a method called "8 and 9 Results.vi" that takes 8 and 9 as inputs and then create a method from that.

This is a high coupling solution. You can add abstract class to decrease the coupling if you wish. (See the white paper for discussion of high, low, and zero coupling if you're unfamiliar.)

Make sense?

[Jonzarwal]

OK, it make sense now.

I've been using AF for a while now and hav'nt read the white papers you mentioned. my fault 😕

I'll read them carefully to improve my practice.

Thank you again for you advice!