Custom data type causing trouble in deploying shared variable to RT target

[parmstrong42]

I seem to be having some difficulty in using a network published shared variable created from a custom data type when deployed as an executable on an RT cRIO target.  I'll start by describing why I believe this is where the problem lies.  I created my RT VI in the LabVIEW development environment (LV 2012) and everything works fine.  This VI is pretty simple because it rapidly devolved in to a debug exercise.  The RT VI starts by simply blinking the User LED a couple of times and then starts a simple acquisition loop to read a few values off the hardware using the scan engine (while still blinking the User LED).  After reading the hardware, the values are bundled in to a cluster and written to a network-published shared variable defined by a type def custom control.  The custom control contains five dbl precision floats.  If it matters, the cRIO RT system hosts the shared variable in this case.

So, I deploy this under the development environment and everything works fine.  The LED blinks merrily along, telling me that the program is running properly.  Running a host VI that reads the network-published shared variable yields the desired result.  All is good.

Now I want the cRIO system to run this simple program autonomously at startup.  I build it, set it as the startup VI, deploy it and then restart the cRIO target.  The LED never starts blinking... the VI does not seem to run.  I will spare you most of the debugging work and jump to the end.  I basically "Diagram Disabled" various sections of code until the VI started running correctly as an executable.  I kept reducing the size of the disabled code until only one thing was disabled:  the write to the custom data type shared variable.

So, I guess my question is this:  Are custom data types defined by type def'd custom controls allowed in executable RT programs?  I've read through the cRIO Developers Guide, my NI Real Time Development course book and the Using Shared Variables white paper and I didn't see anything that forbade it.  I know that there are some things not allowed in executables that are allowed in the development environment (front panel property nodes, dialog VIs, OS-specific calls, etc), but no mention of custom data type shared variables.  Any ideas as to why my VI runs in the development environment but fails when compiled unless I remove the write to the network published shared variable?

Thanks in advance for your help!!

[BillMe]

Since you didn't mention, I'll ask: Are you handling the "error out" of the shared variable you're writing to?

[christian_w]

Compile your RT executable with debug enabled and step into the code.

Check where your SharedVariableEngine is located and that your *.aliases file points to the right machine.

Check your nirt.ini file for the following entries

RTTarget.ApplicationPath=/c/ni-rt/startup/<startup>.rtexe
RTTarget.LaunchAppAtBoot=True

I don't think that this is data type issue, but to be sure use a simple data type like boolean to debug your code.

Hope it helps

Christian

[pincpanter · Accepted solution]

You need to disconnect variables from the data types and recompile. You may find usefull to keep on disk a copy of the original lvlib.

Don't know if it's a bug or not. It was suggested by someone in the forum that putting the ctl files in the proper position (on disk? in the project?) would allow the rtexe to start; I made a quick check and it didn't work so I gave up testing further.

[parmstrong42]

Paolo,

So I thought that you meant to disconnect them in the build specification.  Under the Additional Exclusions in the build specification, there is a check box for Disconnect Type Defs.  I checked that box, recompiled, redeployed and it did not work.  At this point I had to give and move forward, so I was going to convert the data typed from a cluster to an array.  When I went in to change the data type in the shared variable pop-up from the project explorer, there was a big button under the variable definition that "Disconnect from Type Def".  Clicked that button, recompiled, redeployed, restarted and everything worked great.  Thank You!!

I suspect that I'll have to be careful if I change the definition of that data type (add an element, etc) since it is no longer connected to the data type.  We'll cross that bridge when we need to.

Thanks again

[BillMe]

Here's a link to the thread about this issue. It was fixed in LV2012.

[parmstrong42]

Thanks for the thread link.  I'm a bit confused, however, on the statement (by many) that it was fixed in 2012.  I was using 2012 in this instance, as was person in the linked thread.

Thanks again for the link!

[hkaku]

And I'm very sad to found this issue still exisit in LV 2013. 

[ba_0101]

I believe this issue still exists in 2013. I was having issue with a network shared variable (NSV) that was a cluster containing a string. When I disabled the NSV everything worked fine. The issue would only appear when the program was set to Run at Startup. When running interactively by clicking the Run button the issue did not occur.

[LucciolaGuo]

I heard that this issue is scheduled to get fixed in LabVIEW 2014.

Let's just wait.