AF in RT Application - Prioritizing Actors

[gt8860a]

Hello All,

I'm developing a Real-Time application using the AF (targetting a VxWorks cRIO).  I'm curious if anyone else has tried to assign different priorities to the multiple actors you may have running simultaneously on your RT system and what mechanism you used.  For example, I may have 2 actors running but I would like one of the actors to have a higher execution priority.  Using the priority setting under the VI priorities does not seem like it would work as LabVIEW then tries to set all implentations of "Actor Core" to this higher priority, essentially giving all actors the same priority again.

I was hoping not to have to modify the VI lib but it seems like if I replace the loop inside "Actor Core.VI" with a timed loop and added a "Priority" variable to the Actor class to configure the timed loop, this could be accomplished dynamically.

Any suggestions?  Is this a terrible idea?

Thanks,

Damien

[MattP]

Hi Damien,

This is possible, but tread carefully.  Bear in mind that you're most likely using a single-core target with (relative to a desktop machine) low CPU and memory resources.  The more simultaneously running processes you have, the more overhead you incur to switch between those processes.  We generally recommend against having many simultaneous processes going on resource-constrained targets for this reason, which removes a primary use case for AF.

AF is very likely overkill here unless you have a good reason to use it.  I'm curious to know what that reason is.

That being said...

You won't be able to set the priority of the Actors themselves.  You should not be modifying anything in Actor Framework.lvlib (such as the top-level Actor Core.vi).  You can, however, set the priority of the part of the actor that does the heavy lifting.  Since using the message queue as a work queue is not recommended, you should already be shunting intensive processes to a helper loop within your Actor Core override.  That helper loop is where you have more flexibility, either by making it a Timed Loop with priority based on some value held in the configuration data for your actor or by encapsulating it in a subVI with the VI priority set to the desired value.  You could also set the priority of the individual functions called in your message's Do.vi override.

[gt8860a]

Hello Matt,

Thank you for your quick response.

I am a little bit confused why you feel that the AF would be overkill for my application.  Could you elaborate?  My application has more than 2 actors if that is why you felt is was overkill, I was just using 2 as a simple example.  The application presently has 4 Actors but could potentially grow (DAQ actor, TCPIP communication Actor, DataLogging Actor, and Error Logging Actor).  In general, I want to use the actor framework for all the same reasons anyone would want to use the actor framework in a non-RT applicaiton on a desktop PC:

1. Reduce the amount of code duplication typically found using seperate QMH

2. Scalabiltity

3. Reusability

4. Modularity

I have found a few examples and discussions within this community related to deploying the actor framework onto cRIO targets.  From your comments above, you seem to discourage it.  Do you feel the Actor Framework contains too much overhead for all RT targets or just the cRIO platform?

Thanks,

Damien

[CaseyLamers1]

I am curious what the high priority loop is doing.  I run AF on VX-Works cRIO targets in a large app (>5000 vis) and I have one situation where I have a override of actor core with a higher priotity parallel timed loop.  Jitter is not well defined at this point, so I have pushed all "important" time critical items to the FPGA. 

A bit off topic, but I have found some scenarios where my high priority timed loop gets blocked.  Specifically the "Time-Delayed Send Message.vi" in the advanced vis for AF.  That method is blocking and your loop will not run (or any other methods for that matter) until the time delay elapses.

I'd be happy to discuss my AF on cRIO experience if you would like.

Casey

[MattP]

My background is in embedded systems optimization, usually under tightly constrained performance conditions (microseconds matter), so please take what I say with that grain of salt - I'm a bit paranoid.

Depending on which VxWorks cRIO you're using, you might be working with a target that has a 266 MHz processor and 64 MB of RAM.  These controllers are great for what they were designed for, but that level of controller itself will necessarily limit the scalability of any application put on it.  I don't recommend attempting an AF implementation on the far end of the 'value' side of the cRIO spectrum. 

The performance end of the cRIO spectrum will give you an experience much closer to that of a desktop target.  When we have hundreds of MBs - GBs of RAM, I have no problem considering AF.  On such targets the memory overhead of having more code in memory is less of an issue, and the processor performance is high enough that the system can much better keep up with the repeated thread swapping necessary for an application to really take advantage of an AF design.

The point on the cRIO value vs performance curve where AF begins to make sense will depend on your application needs.  If you have a relatvely light application, but you will need to create many similar but slightly different versions of that application, AF wil make sense sooner.  If you have very strict requirements in terms of performance and memory and are squeezing your target, AF will probably be of secondary concern to meeting timing.