02-04-2015 01:57 AM
Could you tell me how to create reply message on the request message from another Actor.
I have cylinder actor and the cylinder should simply report its state (Busy, Error) to the process that called it (send request). I want create abstract message for it. I don't know what I must create in my Actor 😞
Please help me 😉
Thank you.
-- Peter --
02-04-2015 10:32 AM
There's no automated way to make reply messages. Here's the steps you go through:
Now that you have done all this, stop and ask yourself AGAIN, "Am I REALLY sure this is a good idea? Am I absolutely sure that I cannot do this by sending a message to the receiver and then letting the receiver send a message back to the sender in its own time? Do I HAVE to create a synchronous reply message?" These wait-for-reply messages are dangerous, as I said above. You can read about them in many places on this forum and in the help for the Actor Framework that ships with LabVIEW.
02-05-2015 12:58 AM
To have asynchronous messaging and still get the replies you need, what is usually done is registering and broadcasting.
That means that the controller sends a message to the cylinder: "Register me for updates" with its own queue ref; cylinder keeps an array of actor queue refs that need to be updated; every time cylinder state changes, cylinder sends a "State changed" message to all the refs in the array. The controlling process can also choose to unregister and then cylinder removes its ref from the array. This way the controlling process knows the state of the cylinder at all times without locking the system with a reply message.
Good luck!
Danielle
02-05-2015 03:05 AM
In addition to the “Register-Notify” setup Danielle describes, one can also do an asynchronous “Request-Reply”, where the Request message contains the enqueuer of the sending Actor, and the Reply is sent as part of the “Do” method of the Request. This differs from the “Reply Msg.lvclass” that AQ described, in that the requesting Actor is not blocked waiting on the Reply.
02-05-2015 05:22 AM
Thak You 😉
08-19-2021 10:05 AM
So I realize that this is an old thread, but I have a question that seems very much related to this desire to have synchronous behavior with reply messages in an otherwise AF project.
I've got many projects which are testing a DUT -- think change a setting, then take a measurement. There might be 10s to 100s of such synchronous behavior built in to the test. However, simultaneously there is a desired to have the UI keep displaying the current measurements, create graphs, save data, etc. so it seem the project is mixed between asynchronous and synchronous. To have both asynchronous and synchronous, I was also (like the OP) thinking of using AF but with reply messages built in.
However, I was wondering about a second scheme - namely some kind of state behavior embedded in Root actor. For example, I first change my root actor state to "test mode" and send an async request to change a setting -- then based on the state being "test mode" when I receive the setting message back I send a second async request to take a measurement. When that measurement async message comes back, I record the setting and the measurement in the private data of root.
How should I consider the choice: (1) relying on reply messages (risk of deadlocking) or (2) state behavior? I'm not sure how to navigate this decision.
08-19-2021 09:12 PM - edited 08-19-2021 09:17 PM
I'd be tempted to try and write just one message for the situation you described, in which the action to be taken is "change a setting AND take a measurement, and then at your convenience send me an asynchronous message with the result".
A key part here would be that when the scheduler/root actor receives a result, it needs to know what test it is a result for, so you'd have to include that information in some manner in the non-Reply-Msg 'reply'.
A potential difficulty comes when you have many different settings, and many different tests - creating a message to send to your nested "test-do-er" Actor would be presumably prohibitive.
In this case, consider if you can create a class (or perhaps a cluster is sufficient) that represents all of the settings for the "do-er" (I'm going to write B next time...). B can then compare the new settings with the current settings, and only change the ones that are not the same (unless it is simpler and not terribly slower to just update all the settings every time, some hardware this is the case).
Then all that remains is to identify the test, an enum can manage this probably, although it might not be the most extensible if you are frequently adding new tests.
In that case, you could instead consider a class which has space for a result in the private data. B then runs the test, fills in the result to the object it received, and then sends the object back to the root actor (asynchronously). The root actor then knows which test it represents, especially if you include an "ID" field or similar in the data object.
Edit: I also note on re-reading the thread, that this is a rather more verbose explanation of what drjdpowell wrote in 2015. If you prefer videos to text, then he has several available, at least one of which covers the Request/Reply setup he describes (although for his Messenger Library, not Actor Framework, but the idea is close enough for it to be helpful here in my opinion).
08-20-2021 08:23 AM
Thanks for the reply! I realized after reading your reply multiple times, and my original question that I left out a key detail. Namely that "change a setting" and "take a measurement" will likely be undertaken by different actors. So the problem is getting multiple actors to do things synchronously.
That detail (my mistake for not including it) seems to modify the structure significantly and preclude me from pursuing your first suggestion, right?
08-20-2021 10:39 AM
@WavePacket wrote:
Thanks for the reply! I realized after reading your reply multiple times, and my original question that I left out a key detail. Namely that "change a setting" and "take a measurement" will likely be undertaken by different actors.
Hmm, that does make it more difficult. Is the different actors bit a hard requirement for some other reason?
You might have some better luck if you can avoid making the "make a measurement" actor an Actor - does it need to run asynchronously and hold state? If not, a simpler by-value class might be easier to handle, since then synchronous operation is more easy to reason about. This becomes problematic if lots of different things need to use it, but if that isn't the case I'd recommend considering it.
Otherwise you're stuck with either the use of Reply messages (at least from the setting actor to the measurement actor), or some confirmation via timestamps of the active set of settings, which would be tricky to be sure of. There might be better solutions, if I think of one I'll post again although probably someone else will post to correct me first 😉
08-20-2021 10:44 AM
Yeah, I was hoping to "live stream" measurements (actor controlling hardware) of a DUT (second actor controlling separate hardware) up to the user interface in the background, so I was presuming this would be best handled by AF.
Currently it seems then that the best way forward for me is synchronous reply messages in AF, which I realize that many people have caution away from. However, I don't see a better way forward right now...might be my ignorance.