Should I use AF for this?

[Shiv0921]

Hi all, sorry, you must get this all the time, but I’m doing my nut trying to decide whether using AF for my project would be beneficial, or whether to stick to what I know.

I’ve attached a diagram of the main processes in my project and communications I'd expect between them. These aren’t set routes, they’re just where the info needs to end up. 

In short

• It’s a system of 2 primary sensors and a camera(+ image analysis).
• The outputs of all three need to be monitored separately, if they exceed values an emergency state should be entered. 
• There’s a few serial items to control the inputs of
• There’s a control loop based on temperature.
• It’s on a real time system, but determinism is not important.
• It will mainly be autonomous, and without a front panel.
• The user can connect and bring up a front panel for data display.
• An admin can also interact to adjust parameters.
• Everything will be logged, except images which user can decide at run time if they want logged.

Real time programs seem to be most regularly made with the QMH, and I feel I could do this with ease. However, I’ve recently done the advanced architectures and OOP courses and I’d like to incorporate what I’ve learnt into this next project. (But not if it’s nonsensical to)

I’ve arrived at AF because I’m concerned that using OOP concepts alone I’ll end up with various OOP design patterns strung together with botchy spaghetti code. Its not very clear to me how the classic design patterns combine to make a program, so I think actor framework might have the structure I’m seeking. But I’m not sure whether this is a cowardly way to end up opting for a complicated answer. 

 I can see the following being uses here:

• All inputs need to be checked concurrently against their own parameters, so could be duplicate code
• images need to be split into 5 and then each part analysed against similar but different metrics, could be duplicate code 
• The user can decide at run time whether they want images logged 
• The admin front panel could be a different front panel
• The serial items will all have the same ‘methods’ with minor differences (open comms, set value, close) 
• There will be daq signal in, and daq signal out.
• The front panel could be dynamically loaded 
• Parts of the program need to be deployed in stages (eg all image acquisition, processing and logging is needed by June) (just a modularity thing rather than an OOP thing)

Reasons it's not necessary:

• Hot swapping items wont be necessary 
• Dynamic functionality isn't necessary (The program will mainly know what's expected of it at run time, except image logging, but that can be easily added statically)
• Once this is finished in September, I won't have to add to it
• Sub panels on RT systems are advised against
• This is my first program on an RT system
• It doesn't seem to me there's very much inheritance. 
• In many places i can imagine wanting to break the advised tree (eg all the alerts, acquisition to logging)

I realise that picking AF because it provides structure is not the way to make architectural decisions, especially when a QMH may provide all I need. I’m also happy to have a learning curve, but I don’t want to be just forcing my project to fit AF if actually it doesn’t really. 

So might I find benefit in using AF here, or should I swallow my personal aims on this one, stick to what I know with QMH and just jump into OOP/AF when the need actually arises?  

Thanks for reading

[OneOfTheDans · Accepted solution]

I can't speak to RT systems. That alone might be enough reason to not use AF. Someone more knowledgeable will need to weigh in on that.

RT aside, your architecture looks like a good fit for the Actor Framework. Here's some feedback, in no particular order, based on all your comments:

• The big benefit AF will give you is modular code with a well defined interface. That means you can write & test your Camera Actor all by itself while 100% ignoring other stuff (like Valve and Pump).
• Don't make too many Actors. A common mistake at first is writing an Actor for every tiny bit of code. For example, you could probably write a whole Actor dedicated to your Check H. But why bother? Just combine that with the H Sensor Actor, probably as a method (VI).
• Don't make too few Actors. The other end of the spectrum is making 1 gigantic Controller Actor that does everything. At that point, there's no reason to use AF. I like to make 1 Actor for each major module. From your diagram, that's probably Controller, DAQ, Camera, Pump, Power Supply, etc.
• Embrace the tree. For example, your Camera Actor and DAQ Actor should probably send all their data back to the Controller Actor. The Controller Actor will Combine info and ultimately send the waveform back to the Host. This means DAQ and Camera don't know about each other. And it means the Controller can make decisions to discard data for some reason (like a bad Power Supply state or something). The tree doesn't have to be deep or complicated. Your design is probably good to stay relatively flat under the Controller.
• OOP inheritance is over-sold. It's a big feature of OOP, so people getting started with OOP try to find any commonality between their "things" and create a parent class based on that. It's usually wrong, and causes more headaches later. Rather implementing inheritance whenever you find roughly similar code (like open/set/close that all instruments have), instead implement it where you want to treat 2+ things as 1. For example, there's limited value in your Camera and Power Supply behaving the same way. But you might find it useful to have Camera-Physical and Camera-Simulated that behave the same and can be interchangeably swapped out while you're developing.

Anyway, this seems like as good a project as any to start learning the Actor Framework (assuming RT is not a blocker). Good luck!

