Reading Actor Status Data

[Daklu]

[Completely unrelated side question...]

Why am I able to post the message above and this message immediately, but when I try to post a response to some earlier comments I get a "your reply will need to be approved by a moderator before it is posted in the forum" notification?

Grrr... NI's forums drive me nuts.

[Edit: Interesting how the reviewed post is then inserted into the thread according to when I submitted it.  Kind of throws off the thread continuity...]

Message was edited by: Daklu

[David_Staab]

Daklu wrote:

Why am I able to post the message above and this message immediately, but when I try to post a response to some earlier comments I get a "your reply will need to be approved by a moderator before it is posted in the forum" notification

Haha, I'll bet you were flagged for spamming or forum abuse!

[David_Staab]

Daklu wrote:

I humbly request that you call them something other than "zero-coupled message," since they are not in fact zero coupled.

It's an uphill battle, but I'll keep fighting it with you.

What you're suggesting looks more like a dynamic dispatch callback system.

I think the best term would be "double-dispatching", would it not?

[Daklu]

David_Staab wrote:

I think the best term would be "double-dispatching", would it not?

No.  "Double dispatching" is something different.

"Single dispatching" is a system where the actual method called depends on only one of the method inputs.  Labview (and most languages) are single dispatch languages because they only look at one object to decided which method to call.

"Double dispatching" would decide which method to call based on looking at two method inputs.  In Labview it would be equivalent to letting you set two input terminals to dynamic dispatch.  (It's interesting to think about, but I'm not convinced it's a good idea.)

[AristosQueue (NI)]

MartinMcD wrote:

- Send a 'Send Me the Voltage' message, perhaps as a self addressed message

- Register to be send perioidic messages (but I don't want to do this)

- Reads the latest value from some form of global variable/DVR that the voltage supply keeps updated

- Use a synchronous message to read the value there and then.

Option 1 is my vote.

MichaelA's comment is spot on.

Staab wrote:

> But in the abstract, there's nothing about AOD that says you have

> to use one communications mechanism for the actor's entire public interface.

Actually, there is something. Several somethings. State consistency becomes harder to maintain when there are multiple communication systems between actors. If you change the value in a global and then send a command, the receiver may receive the command before the next time it polls the global. This will often become a pain point in any system of any complexity. Clean shutdown becomes harder... remember, Staab, the larger conversation about how to properly stop two while loops? The conclusion of that discussion was that the stop signal should be embedded in the communications channel. When you have multiple communications channels, you often end up needing a stop signal in both, and then there's confusion about what happens when one half of the actor stops before the other half. It gets messy.

The Actor Framework provides defense against a whole lot of very hard to debug problems. Most of its defense is rendered null and void if you add a communications channel between actors in addition to the queues. That's not to say you can't do it or should never do it, but it is a pretty hefty warning to not do it. If you must add a communications channel, a dumb channel -- like writing to a global variable -- is far better than a smart channel -- like a notifier or a DVR. Again, not that you can't make it work, just that it becomes harder to keep the system stable.

Staab wrote:

> Shoehorning something not created designed for the actor

> model into an actor seems like a futile efffort, so I don't

> generally use actors to wrap and model device drivers.

Interesting, considering that was one of the prime use cases that I had in mind for the AF. I don't do enough direct HW programming to contradict you, but I'd be curious to hear more about the difficulties here. Certainly for devices that have state, the AF has proven itself to be more than up to the task... I'm curious what problem is posed by the stateless instruments.

[David_Staab]

This conversation is spilling out of its container and dribbling onto the rug. Let's start a couple of new ones if we want to explore some of the tangential topics that have arisen. ("zero-coupled" messages, wrapping instrument drivers in actors, stringly typed vs. strongly typed, etc.)

[AristosQueue admin edit: I branched a couple of side conversations off to their own threads.]

[drjdpowell]

Brian_Powell wrote:

David_Staab wrote:

I trust you're talking about converting systems that were already designed with AOD principles in mind? Otherwise  it sounds like you and Nancy are succumbing to the same temptation to make AF a golden hammer. If the architecture wasn't made actor-oriented from the start and it functions well, leave AF out of it.

Which I think proves our point.  Nancy and I don't think it's wise to introduce the AF into an architecture that's not built with actors in mind--yet we're asked about it a lot.  How do I dip my toe into the AF waters?  Answer:  You cannonball.

Isn't that a major weakness?  A limit to code reusability?  Build an actor to do something but be unable to reuse its capabilities in a new project that, for some reason, isn't AF as a whole.  Or put effort into extending older code but be unable to use it in new AF projects because you were unable to write it as an actor.  If actors can easily double as "active objects" in non-actor code, then there is a lot more flexibility.

[Jeannius]

I am actually building a DAQ system using AF.

Some background: I work for a testing lab and we have various instruments from different vendors or different models that are being used by various people (first come, first serve).  The whole point is that I created many labview VI for data acquisition based on a certain brand/model. This VI would not work with a different model so that sounds like the perfect use of Classes and inheritance. So I have embarqued on a massive project of creating parent class for each intrument type we use (power analyzer, data logger, power supply,...) using actor framework.

My approach was to treat the instrument as 2 actors: an actual instrument actor and a card actor. The instrument actor is responsible for initialization and data acquisition. The card actor is responsible data logging to disk, timing function (record this for x amount of time, ...). The reason I chose this is because many instruments have multiple channels/card, so that the instrument actor can collect data for all cards and the user can spawn as many card as available in the system independently. The instrument card broadcast the full range of measuremnt and each card actor filter for its own use (I also created a display actor that is spawn for each new card)

I am by no means a CLA (I have yet to take the CLAD, which I am sure I can pass), so cant really say with certainty that this is the correct architecture and so far the 100+ hours I spent on this might all go to waste (or at least to really learning labview AF).

[drjdpowell]

Lets say I have an actor which is responsible for communicating with a voltage supply...

Now, suppose another actor...

Another side issue about reuse that occurs to me: Martin is starting with a simple actor, and then considering how to customize it to suit the needs of a particular caller.  Reused in a different project with a different caller, the Voltage Supply actor might need alternate customization.  It would be much better if the Voltage actor could be designed independently of any caller, with each caller able to specify how it would like to access the information.  A message-publishing system, with flexible registration methods (all updates or one update, synchronous or asynchronous) would allow this.

-- James

[AristosQueue (NI)]

drjdpowell wrote:

It would be much better if the Voltage actor could be designed independently of any caller, with each caller able to specify how it would like to access the information. 

*sigh*  Take a hint, folks. As Martin said in his post at the top of this page:

"I think with the AF in particular it is pretty hard to get started as there is such a breadth of views on how/when/whether to use it."

So stop trying to make his life harder by adding complexity to his design! No, it is not necessarily "better" to increase the flexibility of the system. There may be reasons to do so, but a big reason not to do so is if that kind of code reuse isn't necessary. For example, if the actor is just a shell around the core device API, creating a custom shell for this particular app that will never be reused elsewhere is more than appropriate. And there are plenty of other reasons.

Martin: it's only hard if you second guess yourself at every turn and try to bite off everything that all the architects know in one bite. If the architecture you're working on works for your code, take from these discussions the comments that help you implement that design and ignore all the ways you could do it better until you're ready to move up to the next level.

You've got the answer to the question you were asking. Take it, run with it, come back when you're ready for the next piece.