cRIO - Troubleshooting creation and deployment of startup standalone real time application

[JensG69]

I had very similar problems. It was unpredictable if a startup.rtexe (build with LabVIEW 2011 SP1) would really run or not, most of the time, it would not run, Running the project (i.e. the main VI) from LabVIEW directly has always worked. I tried every combination of additional settings (SSE2 (in-)active, LV8.x file structure, (dis-)connect typedefs, ...), nothing was working. But today I think I discovered the problem: I had one sub-vi set to execution-priority "subroutine". Since I changed the priority back to normal, every build of a rtexe has been successful. Jens

[vgravel]

I have the very same problem as the original poster...

I'm not able to debug the cRIO application I open a FPGA reference somewhere in my RT code. My startup RT application doesn't start but it work fine when I'm running it with LabVIEW (2011).

Any news that might help me?

Thanks!

Vincent

[Jed394]

Simular problem here.  Trying to troubleshoot now.  Not sure if mine stems from the open FPGA yet or not.  I was able to run much simplier code as a startup.  I'll update if i find an additional solution or can replicate the source distribution solution.

jed 

[nathand]

---

@kkguner wrote:

Today I realized that I should not use Property Nodes or References for my clusters. Since the startup.exe has not any front panel it gives error and do not update cluster value. By means of  the Labview help, I changed these into the local variables. Now my project works fine as a startup.exe I hope you find your solution too.

---

If you feel like the NI compiler should have warned you about this when you built the executable, then please vote for this idea: http://forums.ni.com/t5/LabVIEW-Real-Time-Idea-Exchange/Warn-about-front-panel-property-node-use-whe...

[vgravel]

Anyone from NI would like to have a look at this issue?

It's starting to be quite time consuming on my side and I still have no clue how to overcome it...

Mass Compilation doesn't work on my side...

Thanks!

[nathand]

You're posting in a thread marked Solved, so you may not see many responses, including from NI employees.

Can you post the contents of your ni-rt.ini file from the cRIO?  Have you tried enabling remote debugging in your build, and connecting to the compiled application?  What else have you done to troubleshoot this?  Can you post any of your code?

[JensG69]

Quote:

You're posting in a thread marked Solved, so you may not see many responses, including from NI employees.

---

The problem hereby is that it is not a solution of the error but just a workaround.

Deploying a source distribution instead of a startup.rtexe just because the startup.rtexe is marked as crashed cannot be the final solution.

Enabling remote debugging has not been solution for me, because with this option enabled a startup.rtexe always started.

[nathand]

---

@jg69 wrote:
The problem hereby is that it is not a solution of the error but just a workaround.

---

Whether or not you see it as a solution, the original poster marked the thread as solved, which indicates to other users that there's no need to comment further on it.  You may want to start a new thread.

---

jg69 wrote:

Enabling remote debugging has not been solution for me, because with this option enabled a startup.rtexe always started.

---

Now this is useful information.  Are you using any front-panel property nodes inside a subVI?  If so, with debugging disabled, the front panel will be removed and property nodes will generate an error.  With debugging enabled, I believe you won't get that error.  Does your code exit if an error happens?  Have you considered logging progress through your code, or errors, to a file?  That may help determine if your code started and then failed, or failed to start entirely.  Can you build the same code into an application targeted at your desktop PC and see if you get the same failure?

[Mugur]

Hello everyone

I'm experiencing the same problems, however none of the proposed workarounds are working for me. I imagine there must be another fundamental problem.

It is my understanding that this issue is marked as solved. Can anyone suggest an active thread.

Many thanks

Yannis

[nathand]

---

@Mugur wrote:

It is my understanding that this issue is marked as solved. Can anyone suggest an active thread.

---

It's OK to start a new thread, if you've already searched through the forums and have not been able to find a solution.  The forum forces you to do this search before posting: after you run a search, you'll see "Post this as a question" (or something similar, I don't remember the exact phrasing).  Provide as much detail as possible in your post; it's best if you can attach your code too.