Actors and interfaces - am I doing it right?

[drjdpowell]

Regarding HALs, Hardware Abstraction Layers, that is any layer that serves to abstract hardware.  Actors are a layer, and they can serve to abstract hardware.  Don't assume a "HAL" has to be a passive object.  You can do it as an object, in which case you only need one Actor class to manage that object, but you can also have a different actor for each hardware type.

[Taggart]

---

@cbutcher wrote:

---

---

@Taggart wrote:

And also as far as HALS, do you really need a seperate actor for each instrument? or could you just have one actor that wraps the interface to your HAL using composition? Wouldn't that be easier? Then the only interface any other actors have to worry about is that one actor interface?

---

What's the purpose of the Actor here? I think you're saying this from the point of view of already having non-Actor drivers (class, library, bunch of VIs in a folder somewhere) to operate each piece of hardware (you mention HAL, but I'm not sure if you're talking about multiple implementations of a single tool, or multiple different types?).

Can you elaborate what you're (mentally, or really) doing?

Well in my case I am a contractor and I end up working on various projects. Some use AF, some DQMH, some other frameworks. I try not to couple my code to the messaging framework. So if I need a DMM, I make a regular vanilla LVOOP DMM class that I can call and test serially. If I want to use it in a DQMH project, I create DQMH module for it. If I want to use it in an AF project I create an Actor for it. I just use composition. If need a HAL or something I implement it either by subclassing DMM or creating a parent instrument class and writing the AF/DQMH wrapper around. Then I can use dependency injection to specify which DMM or instrument to use. In that case I only need 1 Actor/DQMH module.

[horuable]

Thanks everyone for your input. For now, I'll stick to the way recommended by AQ and ACS, and keep my interface separate from other actors. I think it'll work fine for what I have in mind and will allow me to reuse the actor I care about the most at this time.

There's still a lot I have to learn about AF and I'll definitely refer to this thread in the future.

Thanks again!

[drjdpowell]

---

@Taggart wrote:

---

Well in my case I am a contractor and I end up working on various projects. Some use AF, some DQMH, some other frameworks. I try not to couple my code to the messaging framework. So if I need a DMM, I make a regular vanilla LVOOP DMM class that I can call and test serially. If I want to use it in a DQMH project, I create DQMH module for it. If I want to use it in an AF project I create an Actor for it. I just use composition. If need a HAL or something I implement it either by subclassing DMM or creating a parent instrument class and writing the AF/DQMH wrapper around. Then I can use dependency injection to specify which DMM or instrument to use. In that case I only need 1 Actor/DQMH module.

---

I also am a contractor, and I also generally make a "vanilla class" and then an actor (Messenger Library actor) to use it.   The vanilla class is more likely to be reusable and isn't dependant on an framework.  But I would be wary of making that vanila class directly part of a HAL.  I think it is difficult to design a good HAL that works well and is really reusable in arbitrary new applications.  It is usually better to assume your HAL is application-specific, and have it use your vanilla classes by composition rather than inheritance.  Then your HAL can often work better at the actor layer.

[justACS]

---

@horuable wrote:

There's still a lot I have to learn about AF and I'll definitely refer to this thread in the future.

---

I've been working with AF for 12 years now.  I still learn new things.

If you haven't taken it yet, Actor-Oriented Design in LabVIEW is being offered the week of August 18th, and again the week of October 31st, in the virtual instructor-led format (i.e. on-line) format.  I am teaching the offering this month, and maybe the one in October.  I believe there is still time to enroll in either.  This is the recent update, which includes material on interfaces.

[Taggart]

---

@justACS wrote:

---

@horuable wrote:

There's still a lot I have to learn about AF and I'll definitely refer to this thread in the future.

---

I've been working with AF for 12 years now.  I still learn new things.

If you haven't taken it yet, Actor-Oriented Design in LabVIEW is being offered the week of August 18th, and again the week of October 31st, in the virtual instructor-led format (i.e. on-line) format.  I am teaching the offering this month, and maybe the one in October.  I believe there is still time to enroll in either.  This is the recent update, which includes material on interfaces.

---

The class is awesome! Although I took the old version without interfaces. Perhaps I need to retake it now.

[StevenHowell]

Sam,

I agree with you on that. Keep your hardware layer as straight classes and not Actors and then bring them into the messaging architecture you choose. 

One thing that I have a very hard time deciding on when using AF is what to do with my DAQ functions.

As you said, keep those in a class that can be imported and used anywhere, but my problem is with how to continuously grab data from the DAQ.

I've used message pumps in the actor helper loop, used the timed self message, but those two paths always seem to cause me grief one way or another.

Currently I have a project I am working on where I am upgrading a controls platform that handles the Air Flow system in a clean room. This is a large clean room and the stimulus (pressure, humidity, temp) will all change slowly so I do not see the need to have a DAQ running every few mS. I may set the DAQ calls to only call once per second and then feed those into a PID loop for closed loop control of the HVAC actuators. 

Not sure if I want to use Actor Framework for that or some other messaging framework. This system will be deployed to a cRIO that WILL NOT have a user interface so I do not have to worry about networked actors. 

That is one of the main reasons I typically steer clear of AF when using cRIO. The Network Endpoints always confuse the heck out of me. 

The other is that I have had a real hard time testing AF on cRIO because of the actor front panels not coming up on the cRIO when testing.