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

[HollyBerry]

Hi all,

Can any of you provide more details about what you experienced with deploying your shared variables? Did the work around of disconnecting the type def. work for creating a deployable application? It seems that several customers are experiencing this issue and I'd like to make sure that your efforts are documented for R&D as well as try to duplicate what you are finding here at NI.

I appreciate the time and effort! 

[MartinMeyer]

I've been doing a lot of development with cRIO, We have basically kept up with the new LV releases.  As of lately with 2013 we have seen some issues with startup, we are seeing several issues with getting a build to startup.  You have to do a different dance for the 9074 vs. the 9068.  I have not finished tracking this down, but based on my encounters with a PXI implementation I would guess a lot of this is due to using typedefs.  It is a rather huge time waster when there is absolutely no indication that RT is unhappy with the variable declaration.

On one of my RT-PXI applications, I just began to run into an issue where the startup executable would not startup.  The only message on the console is that the exe was started.  If I re-installed LV on the target, the code would deploy and start as long as I didn't make a change and re-deploy.  Disconnecting my network variables from the typedef allowed me to re-deploy and start...... once.  I had to disconnect typedefs from all of my SPV (single process variables) as well.  Since then I have been able to re-deploy (twice so far) and start on boot.

[HollyBerry]

Can you clarify what you have to do differently when running a startup exe with the cRIO-9074 vs the cRIO-9068? They are both running different operating systems but we want the user experience to be the same. Do you have a heartbeat LED or something going on the cRIO to show you when the application is running? What are your indicators for a successful deploy of a startup.exe vs an unsuccessful deployment?

[MartinMeyer]

We have an RT-PXI app that we have not had any trouble with running in interactive mode.  When we build an executable and deploy it, the console indicates that the exe has been started, but it appears that it never really starts the application.  With a console output message as the first thing to do, the message never appears.

We have been able to get it to run by commenting out an SPV that is being accessed in a function, but this same variable is accessed in other VIs without a problem.

It appears that something in the build, creates an rtexe which is corrupt.

Can NI look at the executable and determine what is going on?

[christian_w]

Enable the debug option and build a rtexe that you can connect with to see which VI is broken. We had similar problems where we just modified a control position on the panel and recompiled a working executable.

So try to find broken VI's by debug the rtexe.

Hope it helps

Christian

[MartinMeyer]

Thanks for the info.  The VI did show up as broken, however, it would not divulge why.  We spent quite a bit of time narrowing down the issue to an SPV that was read and written in a sub-VI.  This sub-VI did have the broken arrow indication.

We deleted the variable from the project and then re-added it.  This seems to have "fixed" the problem... for now.  We have had issues with network variables in the past, but single process variables always seemed solid.

We are using 2013 F2. 

[MPCC]

I am experiencing the same issue. It appears to be periodic. I am using a couple of local variables and earlier today, I had an issue with one of them. I diagram disabled it and deployed fine. Just recently, a different VI is giving me problems. I disable the variable and the problem goes away.

It's really a frustrating problem.

Also, it never happens when I use the run arrow. I only get an issue when I build an RTEXE and deploy. I find the problem VIs with the debug console. I've tried compiling with debugging off and the problem still exists.

[MPCC]

I just had some luck.

I'm going to test later to see if I can break and unbreak the project at will now.

Shutting off Debugging didn't help. However, shutting off debugging on all of the deployed VIs did fix the problem.

The easiest way to do this is to go into your build spec and select 'Set VI properties for all contained items' Click 'Custimize VI Properties' and disable debugging.

Please update if this work aorund fixes the problem for you all.

[MPCC]

Confirmed.

I was able to break and un-break my rtexe deployment by turning on and off the 'Allow Debugging' option in 'Customize VI Properties' in the build spec.

I'm still interested in getting feedback from the rest of you having deployment problems with local variables.

If this works, I'll try to get a CAR going with NI and hopefully get it documented somewhere.

[christian_w]

By default we disable the debug option via the build spec for all VI's. That isn't a long term solution but may work for a while. The same with deleting and readding vars...

The only safe way we found was to strictly avoid doubled access within a VI hierarchy and also in parallel working loops.

For now as a workaround we use queues to implement central access to shared variables.

THIS IS DEFINITELY A BUG   ...hard to reproduce