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

[dfjuggler]

And maybe include a link in this thread to the new one, so users that arrive here and don't find a solution will be able to check other options. Good luck!

[Matthias_T]

Same problem here. I created a sbRIO-9632 Project in LabVIEW 2010 + RIO 3.6.1. It works fine. 2 Month ago I installed LabVIEW 2011 SP1 on my Notebook. Last week I traveled to France to add some new features. My application works fine when I use the run button. But when I create and deploy a startup.rtexe, nothing happens. So I took my original source code and tried again with LabVIEW 2011. Same problem.

Mass compile has no effect and debugging the .rtexe stops on error by connecting to it. I also reboot my Host PC, move the hole project to an other path and reinstall the RIO Software on the sbRIO.

I read about the "subroutine" - Problem (one or more VIs are set to execute as subroutine). My app uses one Sub-VI (the main functionality) as subroutine. I can't change it, because all other options are not fast enough. To use other settings are not a solution for me.

This is one of the problems I had with sbRIOs since I updated to LabVIEW 2011. In an other case we connected a Agilent 34401 to the serial port of the sbRIO. Same source code as used in LabVIEW 2010, but the .rtexe was created with LabVIEW 2011 and RIO 4.x instead of RIO 3.6.1 are installed on the sbRIO. I can't communicate with the Agilent DMM. The VIs are from the Instruments Palett, so they have to work.

The only way to get a running system is to uninstall all NI Software and go back to LabVIEW 2010 tonight.

LabVIEW 2010 SP1 with RIO 3.6.1 is the last worriless software combination.

Hopefully all problems are solved in 2012 but there is no time for me to verify it.

[nathand]

I had the same problem with an RT application that ran under 2009 but would not run properly under 2011.  The problem, as I mentioned in an earlier post, was a "Value" property node that apparently did not return an error in 2009 but does generate an error (probably correctly) in 2011.  I would check if your RT application uses ANY property nodes, and if so, either delete them or ignore any error that they generate.

[vgravel]

I was able to get rid of the problem by unchecking the "Bind FPGA Host reference to Type Definition". I now have to modify every subVI that use the FPGA reference after each compilation but the application is now working and I haven't got any problems since then.

I really don't know if it could do the trick in your case but worked in mine.

If you are desperate, try that.

Hope it helps!

Vincent

[Mugur]

My temporary solution in my case was to add timing to my while loop.

I didn't go back to 2010  as the point is to get an understanding of the programming procedure, which I thought I'm comforming to. 

I should mention that I've migrated from 2010 to 2011 and modified the VIs. Could this migration cause any issues? If I get the time I'll start from scratch... 

Yannis

[timpy]

I've had similar issues in LV2011 and LV2011 SP1f2.  The solution I found was to avoid having the RT read clusters from the FPGA using the read/write nodes on the RT.  The Clusters work fine in the FPGA, but the RT side of the cRIO will not read them reliably.  Work OK as code run from Windows in the development environment, but with a Startup.rtexe on the cRIO the RT side seemed to give every indication of not running at all.

Once I'd tracked the problem down, (this took all day, thanks NI) I tried playing with the settings for the RT build for type defined controls etc. but in the end added a parallel array alongside the all the clusters the FPGA is using, and the RT side reads these instead, which it does do, then then re-cast them to clusters on the RT. I also found that if you broke the RT read down to individual elements of the cluster on the FPGA then this works too.  In my application life is too short for that so arrays it is and the RT is now just a bit busier than it should be re-constructing my clusters again.

I've had better days.

Hope that helps someone.

Tim

[David-n-MO]

Matthias_T,

Just a warning about 2012.  If you use soft motion "advanced" trajectory VIs not only have they quit supporting them, they broke 'em.  Just saying...

[David-n-MO]

Ditto problem with 2011.  Wasted many hours trying to figure this out and seemed to have some success by unchecking the debug option in the build spec... but it came back.

Finally found this forum thread and thanks to vgravel I unbound the fpga open and replaced all of the references and it is working now.

Arrrrg! But at least I'll sleep well tonight.

[maxwellb]

Had this suddenly start happening on a startup app when trying to redeploy after increasing the sample rate on one of my modules in the FPGA VI. No mesages in error log. Worked fine in development. Spent hours trying to figure out what was up. After trying many other things, ended up fixing by removing all references to a certain typedef (an error cluster), including shared variables that were that data type.

I got clued in to this solution in a roundabout way. When rebooting the cRIO, the startup app would not start. But, if I tried to run the RT VI in development mode, I would get a message about conflicts with two items: the main RT VI, and the error cluster typedef. Earlier, when the startup app was successful, if I tried to run the RT VI in development mode, I would get a message about the main RT VI and all typedefs, not just the error cluster.

Maddening. Why can't we get some more feedback from the controller here?

[maxwellb]

Update: apparently that didn't fix things completely. I still have some trouble getting the startup app to run but now can usually do it by redeploying the app and rebooting the crio a few times.