Actor Framework Discussions

cancel
Showing results for 
Search instead for 
Did you mean: 

Actor Framework cRIO

Solved!
Go to solution

Hi All,

 

I am about to start writing a proposal for an embedded cRIO system, and I am thinking of using Actor Framework. For the most part, I will not be creating an overly large amount of actors and most of them be created at power-on and remain in memory until power-down.

 

Is it a terrible idea to use AF on cRIO? Should I just stick to a QMH?

 

Thanks,

Tom

0 Kudos
Message 1 of 9
(3,972 Views)
Solution
Accepted by tcapuano-aps

AF works just fine on cRIO.  One of my current AF projects is on a cRIO, and I know other folks who have AF projects on cRIO.

 

There are a couple of pain points, which you can mitigate pretty well with good design.

 

First, you are dynamically loading a lot of parallel processes, so it can be very hard to get to the specific diagram you need when you are debugging.  Another issue that comes up is that deploy time to the cRIO scales exponentially with the number of coupled classes, and OO designs, and AF in particular, can couple a LOT of classes pretty quickly.

 

The answer is a stock answer for cRIO development:  to the extent possible, develop and test your code on the desktop before you deploy.  The corollary to that advice is to design your code to maximize the amount you can test on the desktop.

 

I have taken to having one project for each actor I'm developing.  I make this possible by having every actor inherit from an "interface" actor that defines methods and messages, but leaves implementation to its children.  Actors call those interfaces, not the children, so they are only coupled to thin actors that aren't coupled to anything else.  (This is the low coupling solution we talk about in the AF course.)  I use dependency injection to put it all together in the final system.

 

With the actor isolated in this fashion, I can test it extensively on the desktop.  I use VI Tester and automate all of my tests.  Once I know the actor works, I can put it into the main project for deployment, confident that almost all of the bugs I am about to find are related to sending messages to the wrong place.  I don't bother deploying to the IDE; I just build executables and test those.

 

Low coupling also seems to help with long load/compile times.  I think the deployment tools thrash less on the code when things are properly decoupled.  My data is only anecdotal, but my build times are reasonable, while the other team I'm working with - which isn't decoupling properly - has much more unreasonable build times.

Message 2 of 9
(3,947 Views)

Minor addition to what justACS said...

The coupling of classes between desktop and CRio can be reduced with some improved language support that is coming in LabVIEW 2020 in a few weeks. Some companies upgrade fast, others slow... if you're one of the faster adopters, it *may* not be as much of an issue as in years past. (I say "may" because I think my team has addressed the pain point, but there's always a bit of breath holding when software finally hits real-world test cases, no matter how much internal testing it has been through.)

0 Kudos
Message 3 of 9
(3,920 Views)

Hi Tom, 

 

I have used the Actor Framework on my last project using a CRIO-9030 and LV2018. It works quite well.

 

During the development I have sometimes the problem that the Launcher VI won't start after pressing the Run button. LV deploys all components to the Crio but the system won't run. Then I have to restart the Crio and LabView.

 

There are also some drawbacks with the embedded UI that is supported by the 9030. The Crio can't use subpanels. So the solutions like the MGI Panel Manager or others won't work. To solve this problem I use the following architecture:

 

I have a Launcher VI that implements the whole user interface and starts a main actor. Before starting it the Launcher VI registers all controls and indicators as references to the main actor. The Launcher VI also has an event loop. If a button is pressed on the user interface this event loop send AF messages to the main actor. The main actor redirects these messages to the responding nested actor. On the other side the nested actors send UpdateGUI messages to the main actor. Then the main actor uses the stored indicators' references to update the UI elements.

 

Martin 

0 Kudos
Message 4 of 9
(3,887 Views)

Hi,

 

On newers cRIO there is no problem in running an application with AF. I have a couple projects in AF running in cRIO. Although I would not recommend in older ones, mainly because of the memory issue.

 

As mentioned before, there are already a natural difficulty in debugging Actor Framework in Windows, more inside de cRIO, so things become even harder when cRIO has no UI. So keep the log to disk routine very sharp and do what Allen says, try to extensively test in Desktop.

 

What if I use FPGA? For that matter I've been using the Open Dynamic Bitfile Reference. This function allows you to load the bitfile into the controller and then execute remotely the fpga code inserting the IP Address and when deploying you can use a conditional disable structure and change to RIO0 or whatever is called your FPGA Target. 

 

Hope it helps you.

 

Regards,

 

Felipe

 

Felipe Pinheiro Silva


Follow my blog for LV content!

0 Kudos
Message 5 of 9
(3,837 Views)

@matrixx567  escreveu:

 

During the development I have sometimes the problem that the Launcher VI won't start after pressing the Run button. LV deploys all components to the Crio but the system won't run. Then I have to restart the Crio and LabView.


Hi Martin,

 

During a development of a code I already had this issue. This should not happen. It is an unstable behavior.

 

I don't recall exactly what I've done, but it may be something related to your application not closing cleanly or some process inside the application taking over the CPU and not allowing this remote connection to be established between target and host pc.

 

Nowadays I keep a record of these problems but at the time unfortunately was not a fact.

 

Cheers,

 

Felipe

Felipe Pinheiro Silva


Follow my blog for LV content!

0 Kudos
Message 6 of 9
(3,836 Views)

@AristosQueue (NI) wrote:

Minor addition to what justACS said...

The coupling of classes between desktop and CRio can be reduced with some improved language support that is coming in LabVIEW 2020 in a few weeks. 


I realize this is probably not the correct forum to ask, and it has probably been asked before. 
Will there EVER be multi-class inheritance in LabVIEW? 

 

Figured you'd be the guy to ask 😃

Appreciate constructive criticism, it is there to help you succeed.
0 Kudos
Message 7 of 9
(3,785 Views)

@SHowell-Atec wrote:


I realize this is probably not the correct forum to ask, and it has probably been asked before. 
Will there EVER be multi-class inheritance in LabVIEW? 

 

Figured you'd be the guy to ask 😃


I'm not AQ but figured I might be able to help:

 

https://www.ni.com/en-us/support/documentation/supplemental/06/labview-object-oriented-programming--...

 

NI has discussed adding multi-class inheritance, and their current public stance is that they're not planning on adding it (what they say behind the scenes is of course anyone's guess).

 

The good news is that inheritance IS coming in LV2020, which AFAIK get most people most of what they need from multi-class inheritance, so we can all start playing with that whenever it launches. Originally it was set to be May during NI Week, but NI Week was bumped to August and I haven't read if they're going to change the release schedule or not.

 

I hope it's soon, as interfaces are a big enough feature leap for me to make the switch. (I'll also get Sets and Maps which will be nice :))

0 Kudos
Message 8 of 9
(3,773 Views)

@SHowell-Atec wrote:
Will there EVER be multi-class inheritance in LabVIEW? 

Ask again next week.

0 Kudos
Message 9 of 9
(3,766 Views)