LabVIEW

cancel
Showing results for 
Search instead for 
Did you mean: 

Startup application doesn't start on cRIO (work fine on the target with LV RT)

Hello!

 

I have a application (running on a cRIO-9075) that is communicating with a GPS via RS-323 (using NI-9870).

 

I can run the code without problems with LabVIEW RT on the target but when I build the executable and setting it up to run at startup it doesn't run.

 

If I remove the GPS code, the startup application will run fine. As soon as I put back the GPS code, it will not... I see that looking at a Heartbeat shared variable (no heartbeat when the GPS code is there). Also, the startup application will not run if the GPS code is there even if that code is disabled...

 

I have attached a screenshot of the code and one of the software installed on the cRIO for more clarity.

 

I'm using LabVIEW 2011.

 

Thanks in advance!

 

Vincent

Download All
0 Kudos
Message 1 of 18
(9,259 Views)

Also, the error log (in MAX) is giving me this information:

 

####
#Date: THU, JAN 01, 1970 12:00:13 AM
#OSName: VxWorks
#OSVers: 6.3
#OSBuild: Jun  9 2011, 20:07:19
#AppName: /c/ni-rt/system/lvrt.out
#Version: 11.0
#AppKind: AppLib

 

Not sure if it has anything to do with my problem... The cRIO was just formatted and software re-installed.

 

Thanks!

0 Kudos
Message 2 of 18
(9,251 Views)

The LabVIEW compiler for built applications is sometimes fickle - while the code in the disabled structure is not fully compiled and executed, its dependencies are still evaluated and included in the final built application.  The best thing you can do for us is to enable console output on the controller and give us a log of the output (requires NULL-modem serial cable connected from the cRIO to a PC running some terminal app like Hyperterm or TerraTerm or similar).  Sometimes we'll see that dependent modules cannot be loaded or cannot be found, the app cannot be loaded, or a number of other things.  

 

-Danny

0 Kudos
Message 3 of 18
(9,233 Views)

Hello,

 

Sorry for the late response.

I was able to make the application work for some time and for an unknown reason, it's not starting anymore. I made a change in the code and the problem is now back.

 

The code still work as expected when launched using LabVIEW (arrow button).

 

The output from the console is attached to this message, everything seems fine to me but maybe I'm missing something.

 

I've looked at my code and I can't find any unreachable code (case structure or disable structure).

 

I don't know if it might be related but I'm also getting the famous 1502 error (cannot save bad VI without block diagram) so I have to enable debugging to be able to build my application (which doesn't start afterwards).

 

Any ideas?

 

Thanks

 

Vincent

0 Kudos
Message 4 of 18
(9,177 Views)

Hi Vincent,

 

The next step would be to address the "Bad VI without block diagram". If it points a specific VI, usually just re-save of the VI will repair the block/front panel again. If that doesn't work, try moving your VIs to a new project and re-build. A mass-compile will also reveal any bad sub-vis as an extra step. (http://zone.ni.com/reference/en-XX/help/371361F-01/lvhowto/mass_compiling_vis/)

 

What I recommend is to build a debuggable RTEXE, connecting to the remote front panel and running it highlighted mode watching the portion of the GPS code that is in question. This will provide some insight on what exactly is failing. (http://digital.ni.com/public.nsf/allkb/8DA679805915DE40862572D5007B2F70). From there, we can address any error that might appear.

 

I hope this info helps!

 

Aldo A
Applications Engineer
National Instruments
0 Kudos
Message 5 of 18
(9,141 Views)

Hello,

 

I would like to know if you solved this issues and how. I have exactly the same problem with a different cRIO board. It is very annoying. The first time this happened to me I had to roll back the changes and do it again, then the build exe ran successfully.

 

Now I have made few changes to my code and I cannot start my exe, also if the same code run without issues from labview environment.

I have already rolled back the code and done again the same changes without success this time.

I'm using Labview 2013 RT with LVOOP.

 

Best Regards,

Daniele

 

0 Kudos
Message 6 of 18
(8,720 Views)

I have compiled the same code with debugging flag set and this seems to be a workaround. Now the exec is now running on target, but it is not a solution.

 

0 Kudos
Message 7 of 18
(8,696 Views)

 

If you happen to use non-standard ascii characters in the item names that will be deployed (like VIs, ctls, shared variables...) in LV 2011, it will not work as a rtexe. You will need to either rename those items (change "é" and "è" to "e" for instance) or upgrade your setup to LV 2011SP1.

 

 

Eric M. - Senior Software Engineer
Certified LabVIEW Architect - Certified LabVIEW Embedded Systems Developer - Certified LabWindows™/CVI Developer
Neosoft Technologies inc.

Message 8 of 18
(8,687 Views)

Thank you Eric for your response. I will check all vi names. Anyway the rtexe is compiled with LV2013 and using the debugging option, it works like a charm.

0 Kudos
Message 9 of 18
(8,673 Views)

We've run into something similar in the past and are experiencing it again, only the usual workarounds aren't helping for LabVIEW 2014:

 

Previously (e.g. LV 2011 SP1), internal CAR 359118:
"Building RTEXE with binded type definition in FPGA Open VI Reference.vi does not start up automatically"


Known work arounds are:
- Use dynamic mode

- Disconnect typedefs on the Additional Exclusion page of the build spec

- Have all target VIs closed when building RTEXE. 

 

Setting the debug flag upon build doesn't help.  In fact while everything works properly when running interactively through the IDE, although the RTEXE won't start upon deployment, running the RTEXE in debug mode through the IDE partially works.  That is, the main VI run arrow is broken but a few subVIs (configuration VIs accessing globals) have white run arrows and can be run successfully (that is, the global panels update properly).


Certified LabVIEW Architect
TestScript: Free Python/LabVIEW Connector

One global to rule them all,
One double-click to find them,
One interface to bring them all
and in the panel bind them.
Message 10 of 18
(8,002 Views)