Actor Framework Discussions

cancel
Showing results for 
Search instead for 
Did you mean: 

Multiple actors using the same reply message

Solved!
Go to solution

Hi there,

 

I recently started using the actor framework and I am currently using it on a project. This project aims to develop a visual inspection machine for lenses. In the image below you will see the current actor messaging diagram.

Ongelofeloos_0-1674558513637.png

 

I want to reach the following goal:

The Stream actor is used for acquisition of images from the camera. The Measurement Executioner, Snapshot Dialog, and more actors will request images from the Stream. They can do this by sending a 'Grab Image' to the Image Acquisitioner. The Stream actor will then create an image, wait for an event that the camera has acquired a new image and then send it back to the actor which requested the image.

 

What I have now:

I don't know if there is some kind of morphological polymorphic messaging that knows to which actor to send the reply depending on the enqueuer. So I made a work around, currently the requesting actor creates the image and sends the image reference to the Image Acquisitioner. Then the requesting actor keeps checking until the image has been updated and goes on one's way.

 

Is there a better solution to this?

 

0 Kudos
Message 1 of 12
(2,962 Views)

Why not just include the requesting Actor's Enqueuer in the original request (alone with the image reference)?  Then your Stream Actor can send a reply message to this Enqueuer.

0 Kudos
Message 2 of 12
(2,942 Views)

@drjdpowell wrote:

Why not just include the requesting Actor's Enqueuer in the original request (alone with the image reference)?  Then your Stream Actor can send a reply message to this Enqueuer.


Because each Actor Class will have their own reply message method which is not shared/polymorphic between the classes.

0 Kudos
Message 3 of 12
(2,939 Views)
Solution
Accepted by topic author Ongelofeloos

Then attach the reply message as well as the Enqueuer.  Stream Actor sends that reply message to the reply Enqueuer when the image is ready.

Message 4 of 12
(2,907 Views)

If you use LV2020, an interface for Image Acq. may be a solution. Define in it an abstract VI for sending images and a message for it. Implement this IF in each actor that receives an image. Add the enq. of receiver when it requests images from the Image Acq. actor and reply with the abstract message to the enqueer.

 

If you use older LV version a zero or low coupling approach may help.

Message 5 of 12
(2,906 Views)

@drjdpowell wrote:

Then attach the reply message as well as the Enqueuer.  Stream Actor sends that reply message to the reply Enqueuer when the image is ready.

 


How did I not think of this.

@p4keal wrote:

If you use LV2020, an interface for Image Acq. may be a solution. Define in it an abstract VI for sending images and a message for it. Implement this IF in each actor that receives an image. Add the enq. of receiver when it requests images from the Image Acq. actor and reply with the abstract message to the enqueer.

 

If you use older LV version a zero or low coupling approach may help.


I still need to make the switch to LV2020 or later, but this sounds like the ideal solution. Would be nice to start experimenting with interfaces without having to hassle with abstract messaging. For now I will accept @drjdpowell 's solution.

0 Kudos
Message 6 of 12
(2,894 Views)

AF has a self addressed message class. I don't realy understand how it should be usefull in current form, but if you add an accessor for the message, you can read the message, set some attributes, and send it.

Message 7 of 12
(2,888 Views)

Why 


@Ongelofeloos wrote:

Because each Actor Class will have their own reply message method which is not shared/polymorphic between the classes.


Is there are reason why the reply messages don't have a common ancestor?

 

I do something similar in one of my own frameworks. I have a dialog actor that collects input (a string) from the user. That dialog actor defines an abstract "String Response Message" (this was developed prior to the existence of labview interfaces). When any subactor wants to request user input, it sends a message to the dialog actor with it's own implementation of the string response message and a reference to its own enqueuer. The dialog actor can then collect the user input and send the response message to the requestor. This sounds very similar to what you've described so far, just substitute your image for my string.

Message 8 of 12
(2,885 Views)

@zsmorison wrote:

Why 


@Ongelofeloos wrote:

Because each Actor Class will have their own reply message method which is not shared/polymorphic between the classes.


Is there are reason why the reply messages don't have a common ancestor?

 

I do something similar in one of my own frameworks. I have a dialog actor that collects input (a string) from the user. That dialog actor defines an abstract "String Response Message" (this was developed prior to the existence of labview interfaces). When any subactor wants to request user input, it sends a message to the dialog actor with it's own implementation of the string response message and a reference to its own enqueuer. The dialog actor can then collect the user input and send the response message to the requestor. This sounds very similar to what you've described so far, just substitute your image for my string.


They do share the same ancestor. I just forgot that I could also send a response message with the enqueuer.

0 Kudos
Message 9 of 12
(2,879 Views)

Another way that I've solved this is to have the Stream and Image Acquisitioner actors just broadcast images indiscriminately (ether by interface Msg or loosely/zero-coupled Msg) and leave it up to the receiving actors to decide whether the want to process the newly acquired image or not.

 

One advantage of doing it that way is that the requesting actor isn't coupled and doesn't need to know anything about the Stream (or any other) actor - it simply receives information that it can either process or discard. This makes it easier to test actor subtrees in isolation.

 

The disadvantages are that this takes more memory (though in my experience it hasn't made a difference) and that time synchronization for specific actors can be trickier. YMMV...

CLA CLED AF Guild
0 Kudos
Message 10 of 12
(2,838 Views)