Reading Actor Status Data

[David_Staab]

LVB wrote:

I would be interested to hear some other opinions on the use of Actors with instruments/DAQ...

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. If I want reference-based (i.e. message queue) access to a passive object in my system, I put it in a DVR or make it an ESF class. I use the latter heavily for wrapping device drivers, then I call the ESF wrappers in various actors that need to use their methods.

[Brian_Powell]

David_Staab wrote:

LVB wrote:

I would be interested to hear some other opinions on the use of Actors with instruments/DAQ...

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. If I want reference-based (i.e. message queue) access to a passive object in my system, I put it in a DVR or make it an ESF class. I use the latter heavily for wrapping device drivers, then I call the ESF wrappers in various actors that need to use their methods.

I agree so much with Staab here that I am enticed to pile on.  We've done an outstanding job of marketing the AF.  It helps to get across our unofficial, key message: "LabVIEW is amazing!"

And then there was the day that a customer asked me how to call an actor as a step in TestStand.  Sigh.  No, dear customer, the AF is not the best solution for everything.

If you're going to conceptually think of your instruments as actors, who operate and communicate asynchronously, then I think the AF is an interesting approach.  Control/monitoring is a great example--push the control into the actor, and give it a way to receive setpoints and publish data.  In a purely acquisition mode, perhaps you need an actor to buffer data and publish a cooked version of it--probably not an awful approach if your hardware doesn't have its own buffers.

I could actually imagine needing to combine TestStand with a set of actors.  But the question to ask is how to architect TestStand the best way to have steps interact with other processes running in parallel.  E.g., how does one build a producer/consumer interaction between TestStand and something else?  I would try to avoid bubbling up inter-actor communications into the TestStand layer.  It can be done, but I'm pretty sure I would never stop telling myself that it was an abuse of TestStand.

If we flip that around, one of the things that Nancy and I keep asking ourselves is how to incrementally convert an existing architecture to use the AF.  How do you use the AF as a small component within a larger framework that's not actor-oriented?  Is that worth thinking about?  From our perspective, it looks like if you want to use AF, you are biting off a rearchitecture, and that scares people away.

Returning to the original thought, we are left with the question of how we want to think of our instruments.  For typical data acquisition apps, I don't think it's worth it to go the AF route.

[AristosQueue Admin Edit] Replies to this comment regarding communicating with actors from TestStand should be done in this new thread:

https://decibel.ni.com/content/thread/16780

[David_Staab]

Brian_Powell wrote:

If we flip that around, one of the things that Nancy and I keep asking ourselves is how to incrementally convert an existing architecture to use the AF.  How do you use the AF as a small component within a larger framework that's not actor-oriented?

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.

[Brian_Powell]

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.

Nancy and I would both prefer a Velvet Hammer.

[drjdpowell]

Now, suppose another actor occasionally, but not periodically, wants to know what the voltage output is set to. As I see it there are a few different ways:

- 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.

Note that if one implemented the second option (register to be sent periodic messages) then the first and last options are easy extensions.  The first is just "register to receive one message", which should be an easy option to add.  The last can be done with a subVI that creates a temporary message queue, registers it, waits for it to receive one message, and then destroys the queue. 

-- James

[MartinMcD]

Thank you, lots of interesting comments here which I'm reading through carefully. 

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.  I have completed a few decent sized projects using the framework, but starting out a new one is still pretty daunting. Given LabVIEW's routes in data acquisition it seems reasonable to presume that it might have been designed to be useful in such areas.

At the moment I feel that the Reply message is actually a pretty good solution to the problem, with an appropriate timeout and so on.

[David_Staab]

You can lead a horse to water...

[MartinMcD]

It might be quite right to hold off the drink  http://en.wikipedia.org/wiki/Water_intoxication

[Daklu]

Michael_Aivaliotis wrote:

You guys are all nuts. You go through the effort of using the Actor Framework and then settle on a global variable to pass data around. Just bonkers.

I might be bonkers, but I'd argue using globals as a transport mechanism (not a data storage mechanism) in an AF app doesn't contribute to one's bonkers-ed-ness... 

komorbela wrote:

I think you should not be afraid of async messaging. It is the way actor-model works.

QFT.  +1.  @Martin:  Figure out how you would solve the problem using asynch messages, understand what the tradeoffs are, then make a decision based on your requirements.

komorbela wrote:

Make a zero-coupled message...

I humbly request that you call them something other than "zero-coupled message," since they are not in fact zero coupled.  What you're suggesting looks more like a dynamic dispatch callback system.  If both actors require receivers to register callbacks and you use some startup code do the registering, then it's true your actors are not statically coupled to each other.  That's not the same as being zero coupled.

LVB wrote:

I don't think there has been a conclusion on the ideal design of an instrument/DAQ Actor... I would be interested to hear some other opinions on the use of Actors with instruments/DAQ...

I don't have any problem making actors for instruments or DAQ.  Conceptually the only difference between an instrument actor and a non-actor instrument object is the actor executes in its own logical thread, while the object executes in someone else's logical thread.  If I'm concerned the amount of data will overload the messaging system, I can easily set up a dedicated data pipe for streaming data.  The primary purpose of the messaging system is to transport command and control messages.  We throw data messages on there because it's easier to write and easier to understand, but there's no reason data messages have to go through the messaging system.

[Daklu]

Brian_Powell wrote:

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.

I've harped on this a lot over the years, but this comment is a perfect example of why I continue to stress this.

NI has spent too much time pushing the Actor Framework and nowhere near enough time teaching people the principles of actor-oriented programming. 

I agree it's very difficult (perhaps impossible) to incrementally refactor an application to use the AF.  That's not surprising, given that it is a framework rather than a principle.  It is more feasible (though still not necessarily easy) to refactor an application to an actor-oriented design if they are not wedded to using the AF.