Problem with RT Executable

[cirrusio]

It seems as if I have been down this road before.  I have a large application that is driving two different instruments from a single PXI chassis.  I am able to build the application for the two individual instruments, compile them and get correct behavior when run as an RT executable.  I am also able to drive the two instruments from a single VI using the debug environment (I essentially place the two individual applications into individual while loops set to run once in parallel on the block diagram).  However, when I build the build the VI containing the two applications into a single RT exe, I do not get correct behavior (i.e. does not behave as it did in the debug environment).  I have tried running the two as two separate VIs called in the rtexe (using both methods descibed here) as well as running them from a single VI which calls them as described above. I hope this isn't too vague, but does anyone have any thoughts as to why I might be able to run the combined VI from the desktop but not from an executable?

Thanks, Matt

[Brian_A]

Hi Matt,

One thought is that the process might have a race condition. Running in the Development Environment will cause your vi to run slower because the Real-Time OS has to constantly update the Front Panel. When running as a built *.rtexe, there is no Front Panel so the applications are able to run faster.

Have you tried running each sequentially from one vi? So run first vi » close first vi » run second vi » close second vi.

<Brian A | Applications Engineering | National Instruments> 

[cirrusio]

Brian,

Thanks for the idea.  As it turns out though, it appears that the shared variables that I use to drive this particular instrument are causing the whole system to choke when I build the whole thing into an executable (although they don't seem to be a problem in the other VIs).  When I set the rtexe up for debug through the "Debug Application or Shared Library" selection in the project menu, the front panel comes up with a broken arrow.  When I remove references to SVs, the system runs.  Any thoughts as to why this might be?  All SV libraries have been deployed onto the RT chassis.

Peace, Matt

[viScience]

Hi Matt,

Do you have error chaining on you SV's? 

What kind of SV's are these? Static nodes or API?, Bindings, etc?

[cirrusio]

Hey sachsm -

There is no error on the error chains connecting the SVs because the rtexe does not execute (i.e. in debug mode the little run arrow at the top is broken).  The SVs are network published, unbound, static variables (i.e. I am not using the API for programatic access).  I have narrowed the problem down to two varaibles which are both type defs:

• The first is a cluster that contains five identical clusters, each carrying two single precision floats.
• The second is a cluster cluster that contains two single precision floats.

So, there must be something in my libraries (I have three deployed) related to this cluster type which are causing issues (in another library, I have a variable similar to the second that has been successfully deployed).  I can work around this, but there are a couple things I am going to try. 

This still seems to be odd.  Thanks for the help.

Peace, Matt

[viScience]

I wonder if this could be related...

http://forums.ni.com/t5/LabVIEW/executable-searching-for-typedef-shared-variable/m-p/1481190?require...

[cirrusio · Accepted solution]

Definitely sounds like a similar issue.  However, I wonder if this is just not a quirk that is not entirely unexpected.  The way I got everything to work ultimately is to disconnect the typedefs of those two variables that were causing a problem.  I am not certain that the actual typedefs were used on the server side so they might not have showed up in the dependencies.  In that case, the typedef (it seems to me) would have been lost and the SV would not know what to do with the data.  Just a thought.  Would have been nice if an error had been thrown somewhere.

Peace, Matt

[jmorris]

mtat76,

I had a similar issue in the RT executable I am building, and not even disconnecting from the typedefs fixed it, annoyingly.  I ended up having to create copies of my typedefs that were defined as custom controls rather than typedefs or strict typedefs, and associate the shared variables with those.

Now that you mention it, though, I am curious if the only problem was a lack of the typedef being copied onto the server.  Did you try selecting the typedef files in the build specification and mark them as "always include"?

-Joe

[cirrusio]

Sorry Joe, but no.  We were in too big of a hurry to ship out and I didn't get a chance to really flex the issue (although I did want to try that).  Try it out and let me know how it turns out 😉

m

[Jed394]

I had a similar issue as well that might be related. I was using strict type def custom controls to define a set of Network Shared Variables.  Everything worked fine until i built the application and ran it on a clean machine.  Long story short, everytime i opened the application it would search for the controls and not find them even though each one was used within the program and i had specifically included them in the build.  After trying several differnt approaches, including changing build settings, i ended up having add an additional instr.lib subfolder to executable directory and dropped copies of the custom controls in there.  This cleared up the issue however i really don't enjoy this approach.

In my case it labview seemed to be searching for this instr.lib folder.  On my development machine, my custom controls where not stored in that directory and not know that much about labview, i'm not sure why it defaulted to this location on the clean machine.