Application builder causes problems with vi on RT target

[bscout]

I am developing a motion control application running on the cRIO 9012.  This application uses many softmotion VIs.  The VI runs fine when I deploy it from my PC, but when I build a source distribution, and try and run the 'clean' version, the VI crashes.  The bug is difficult to track down as the connection with the RT target is lost and cannot be obtained again untill the controller is rebooted.  Obviously this is related to the source distribution, but what.

A second somewhat naive, perhaps unrelated question.  Am I gaining anything as far as reliability when I make an exe.  I am only developing this application for inhouse use.  Do I "need" to build an exe, or am I better off leaving it as a normal VI? 

Bscout

[bscout]

Bump... any advice??

[RDR]

Hello Bscout,

What error message are you receiving when the VI crashes (also what version of LabVIEW)?  Also, are you using shared variables in your application?  By far the recommended way to deploy an application to a target with LabVIEW Real-Time is to create a Real-Time Executable.  Using the executable is a much more direct way to setup the application to 'run at startup'.  Where with the source distribution a somewhat "hack job" is required to set the VI as a startup VI on the target (you also will have to FTP over the files to the target).  I recommend using a Real-Time Executable when possible. 

-Bob

[MSATLAB]

Hi Bscout,

     What you also might want to try is to enable debugging in your application.  Then you can use the remote debugging session so you can find out where your problem is in your application.  Here is an article that I think should help if you would like to give this a try. 

http://digital.ni.com/public.nsf/allkb/3087D91EEADBAF3D862571D1004AF192?OpenDocument

I hope that this shed some light on your subject!

Michael

[bscout]

Thanks for the reply.  I don't get any error codes at this point because the application crashes and I lose connection with the network.  I'm trying to impliment a error log that will save any errors to disk, but the same problem occurs there (crash causes the program to lock up and not complete the shutdown procedures). 

Another problem that may or may not be related is concerned with cRIO module initialization.  I am using a 9237 strain module in addition to four 9505 motor drive modules.  As part of the initialization procedure, the controller is taken out of sleep mode, and the strain read property is set to true.  Once the program enters the main execution loop, It will read multiple values, then stop.  If I cycle the read property within the loop it will start reading as it normally would.  It only started exibiting this behavior once I started utilizing the sleep function.  Is the Sleep function somehow incompatible with the 9237 module?  Any advice is most welcome.

Bscout

[bscout]

So I put a shift register in to create an array of the strain values measured.  It turns out that what I thought was several new values at first was just the default values being flushed with one new value.  Why doesn't the module start before it enters the main loop.  It used to work, other changes within the program have somehow made this stop functioning.  Again, if I start the module within the main loop it functions as normal???

Bscout

By the way should this thread be moved to one of the hardware forums?

Message Edited by bscout on 09-14-2007 10:58 AM

[Nick R]

So we know it used to work, what we need to figure out is what changes did you make between now and then? Obviously something significant has been changed.

Are you setting the start bit for the 9237 in the FPGA VI or the host VI? If you look at the shipping example for the 9237 (NI 9237 Getting Started.lvproj) you'll see that they set the start bit in the FPGA VI, so once the FPGA VI is started in the host, that bit is set and acquisition starts. That could be causing problems.