04-10-2014 06:38 AM
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:
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:
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
Solved! Go to Solution.
04-10-2014 12:48 PM
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.
04-11-2014 03:57 AM
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:
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.
04-11-2014 09:51 AM
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.
10-30-2014 09:57 AM
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
10-30-2014 11:58 AM
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.
10-30-2014 01:09 PM
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
10-30-2014 03:38 PM
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.
10-30-2014 04:03 PM
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).
10-30-2014 04:38 PM
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.