Deployed software does not run on crio rt exe application

[mzamstl]

Hello I m working on a labview real time fpga project 

Project specs 

Labview 2011 professional development environment 

CRIO 9074

With 

Modbus i/o server 1.8

ni sound and vibration 11

http client 1.2.0

ni rio 4.0 

ni serial rt 3.8.1

network variable engine 1.8 

system state publisher 2.0

This application exe has the set as startup option enabled for deployment.  

In my application I have the crio act as a modbus slave, web server, signal processing and filtering, communicating with another labview program, to push data out to remote sql server database and the fpga as data acquisition.

For indication on whether the program is running I have the fpga led and user1 led to be lit after a certain period of time during the application, a web page with crio statistics, modbus master recieving data from slave, and another labview program communicating .

With ni dsm I can see when I deploy it or run as startup, the cpu spikes to around 90-94% then starts dropping to until 2% and then stabilises with periodic 4% jumps (I assume the fpga led light/ fpga is working). Memory is not issue because it hovers around 39.4 mb out of 124mb so there is no overload or leak there.

I don't understand how my application fails to run when its deployed or run as startup. Is there anything I obviously missed while deploying the software or is something wrong with my application even though fpga led light turns on but not the user1 led?

regards Mzamanstl

[SKauth]

I'm not clear about what kind of error messages you get, but you might have a similar case as I do.

Do I get it right that you can directly run your VI in Labview, compile your code, deploy it, but when you try to open a frontpanel, you get a message saying the VI is broken and you cannot open it?

[Sam_Sharp]

Are you using shared variables with type-defs? There is a bug in LabVIEW up to 2012 where if you have an RT executable that uses shared variables with type definitions the executable won't run when deployed.

The answer is to disconnect the type definition in the shared variable. I think it's fixed in 2013 onwards (perhaps?).

[mzamstl]

I ll make a post in your thread about what I did to overcome the compilation error I used to have.

To answer your question no, I can directly deploy my labview rt source vi, and watch it runs until it cpu maxes out to 100%  and stays there for 2-4 secs until it goes down to 2-5% cpu. That is with my front panel running after the source is deployed and no build specification SKauth .

[mzamstl]

To answer your question no,  every shared variable except one is used for modbus slave write and read addresses and the one exclusion is for writing error reports.

I used to have a type definition problem(Not a shared variable) but that was with an fpga type definition for fpga open vi reference, which has been resolved through the enabling the property 'disconnect the type definition' in my build specification Sam_Sharp.

I was aware of that issue while researching on how to fix type definition issue I had.

[Sam_Sharp]

---

@mzamstl wrote:

I used to have a type definition problem but that was with an fpga type definition for fpga open vi reference configure which has been resolved through the enabling the property disconnect the type definition in my build specification Sam_Sharp

---

When I had that problem, it wasn't sufficient to disconnect type definitions in the build specification. I had to manually 'disconnect from type definition' on the individual shared variables.

The next step would be for you to use the diagram disable structure and disable parts of your code until you can get your .rtexe to run on the target. It's also useful to add a loop that flashes the User1 LED (the one controlled from RT rather than FPGA1 LED) to help see if your code is running.

[mzamstl]

Do you mean right click the shared variable with a type definition then disconnect, like disconnecting from type definitions and controls ?

Ok I'll try your suggestion. 

[Sam_Sharp]

Yes - open up the shared variable (you only need to do this for shared variables) and click the disconnect from type definition button underneath the data type drop down.

[mzamstl]

Sorry for the delayed response

I disabled all the complex parts of the code except user1 led loop,built it then deployed it. It runs as expected but the full version does not run, I will continue to further test to identify what is preventing the crio from booting the startup app.

http://forums.ni.com/ni/attachments/ni/170/563040/1/Shared%20Variable%20Properties.png 

I did not have to do any of this for any of the shared variables, sorry for the confusion, that used to be an fpga type def like the image provided below(typedefimgfpgaopen.png).

[AndyH_DU]

I had a problem which sounds the same as this, LV2011 + cRIO 9074 + 9144 EtherCAT chassis running in hybrid mode.  Everything worked fine when running from the development environment but when I tried deploying the executable it did not run - no error messages or any indication at all.  I was fairly sure the problem was to do with the network shared variables, and was aware of the 'type def' problem so had selected the 'disconnect' option for the build;  but I never thought about discoinnecting the shared variables themselves from their type def's.  When I did this the executable ran fine ... so thanks very much for this post 🙂