How to troubleshoot a startup VI not (always) running?

[tkienzler-tt]

I've created a small VI to blink the cRIO 9057's status LED plus minus some measurement and set it to run as startup VI following the instructions here, but - not only depending on the measurements included but also apparently some luck - the VI is claimed to be running when I try to connect to the cRIO via LabView, but no programmed function such as the blinking LED occurs. I've found some threads discussing not using front panel elements (obvious in headless mode) and property nodes (in general or only of panel elements?), but my question is:

How can I figure out why a VI is claimed to be running but doesn't not perform its functions? Is there e.g. any way to see an error if it occurred?

[joerg.hampel]

Is there a reason for you not to go the usual route: Create a new Build Specification, add your VI to the Startup VIs, then build the .exe and set it to "run as startup"?

As described here: https://knowledge.ni.com/KnowledgeArticleDetails?id=kA00Z000000P9mySAC&l=de-DE

In regard to your VI not performing its functions, I guess that all the usual debugging strategies apply. Like, 

- does it run correctly when executed from the development environment?

- does it actually execute when run automatically after startup?

- does it throw any errors (and do you maybe log them to disk)?

- ...

[tkienzler-tt]

I also tried using that approach (building an .exe and setting it to run as startup), which yielded the same result, but I'd like to avoid that anyway since currently I'm only evaluating the Application Builder.

Concerning your other suggestions:

• Yes, it runs correctly from the dev-environment. Thus reducing the "usual debugging strategies" to not being too helpful I'm afraid...
• How do I know if it actually executes? When I connect to the cRIO from LabVIEW I get a message about my Main.vi (that's how I named it) running, is that sufficient or might the message be a false claim?
• There are no unwired error terminals (also in the subVIs), how can I figure out what else might be happening then?

[DahlmanR]

Hello!

I find the the Write to System Log VI pretty helpful when debugging (essentially using it like console log/print statements in text-based programming). You can use it to help track down what path your code is taking and ensuring that a) it's running and b) that you didn't simply make some logic mistakes that got you stuck in an unexpected loop. You can view what you're logging using the System Log Viewer in the Web Configuration tool (in IE, navigate to your devices IP address).

http://zone.ni.com/reference/en-XX/help/371361R-01/glang/write_to_system_log/

(Keep an eye on any stop button mechanical actions and your loop stop conditions. It's possible that you are passing a true to stop on the first iteration of the loop and the code runs, but it's simply stopping too quickly for you to witness!)

Hope this helps!

R Dahlman

[tkienzler-tt]

Good idea, I'll give that a shot!

Now the next question would be, is there any way to execute a VI in headless mode without having to set it as startup VI and rebooting the cRIO?

[DahlmanR]

Hello!

Is the issue you have the fact that you have to reboot the cRIO or is the issue that you don't want the executable or startup VI to run at controller boot? I might have some better resources for you if I can understand the why of your question : what are you trying to accomplish? 

Without more context, you still might find this useful! It covers how to programmatically launch a VI or executable on a Real-Time target from a host computer: 

https://knowledge.ni.com/KnowledgeArticleDetails?id=kA00Z000000PAhpSAG&l=en-US

Note, it might be better to create a new post when asking a new questions/slightly different topic than the title of your post, as the new post with a new (more relevant) title will be more easily found by other users in the future.

Hope this helps!

R Dahlman

[tkienzler-tt]

Thanks for your reply, I'm still trying to solve the original question of troubleshooting the startup VI seemingly not perfoming its function. Launching a VI without having to reboot it all the time sounded like a slightly time-saving idea to me, the link you provided seems to provide means to achieve just that, so thanks! I'll give it a shot after the weekend...

[tkienzler-tt · Accepted solution]

So I tried to run the VI via the PC as described, which resulted in Error 1003

Possible reason(s):

LabVIEW: (Hex 0x3EB) The VI is not executable. This error may occur because the VI is either broken or contains a subVI that LabVIEW cannot locate. Select File>>Open to open the VI and verify that you can run it.

Method Name: Run VI

And as https://knowledge.ni.com/KnowledgeArticleDetails?id=kA00Z000000PAhpSAG&l=en-GB stated, I forgot to uncheck the exclusion of vi.lib etc. which explains why simple test VIs did work... However I ran into a new problem then, namely the unhelpful error

Click the link below to visit the Application Builder support page. Use the following information as a reference:

Error 1562 occurred at Property Node (arg 1) in AB_Source_Library.lvclass:Copy_SourceItem.vi->AB_Build.lvclass:Copy_Files.vi->AB_Build.lvclass:Build.vi->AB_DepSourceDist.lvclass:Build.vi->AB_Engine_Build.vi->AB_Build_Invoke.vi->AB_Build_Invoke.vi.ProxyCaller

Possible reason(s):

LabVIEW: (Hex 0x61A) The specified project or library is locked.

Bummer. And there's no helpful information available anywhere. https://forums.ni.com/t5/LabVIEW/Application-builder-error-1055/td-p/2759902 indicates a problem with the not installed DSC. I had to play around with the exclusion settings to finally figure out I have to check the "remove unused members of project libraries" then. In contrast to the other exclusions LabView's help recommends for Run-Time Source Distributions (disconnect type definitions and remove unused polymorphic VI instances) this also is possible on the evaluation version I'm currently running. And I must say NI does no good job at convincing me to move forward... Of course the very evaluation property may be responsible for the error above to start with...