Actor Framework Discussions

cancel
Showing results for 
Search instead for 
Did you mean: 

Showing Actor Front Panel on cRIO

Solved!
Go to solution

For the purposes of debugging, I want to see the front panel of my actors running on my cRIO.  I made a test VI to ensure that this worked.  I had a top level VI which had a VI on its block diagram with its SubVI Node Setup as follows:

Capture1.PNG

This works great.  I run my top level and the subVI pops up.  Unfortunately, my actor code is not doing the same thing. At the moment I have a launcher like this:

Capture.PNG

This is not showing the front panel of the actor I'm trying to launch. Can anybody help with this?

I'm using LV 2012 with the LabVIEW 2012 Real-Time Module f1 Patch to fix the bug mentioned here

0 Kudos
Message 1 of 17
(8,959 Views)

The Boolean debug input doesn't work in the runtime engine -- that means it doesn't work when deployed to RT. It only works in the dev environment.

You need to edit your Actor Core VI to turn on the same "show when called/close when finished" options that you used in your test VI.

Message 2 of 17
(5,799 Views)

Thanks AQ but I still can't get this working

In Actor.lvclass and in my cRIO Main.lvclass the Actor Core.vi have these settings:

Capture.png

My launcher now has the Open Actor Front panel as false.

One thing to note, the Show front panel when loaded is greyed out on my Actor Core.vi but it is not on my test VI.  Not sure if this is relevant?

So when I run my launcher, no actor front panel is shown.

0 Kudos
Message 3 of 17
(5,799 Views)
Solution
Accepted by lewboi

In your test VI, turn on reentrancy on your subVI.  You'll find that the show front panel when called option does not work for reentrant clones on RT.  Since Actor Core has shared reentrancy, this means that showing the front panel won't work as you expect (nor will probing, etc).

This is not an issue with Actor Framework per se, but rather with the debugging experience on RT systems versus that on desktop platforms.

I've attached a simple project (2013) to demonstrate.  All subVIs have been set to show front panel when called.  You'll notice a different behavior between the reentrant and non-reentrant subVI calls on the RT platforms.

Instead of relying on the front panel (which will get stripped out in your final RT executable), I suggest adding in debug outputs (either to log file, console, Syslog over the network, UDP broadcast to a listener on your host, LED blink pattern in Morse code, etc) to accomplish the same things you're trying to get out of the system via a UI. 

This will serve you better in the long run if you're building out a system you'll need to debug in operation, as these are the kinds of approaches you'll need to take eventually.

Cheers,

Matt Pollock
National Instruments
Message 4 of 17
(5,799 Views)

Thanks for clearing that up.

I decided to not use Actor Framework on my CRIO because I was worried about debugging without front panels.  However,  I realise now that I could have viewed any Non-Reetrant VIs while they were running.  I think this is correct?

At least then you can see what Static Dispatch VIs are being run from any messages.

Thanks,

Leiws

0 Kudos
Message 5 of 17
(5,799 Views)

Yes, you can see front panels of non-reentrant subVIs.

I still strongly recommend you consider instrumenting your code such that you are not solely reliant on front panels to identify and trace issues per my comment above.  This effort pays significant dividends in all but the most trivial of embedded applications.

Cheers,

Matt Pollock
National Instruments
0 Kudos
Message 6 of 17
(5,799 Views)

MattP wrote:

Instead of relying on the front panel (which will get stripped out in your final RT executable), I suggest adding in debug outputs (either to log file, console, Syslog over the network, UDP broadcast to a listener on your host, LED blink pattern in Morse code, etc) to accomplish the same things you're trying to get out of the system via a UI. 

This will serve you better in the long run if you're building out a system you'll need to debug in operation, as these are the kinds of approaches you'll need to take eventually.

Haha!  Morse code?  Nice.

But seriously, this suggestion seems incredibly inefficient and brings me back to the bad ol' days of crappy/no IDEs (vi, anyone?) when you used print statements to figure out where the code is breaking (think, PRINT "Here I am").  How about wrapping functionality specific to the current actor instance in non-reentrant VIs?  To be honest, we know that the core AF VIs are robust and they don't really do much aside from getting messages where they need to go - what you should be worried about is just how your code is functioning.

Don't give up on AF yet - despite all my frustrations with my attempts to use it well, I have found that the applications I have built in it are incredibly robust.

Cheers, Matt

0 Kudos
Message 7 of 17
(5,799 Views)

mtat76 wrote:

Don't give up on AF yet - despite all my frustrations with my attempts to use it well, I have found that the applications I have built in it are incredibly robust.

That's good to hear. Sometimes I worry the AF is too much of a straightjacket, insisting on particular patterns of action. Comments like yours combined with finding three race conditions in a custom-rolled solution that I was reviewing yesterday keep bringing me back to being comfortable with the architecture that the AF pushes its users into.

0 Kudos
Message 8 of 17
(5,799 Views)

AQ, you sound depressed.  To be honest, everytime I start an AF project, I swear it off forever.  And then, once I am rolling, I am very happy with it. 

It may push you into an framework, but you have a lot of space within that framework to do what you need.  AF provides me the space to separate concerns properly, thereby actually making things easier to debug.  But, to be fair, I haven't deployed one on a cRIO (although I am currently building an embedded system with web services using AF and plan to migrate a cRIO project over to AF).

0 Kudos
Message 9 of 17
(5,799 Views)

I'm slowly moving in the direction you suggest Matt for debugging AF on the cRIO.  Sometimes it's hard to do the right things all at once. 

For my AF projects on cRIO, my first approach was to simply probe the non-reentrant subVIs. This can get you some information, but it can be hard on the cRIO depending on how frequently the probed VI is executed.  Then, I printed out the Common Actor Life Cycle diagram (attached) which I copied from something NI put out, and this reinforced that I can also override the Handle Error and Handle Last Ack Core VIs to see more information when something goes wrong.  That took me a step further.  I'll probably add the log file approach to my toolbox next.

Thanks for the summary of techniques and the encouragement to get better at debugging AF code on the cRIO.

Message 10 of 17
(5,799 Views)