[cbutcher]

I haven't looked at your attachment, but nothing in your description immediately strikes me as a reason not to use AF.

I'm posting mainly now to say that I use some Actors on a cRIO system and don't find them problematic. The problems I've had to solve were all issues I would have had with or without Actors, relating to things like misconfigured RT Queues or similar (note that AF uses normal Queues, so this was within, not because of, the Actor(s)).

Also, using Actors for part of a system doesn't require that you use Actors for all of your system. You can choose to use or not use Actors as you see fit, and you can have more than one root Actor (and corresponding tree).

[Taggart]

The project sounds like a good fit. My only concern would be you only recently took the OOP class. AF requires a good understanding of OOP. There is an AF specific class, which I highly recommend. They don't offer it often, but if you reach out to Allen he might be able to help you get one scheduled.

[BertMcMahan]

I'll admit the learning curve for AF is steep at first, but after your first project I bet you'll really like it. Do you have another QMH template you're comparing AF to? In your application, you can consider AF to be basically a fancy QMH since you're not going to need the OOP aspect of it.

At its most basic, AF is a template that lets you implement very complex QMH's very easily. Having spun up my own QMH's for a long time, it was nice to switch to AF for just the simplicity of message handling, even before I started using some of the advanced OOP features.

(Also, if you find out about an AF class being scheduled, I'd love to take it as well, as long as we can do it remotely ;))

[justACS]

---

@Shiv0921 wrote:

• It’s a system of 2 primary sensors and a camera(+ image analysis).
• The outputs of all three need to be monitored separately, if they exceed values an emergency state should be entered. 
• There’s a few serial items to control the inputs of
• There’s a control loop based on temperature.
• It’s on a real time system, but determinism is not important.
• It will mainly be autonomous, and without a front panel.
• The user can connect and bring up a front panel for data display.
• An admin can also interact to adjust parameters.
• Everything will be logged, except images which user can decide at run time if they want logged.

---

This sounds suspiciously like the student project in Actor-Oriented Design in LabVIEW (the AF course)!  So yeah, it would be a fine first project.

AF runs just fine on cRIO.  The big project I'm wrapping up is AF on a cRIO.  I'm running 9 - 15 actors on the system at any one time. (Some actors are ephemeral, i.e. they come and go over the run of the application.)

Real-time *does* make everything harder, and it's hard to follow program flow on a running actor system, as you have lots of dynamically loaded reentrant message handling loops.  I STRONGLY encourage you to test your actors individually and on the desktop before running the entire system on the cRIO.  I'm also a big believer in unit testing and test-driven development in AF; see my video here:  Designing_with_Interfaces_in_Actor_Framework 

At the risk of being self-serving, I do recommend Actor-Oriented Design in LabVIEW (the AF course) if you're just getting started.  (I'm the one they usually call in to teach it.)  It's offered intermittently, when we can get enough people together to form a class.  The good news is that it is now offered as an instructor-led on line course, which makes that easier.  Anyone who is interested can PM me.  If we get enough folks (I think five is the minimum number), maybe we can put one together this summer.

[Shiv0921]

Thanks, oneofhedans, that’s some really useful input, thanks for taking the time. Your comments have helped get a lot more clarity on where I’ll go with the design which is certainly the first hurdle, and steered me away from breaking the tree! I appreciate it. 

[Shiv0921]

cbutcher, that’s good to know. When you say misconfigueuered queues, are you referring to characteristics such as queue size etc being incorrect? Just so I’m with you.

But thanks, that’s a good point about it not having to all be AF, my host side may be a QMH because things on that side will be relatively minimal, but that’s to be decided.

[Shiv0921]

BertMcMahan, 

I'm pretty much comparing it to the continuous measurement and logging template, which is what I’ve based other programs on and would be similar to what I'd use if I didn't go with AF. But my last one got quite large and I ran into a lot of feelings of everything being tightly coupled and not very extensible which made additions unpleasant. Though this could have been more my fault that the framework's.
I like the comparison to a fancy QMH though and it’s starting to materialize in my mind how it is that. The lack of being able to easily click through VIs I’m currently missing but I’m sure how everything links together will become more clear.

I definitely want to do the AF course. I think my employer prefers to keep courses internal, though I suspect we won’t have the numbers to do that. I’ll let you know what materialises.

[Shiv0921]

justACS, 

Haha oh now I really wish I had done the course prior to this project kicking off.

I’m glad to hear you run AF on the cRIO, I’ve been digging for information on people doing that but what’s out there isn’t exhaustive. I’m hoping this is because no one finds it too different to comment on, rather than that people think it's a bad idea so don't do it.

I 100% want to do the course, I just need to work things out with my employer. Thanks also for the video link, I’ll give that a watch today. Listened to the first few minutes and you have a very engaging presentation style so I look forward to it.