Actor Framework on real time in LV 2012

[AristosQueue (NI)]

I want to give a heads up to everyone who has been asking to deploy the AF to real time in LV 2012.

We have finished testing and vetting the actor framework on CRIO and other RT targets. With one known issue, the actor framework is working as designed and is a viable architecture for real time applications. NI engineer niACS expects (no promises, as usual, for unreleased projects) to have an example posted at NI Week showing a host running an actor-based application establishing contact to a real time target running an actor-based application. He has had the example running for several weeks now, but is still polishing it to make the code releasable.

The one known issue affects VxWorks targets (aka most cRIO targets).

These targets have a bug that prevents any library that uses community scope from downloading to the target. This bug was discovered too late in the development process to be fixed before release. It will be fixed in the first real time patch that is issued for 2012, but we have no date set for when that will be.  I am pushing for it to be much sooner than the general SP1 patch, but the actor framework does not have much sway on real time as the number of customers expected to need it in the short run is fairly small and a workaround exists.

That workaround is to edit the vi.lib/ActorFramework files to change anything that is community scope into public scope. I know that users do not like modifying their vi.lib files as that makes it hard to port the code to other machines. You might wish to make a copy of the actor framework and modify the copy, but that will prevent you from using the message maker tool. I believe your best option is to modify the vi.lib files.

I wanted to get this information out now for those of you who are looking forward to LV 2012 so you can begin planning your work accordingly. It took me a bit because I was still holding out hope that we could get a patch in place to coincide with the release, but that is not going to happen.

Edit (by niACS):  Here is a list of the VIs in Actor Framework that are community-scoped (valid for AF 4.0 and 4.1):

Actor.lvclass:  Handle Last Ack.vi, Init Check.vi, Init Queues.vi

Message.lvclass:  Drop Message.vi

Last Ack.lvclass:  Send Last Ack.vi

Message Enqueuer.lvclass:  Init from Existing Queue.vi, Enqueue Critical.vi

Message Dequeuer.lvclass:  Init from Existing Queue.vi

Message was edited by: niACS

[David_Staab]

If the next rev of Message Maker is going to be posted to NI Community, it should be straightforward for one of us -- yes, I'll volunteer, if need be -- to modify it so you can point it to the copy of AF you want it to use.

[David_Staab]

Something occurs to me: How are we going to debug actors on LVRT? You can't highlight execution or probe wires on a reentrant VI! There's going to be a lot of needed "developer infrastructure" for checking the running state of spawned instances, call chain hierarchies, reference lifetimes, execution traces, debug messaging....all that stuff you can normally glean from the probing block diagram will have to be exposed through network-capable tools.

[AristosQueue (NI)]

a) Some of this came up at the NIWeek open mic session with LV R&D. We'll see what comes of that.

b) The instrumented-for-debugging version of the AF that I posted last wee should work on RT *I think* (haven't tested it). You could instrument your code further to add more information to the debug window using the same techniques I did to instrument the core actor. A great solution? No, not by a long shot.

c) I pinged the RT team about the issue (I didn't even know prior to NIWeek that reentrant VIs weren't debuggable on RT). The short story of what they said is, "We know about the problem and we'd like to do something about it." I am guessing that vagueness was part of what spurred the open mic session at NIWeek. They said for now, the only option is some form of instrumenting the code.

[AristosQueue (NI)]

A bit of debugging info from someone else who works on RT:

1. LV ships a debug print VI that logs to the target's console (either a monitor or a serial out. or a remote console viewer in the WIF). Don't recall the name of the VI.
2. This implementation of syslog from SE (I think?)

Might be helpful for RT debugging generally. Certainly the debugger VIs that I posted could be updated to write to this console instead of to the panel.

[Pie56694]

Re. #1:

LabVIEW 2012 Real-Time Module Help » RT Debug String VI

KB: Can I Use the RT Debug String In My Time-Critical Loop?

[SamoraJ]

Call me crazy, but I am going to use tha Actor Framework for the very first time on a commercial project.

A single board RIO application for medtech.

Just thought I'd let you folks know.

So if any more quirks like the "community scope"-bug are uncovered, there's at least one guy who'd like to know.

Cheers

[justACS]

Hi Marcus,

It's actually not too bad, certainly no worse than normal RT programming.  Debugging can be tricky.  But building an executable posed no unusual problems.

I anticipate posting a working example sometime in the next few days (later this week or early next).  Hopefully, that will save you some pain.

[AristosQueue (NI)]

We'll keep you posted. So far, so good.

-- AQ

[SamoraJ]

I'm lazy, so I'm looking forward to a working example for VxWorks / RT.

In the mean time though, I've posted a document scripting the update of the community scpoed methods listed above, making them public (or back if you want).

https://decibel.ni.com/content/docs/DOC-24105

cheers

/MArcus