Am I over complicating Actor Framework?

[CDuck]

I have 3 actors: root and then a nested  MainMenu and Config Actor

I just finished my first ever Actor Framework function... I want to make sure I am not creating bad habits before I continue.  Is the following sequence overly complicated? Or is this the expected actor framework experience.

Main Menu messages root to request Test Names
root messages Config to request Test Names
Config obtains Test Names from disc, sends them to root through user event
root messages Test names to Main Menu

@@

Should I just remove config actor to make the config functions public so that Main Menu can access configuration with out the root middle man?  

[drjdpowell]

"Actors" are active entities.  User Interface actors are actively listening for User actions; Hardware actors are usually monitoring their hardware and perhaps providing feedback control.  

What is the active thing your Config actor doing?  If nothing, then it's not obvious it should be an actor, rather than a passive class or subVI.

Also, it may be just me, but the concept of something "asking for its configuration" seems weird to me.  If I'm using a tool, I configure the tool; the tool does not ask me for its configuration.  If I were writing your app, the "root" actor would read config on startup and send the subactors their configuration.  That's one message.

[LucianM]

Think first if your actors really need to be actors (i.e. separate modules running in parallel that can receive messages and execute them). Maybe they can be replaced with simple VIs. Actors are asynchronous processes, meaning you send messages to them and they will execute on their own schedule. Requesting information from an actor can cause some issues.

If your actor hierarchy is like you described, I would not request data from actors like that. If an actor holds information that is also interesting for other actors, I would send messages to all those actors with the new data every time it has changed so they always have the latest version of that data and they don't have to request it.

Also keep in mind that nested actors should not depend on their callers. Use abstract messages when sending messages from nested to caller or use interfaces if you are working with LabVIEW 2020.

[CDuck]

Ok this makes sense.  I should do less asking and more posting.

Yeah config should probably not be an actor in my scenario.  Especially as it started to have a spaghetti code feel to it.. Today I will practice/learn "interfaces" as well, which I suspect may get rid of that spaghetti code feeling.  

Thanks guys, much appreciated. I have a better idea of how this framework is supposed to look/behave now

[CDuck]

Also in case anyone is in the same boat as me, I would like to add that I suspect learning about "interfaces" and "hardware abstraction framework" might go hand in hand. 

Correct me if I'm wrong but maybe the shortest way to describe what I was doing wrong is to say that "configuration" does not need to be abstract..  

Maybe there's a lot of knowledge to unpack in the term "abstract" though @@

[wiebe@CARYA]

---

@CDuck wrote:

Also in case anyone is in the same boat as me, I would like to add that I suspect learning about "interfaces" and "hardware abstraction framework" might go hand in hand. 

---

Unless you have several interchangeable device types and multiple requirements to use them differently in a dynamic way, I'd simply make nice drivers for each device and use them. Or a parent for each device type, with a child for each specific device.

AFAIC, HALs are very often overkill. Almost like a holy grail, or a pot of gold at the end of a (fictional) rainbow.

A multimeter can measure a voltage, and so can an oscilloscope. But do you really ever want to do a Read, while you don't know in advance if it's the MM or the Oscilloscope? The answer could be yes, and if so you might need some sort of HAL...

I'd be very careful with spending too much time on a HAL. IFF you really need a HAL, you're in for hell of a ride. Once it's done it will be very complex, maybe too complex to be practical.

If you want to make a HAL to learn OO, I'd reconsider. It's not a good idea, IMHO.

Interfaces are much wider applicable. A good tool everyone should have in their toolbox.

If you really need a HAL, interfaces would be almost a prerequisite.

[CDuck]

Perfect! I had just come to the conclusion that rather than being paralyzed by HAL... I would continue on with out the perfect abstraction, so I can get comfortable with interfaces and general actor behavior.  Thanks for the confirmation.  I can come back to mastering HAL at the next stage if needed 

[WavePacket]

---

wiebe@CARYA wrote:

---

@CDuck wrote:

Also in case anyone is in the same boat as me, I would like to add that I suspect learning about "interfaces" and "hardware abstraction framework" might go hand in hand. 

---

Unless you have several interchangeable device types and multiple requirements to use them differently in a dynamic way, I'd simply make nice drivers for each device and use them. Or a parent for each device type, with a child for each specific device.

AFAIC, HALs are very often overkill. Almost like a holy grail, or a pot of gold at the end of a (fictional) rainbow.

A multimeter can measure a voltage, and so can an oscilloscope. But do you really ever want to do a Read, while you don't know in advance if it's the MM or the Oscilloscope? The answer could be yes, and if so you might need some sort of HAL...

...

---

I'm still learning -- but your multimeter/Oscilloscope example is more of a measurement abstraction layer as opposed to a hardware abstraction layer, right? 

[wiebe@CARYA]

---

@WavePacket wrote:

---

wiebe@CARYA wrote:

---

@CDuck wrote:

Also in case anyone is in the same boat as me, I would like to add that I suspect learning about "interfaces" and "hardware abstraction framework" might go hand in hand. 

---

Unless you have several interchangeable device types and multiple requirements to use them differently in a dynamic way, I'd simply make nice drivers for each device and use them. Or a parent for each device type, with a child for each specific device.

AFAIC, HALs are very often overkill. Almost like a holy grail, or a pot of gold at the end of a (fictional) rainbow.

A multimeter can measure a voltage, and so can an oscilloscope. But do you really ever want to do a Read, while you don't know in advance if it's the MM or the Oscilloscope? The answer could be yes, and if so you might need some sort of HAL...

...

---

I'm still learning -- but your multimeter/Oscilloscope example is more of a measurement abstraction layer as opposed to a hardware abstraction layer, right? 

---

I guess it could be both...

From HAL_MAL_Web.pdf (ni.com):

---

It’s important to understand the difference between a HAL and MAL.

A HAL is a code interface that gives application software the ability to interact with instruments at a general level, rather than a device-specific level.

Typically a HAL defines instrument classes, or types and standard parameters and functions that those instruments must conform to. In other words, the HAL provides a generic interface to communicate with instruments from the instrument’s point of view.

A MAL is a software interface that provides high-level actions that can be performed on a set of abstracted hardware

---

Now I don't really see how one would make a HAL without at some point implementing some sort of MAL...

The point was to pick your battles. Make what you need, in the simplest way. Don't make a fancy HAL or MAL because you can, because chances are it gets so complex you never get it working, or it won't be used. Especially with HAL\MAL, you can keep working on them forever...

[wiebe@CARYA]

---

wiebe@CARYA wrote:

I guess it could be both...

From HAL_MAL_Web.pdf (ni.com):

---

It’s important to understand the difference between a HAL and MAL.

---

It's funny how they stipulate the importance of the difference, and then continue to call everything HAL/MAL...