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

[dirida]

Hi LabBEAN,

I have few questions for you:

1) Could you edit the not working RTEXE file with and HEX editor to see if it is mostly composed by 0? You could also zip it and see if the final size is much more less than the original.

2) Are you using conditional disable in your project?

3) Have you tried to mass compile the project folder?

The problem I had with LV2013 RT magically disappeared after a while. In the meanwhile I have noticed a similar problem on LV2013 developing windows executable. I suspect that this problem arises using conditional disable, that I'm using to test the software on developing machine.

Sometimes happen that after a successful compilation, final exe is mostly made of 0. When this happen I have to mass build the project directory.

Regard,

Daniele

[mdwebster]

Hey Daniele,

I'm the primary coder for the RT side of this application and I can answer these:

1) Startup.rtexe is not mostly zeros

2) No conditional disables

3) Have not mass compiled

Just tried a mass compile and something like 34 out of 80 files come back with "### Bad VI: "VI Name" Path = "VI Path"  with no further information.  Opening those VI's reveal that none of them are broken, so I don't know what that's about.  We do have compile code separated from source flags turned on.  I have also done a force recompile (ctrl+shift+run arrow in top level VI)

Weird thing is I can compile with debugging turned on and connect to remote application (it reads status as running on the RT) through the operate menu and it downloads the remote VI's and gives me the panels, but many of them have broken run arrows.

[dirida]

Well,

it may be something different from what I supposed. Anyway I can suggest to disable the compiled source separation option. Although it is useful when using source code versioning, I had only issues with it, especially with RT.

ciao

Daniele

[MarkCG]

Just to add in my two cents, I was getting beat up by this problem over the weekend and today. I have a real-time project running on cRIO 9074 with LabVIEW 2014. Source code is NOT separated from compiled. Up till now my build worked fine-- just like running in interactive mode. Now my build are completing, but when started on the target are causing the cRIO to create error logs. VIs are showing up as bad / broken. Tried forcing recompiles of my top level VI (ctrl + shift+ run arrow), did not help as it usually does. I usually disable debugging, disconnect typedefs, and remove unused memebers of libraries an polymorphic VI for my builds.

Finally I mass compiled some of my libraries in instr.lib that seemed to be causing the issue according to error log. That seemed to help and now my RTEXE is running normally. I also noticed that I had a fpga reference terminal that wa being coerced, I deleted it and recreated it. Just in case the old CAR mentioned previously was still an issue.

[Hrachya]

Hi

I have same problem with cRIO 9075. Startup program not run. Friend ask me to remove proporty nodes or referances if that uses for first steps. I do that and all started work correctly. May be that will help You in feature.

I use LV14.

With Best Regards

[ZoltanMTS]

Hi,

I have same problem with cRIO 9065 with Labview 2015.

I have inherited code that was written in an earlier Labview version and was running on an older cRIO. I have managed to make it run under Labview, but it seems I have bumped in the issue discussed here.

It seems my code runs only while Labview is connected and after I disconnected it, until I reboot the cRIO. (At this point, I can detect that if the code is running from its handling of the internet connection to it.) The aim is to be able to start the code as standalone application after boot, so I followed the recommended steps: http://digital.ni.com/public.nsf/allkb/BC513C2A0DC29C89862574BF0002B0B9

I have just recently moved back using Labview for embedded systems and the troubling thing for me is that, I can build and run the application, but the standalone version does not work. Apparently there are errors hidden somewhere, so I started searching for them.

One of the recommendations was to make a mass compile and that pointed out certain broken Vis. So I opened them, but according to Labview, they were not broken. So I carried out a VI analysis on one, which pointed out problems (warnings only), so I fixed all of them and made a mass compile again, which came back with broken VI, so I do not know how I can find why the VI is broken.

Another place I have found a list of errors was in a file called VI-Analyzer-errors.txt (attached) in the sub folder

builds\<project name>\<target name>\<build name>\c\ni-rt\startup\project\errors

It is clearly generated during the build process, although its date stamp is couple of years old. It lists errors with an error code, but as the error codes are incremental, they do not seem to be useful. And there is no any other information regarding the location of the errors, so it is pretty much impossible to locate them. Do you have any suggestion on how to locate these errors?

Do you have any suggestions on how to find errors, which block the standalone executable application to run?

Thanks,

Zoltan

[JiPé]

Thanks Eric,

It's an old post, but it saved my day !!!

You're awesome 🙂

[PCasado]

Hi,

I have had the same issue with a deployed application on a  CRIO 9075 (it has been deprecated) and aftger performing a minor change that needed to be done in one of the loops of the RT suddenly it stopped to work as the startup application but worked flawlesly with the PC conneted. But when launched as a startup app the FPGA was working but not the RT.

After several compilantions and changes only disconnecting the unused typedefs seem to solve the issue.

regards and thanks for the advices.

*edit: using labview 2017 sp1 32bits.