LabVIEW

cancel
Showing results for 
Search instead for 
Did you mean: 

How to debug/highlight-execute Asynchronous VI on Real Time Target from Dev-Environment

Hi everyone!

 

My RealTime Application has a similar structure to the following:

  • MAIN.vi (controller)
    • some subVIs called from MAIN.vi, and one that starts Module.vi asynchronously
  • Module.vi (Asynchronous VI)

I have set a deployment-dir "/c/ni-rt/startup/data" (the Support-Dir in BUILD-properties),

since running my program from the DEV-environment wouldn't find the Module.vi,

i have made a symlink in "/usr/local/natinst/labview" to data.

so my program can find all files (including the asynchronous module).

 

Unfortunately i cannot Highlight-Execution-Debug this Module,

since it is run only on the RealTime Target.

 

Is there a way to debug this Asnychronous VI from the Dev-Environment, like i can with the MAIN.vi??

 

Your help (and time) is very much appreciated.

 

<edit>

just to clarify, the Module.vi depends on other stuff, so i cannot run it by itsself

</edit>


If Tetris has taught me anything, it's errors pile up and accomplishments disappear.
0 Kudos
Message 1 of 10
(5,068 Views)

Several decades ago, when I was learning Fortran, we debugged by inserting "Print" cards into our decks to (a) tell us "we reached this spot in the Program" and (b) "Here's what I (by default, an integer) is right now".

 

For my RT code that seemed to have subtle timing bugs, I wrote a Debug VI that took a variant input and, when called, wrote the input name and value to a Debug file on the RT Target, along with some timing information.  Found my problem ...

 

Bob Schor

Message 2 of 10
(5,035 Views)

hi bob,

very kind of you to answer.

 

the "print" approach i have done already (my logging infrastructure).

(and nice to bring a fortran anecdote)

 

but since my program is substantially bigger than the examplary outline above 😉

i get very many log-entries very fast.

 

i just thought since i can run my MAIN.vi in debug mode from the dev-environment,

that this might be possible as well for my asynch-vi.

 

it seems to me that on running debug-mode from DEV,

Labview sends something, but not the real VIs to the RT,

(because when i search for the filename in question on RT i don't find any --

it certainly doesn't put them in /usr/local/natinst/labview/).

 

perhaps anyone has had the same problem and found a solution

or any other hint is appreciated.

 

greets jwscs


If Tetris has taught me anything, it's errors pile up and accomplishments disappear.
0 Kudos
Message 3 of 10
(5,016 Views)

If I want to debug asynchronously/dynamically called VIs, I tick the 'open front panel when called' option - this allows me to see the instance/clone of the VI and I can then open the block diagram and probe around.

 

I'm not sure if that would work on RT though?

 

Another option would be to statically drop the Module on the block diagram (or a test-wrapper-VI) to test it and then once you've got it working, you can then use the asynchronous calling code.


LabVIEW Champion, CLA, CLED, CTD
(blog)
0 Kudos
Message 4 of 10
(5,012 Views)

i am not 100% sure -- but i think not, since the RT has no concept of frontpanel.

 

thx for your time


If Tetris has taught me anything, it's errors pile up and accomplishments disappear.
0 Kudos
Message 5 of 10
(5,008 Views)

I may be wrong (but never in doubt!), but when you "deploy" to a Real-Time target, I believe you are deploying to Target memory, which is why you see no files.  The exception (in "modern" LabVIEW) is the "built" .rtexe file, which is typically set to Run as Startup.

 

[Caveat -- I'm pretty sure this is true for PXIs, but may well not be true for FPGA systems -- I remember something called a "Bit File", which certainly sounds like a file ...]

 

Bob Schor

0 Kudos
Message 6 of 10
(4,994 Views)

Dear jwscs,

 

I hope this topic is not stale yet, I'm experiencing the same issues. I'm using SoM (sbRIO-9156) as RT target and have adapted a software architecture to run on it.

 

I have a launching instance that calls the Actor Core using an asynchronous call and can not debug the actor core called from the asynchronous call...

 

I've found a proposed way to debug RT projects here

But as soon as I enter the debug session all of the VIs in the launcher appear broken, with a request to be located at the startup.rtexe (not found)

I'm playing around with the build settings and hope that I can get it running soon.

 

If you have made any progres since your last post I would be really glad if you could share.

 

 

"Anything can be done if you only think about it hard enough..."
"... truth is a lie in disguise!"
0 Kudos
Message 7 of 10
(4,733 Views)

unfortunately no, the "print" method is the only method to debug directly on RT (for me).

 

i tried to build mockups whereever i could and tested them on my dev-machine,

for hardware access i used network shared variables then or directly connecting to devices via rs232 or rs485

 

good luck in you endeavors


If Tetris has taught me anything, it's errors pile up and accomplishments disappear.
0 Kudos
Message 8 of 10
(4,727 Views)

Hi jwscs,

 

thanks for your rapid reply, I hope to come up with a good solution that I will share!

 

"Anything can be done if you only think about it hard enough..."
"... truth is a lie in disguise!"
0 Kudos
Message 9 of 10
(4,720 Views)

I realize that this is an old thread, but I'm sure others are still having this issue.

 

To debug an asynchronous process on an RT target from the Developers environment, make sure that the VI that you wish to debug is marked as "non-reentrant" and "Allow debugging" is checked. You find these settings on the VI properties, execution category.

 

I have never been able to debug multiple instances of the same VI, so ensure that you only spawn one instance of it while you are debugging.

 

Now, right-click on the VI that you want to debug, and select the "Deploy" option. This will copy the VI into the run time environment on the real time controller.

 

Press the Run button on your main VI. When it calls your vi asynchronously, the previously deployed VI will start running, and you can open the block diagram and debug normally.

 

Hope this help.

 

Regards,

Rick

Message 10 of 10
(4,104 Views)