Accessing Actor Object Data within Event Loop?

[hecmar.arreola]

I've been studying this template a lot lately.  I love the concepts of the actor framework, but have yet to impliment anything using it.

Now I have a straight forward project that I think I could use with this, but I'm hung up on something.  I like this event driven Actor Core framework (the default for what you designate as the "beta" task in the template wizard).  One issue I see, however, is that the actual object data is not really that accessible inside the loop structure.  I guess I'm not really sure I understand how this is executed.  Can I read and write Object data (such as the "stop signal" reference) from within my loop and event structure?  If I do, how should I make that data accessible to class VIs?

As an example: I want to utilize this template to build a "Data Logger" actor. It seems appropriate to me to create a string variable named "File Name" as part of the data in my "Data Logger" object.  I would then create a VI that would store the "File Name", and then turn that into a message that my calling Actors can use to set this "File Name".  But I call that "set File Name" function asyncronously to the "Actor Core" vi which is already running the event processing loop (see image below).  So running my object line into that loop would be fruitless (I think) because it wouldn't be able to talk to the outside VIs.  Does any of that make sense?

[hecmar.arreola]

Also, that note at the bottom about not using property nodes... is that only property nodes of UI elements that would cause the whole UI to load?  I don't like how throughout the template there is no use of accessors for the object data.  I prefer making property defintiions that are my accessors and using them, but that note makes me hesitant.  Surely only UI element property nodes is what it is referring to...?  Thanks for your feedback.

Even through an object method I think an accessor should be used to access that object's data.

[dsFlux]

Nickerbocker

I'll take a closer look at this and get back to you some time later today.

[hecmar.arreola]

Hi - Thanks!

I've been thinking about this problem a lot.  I think that the best approach is to use this design pattern as a parent actor class that polls and executes on events children actor methods.  That way, every time the children actor method fires their VIs have access to the most recent object data.  Does that make sense?

I'm not sure my original question makes sense, so I'm going to try and restate it for clarity (hopefully): I like this design pattern and want to use it but I am troubled by the fact that object data is inaccessible within that event loop.  My understanding is that once that event loop starts, if I send a message to that actor with the event loop as its actor core the message may update data in my object but that data will be inaccessible inside that event loop because it will already be running and there doesn't appear to be a mechanism to update the object data within it.  (mouth full... let me know if I need to clarify some more).

[elset191]

Basically it sounds like you understand why any data set by a message sent to that actor isn't accessible from within the loop.  Because the actor wire heading to the loop is branched from the one going to the actor core I think of it as basically two different instances of that object.  Anything that happens to the object inside the actor core by messages will not be seen in that loop.

This has gotten in my way a few times.  I haven't tried yet, but I think if you have a DVR in the class you should be able to get around that.

Additionally, I have put references to controls in my class before the branching occurs, and update the value of what I want using that reference.  My accessors then become an unbundle to get the reference, then a value property to get the data I want.  I don't particularly like this method, but it seems to work.

[GregFreeman]

---

@elset191 wrote:

This has gotten in my way a few times.  I haven't tried yet, but I think if you have a DVR in the class you should be able to get around that.

---

Let the debate BEGIN!

[hecmar.arreola]

I'm not sure what a DVR is in this context.  Please explain.  Thanks.

[AKA_TG]

You mean the one By value schmalue?

[elset191]

I meant a Data Value Reference.  I have not used them yet so don't know the specifics of implementation, especially within the context of a class.

[GregFreeman]

---

@elset191 wrote:

I meant a Data Value Reference.  I have not used them yet so don't know the specifics of implementation, especially within the context of a class.

---

Here's  a discussion on it. There are lots of good ones over on LAVA so I would look there. Just google Lavag by reference classes. I have not seen it implemented in the actor framework yet. As far as I can tell (i'm overgeneralizing here) there are two schools of thought. One is the "when representing objects, if I split my wire that doesn't suddenly mean I have two of something." Fair argument, especially when representing things like hardware. If you have one DAQ device, should splitting your wire suddenly give you two DAQ devices? Then, there's the idea that LabVIEW is a by value language. The compiler cannot do many of it's optimizations when you have DVRs. Also, with the actor framework, it is taking the idea that each actor represents something, so by having more than one you are essentially saying I want more than one of this device; that's why I launched two of you! However, in your case, you have two loops within one actor...sooo....it gets a little more grey IMO. I am not taking sides here just throwing out there a couple of mindsets. You will probably find discussions continuing on ad nauseum about this. At some point you will have to decide what works for you. AQ will probably come in here and put in his two cents. I'm sure he has a good way to handle this. Anyways, just wanted to throw these points out there.