LabVIEW

cancel
Showing results for 
Search instead for 
Did you mean: 

Real-Time Application doesn't run; source code works fine

Solved!
Go to solution

I suspect that both these problems are due to the software stack on your computers. Your customer’s computer might not have the proper software installed to properly connect with the cRIO.

 

For the problem with your computer, do you have VIs developed in multiple versions of LabVIEW? Please look at this article and try to mass compile your code:

http://digital.ni.com/public.nsf/allkb/8D2A6D74062A9EAA86256993006F0471

Nolan H.
Applications Engineer
National Instruments
0 Kudos
Message 21 of 25
(1,138 Views)

Thanks, i check your suggestion, mass compile i've already done. I'll try the other point in the doc.

 

In my PC i have 2014 and 2016 but i worked only in 2014. True the drives can be update to LV2016. In the customer PC LV2014 and LV2014 drivers.

S:O W7 for each

 

Thanks

Nicola
LabVIEW DeveloperByteLABS.
0 Kudos
Message 22 of 25
(1,128 Views)

I ran into a similar problem. But I am using a PXI RealTime system and LabVIEW 2015 SP1f7 32 bit with a RealTime remote panel application (in a web-browser). There were numerous build trials where LabVIEW crashed during the build process. And once I got lucky to have gone successfully through the build and 'run as startup' process, the application wouldn't run in the web browser.

 

In the development environment there are no problems. The application runs just fine.

 

After changing the build spec where I chose to "disconnect type definitions", the problems seem solved.

I do have a (few) single process type def'd shared variables (error clusters I know for sure, maybe some others).

I tried a few builds, also on different PC's (same PXI system). So far so good.

 

The peculiar thing is there was a CAR reported in 2011 and supposedly solved in LabVIEW 2012.

Note that the workaround is somewhat confusing the way it is written, but it should read "change build spec to disconnect type definitions".

 

 Another peculiar thing is that I also have two other PXI systems running, as far as I remember without "disconnect type definitions".

They seem to run just fine (they have different controllers though), but are at our customers site now at the other end of the world. So I cannot do some experiments on them.

 

I just opened a service request at National Instruments. Have no definitive answer yet.

 

CAR 292012

Real-Time Applications containing typedef Shared Variables fail to run.
If you are building an RTEXE that contains Shared Variables whose data type is based upon a type definition and the build specification is configured to disconnect type definitions the RTEXE will not run.

 

Workaround: 1.) Manually disconnect the variable from the typedef before building the application 2.) Change the build spec so it doesn't disconnect type definitions

Reported Version: 2011 32-bit Resolved Version: 2012 Added: 10/11/2011

0 Kudos
Message 23 of 25
(936 Views)

In our case, the only solution that have match solution is creating new project and insert all vi's and other in this one. 

 

We has founded the problem two or three times during the development, we have removed typedef/shared variable and each kind of possible use of UI (like error popup message ....).

 

The only is that the xml file of the oproject are corrupted and in rebuilding we have solved.


Nicola
LabVIEW DeveloperByteLABS.
0 Kudos
Message 24 of 25
(923 Views)

Ten years later and I run into the very same problem - RT Startup exe does not run on target unless "disconnect typedefs" option is clicked when building. FPGA and RT User LEDs just freeze on sbRIO startup. Can anyone explain this behaviour and why it is still a problem on LV2021+?

0 Kudos
Message 25 of 25
(91 Views)