RT Network Communication Problem

[cirrusio]

Hello all,

I am having an issue that I hope someone can help me with.  I am attempting to run a VI as an executable on a PXI chassis (8110) on RT.  I am able to run this VI, no problem when directly running the VI through the desktop (on the chassis).  However, when I attempt to run an executable based on this VI on the chassis (startup.rtexe), the VI seems to execute properly occasionally and I am unable to discern the pattern.  And to make matters worse, I seem to be unable to access the error logs through NI-MAX so all I have is the text based XML and there are no time stamps associated with the actual errors generated (is this the way they are supposed to be?).

My program when executed starts by sitting in a state in which it sends out a UDP packet every 10 s to a specific IP looking for a response (the packet is sent, the UDP connection is closed and a TCP listener is opened on a specific port; see below).  If no timeout is specified, the port will be polled indefinitely.  

When the VI executes properly (and the executable has executed properly), I am able to see these packets coming across the network using a sniffer (Wireshark) (below).  When the VI does not execute properly, no packets are visible.  The VI executes properly if run from the VI itself every time. 

 This issue only seems to pop-up when run off the executable.  I have even tried to run the above VI as the executable and I get the same behavior.  Does anyone have any thoughts as to why this might be occurring?

Thanks, Matt 

[MarcoMauri]

Hi!

It would help if you can post your VIs (LV8.6.1).

Marco

[cirrusio]

OK, so after a little more leg work, it appears that, when I debug the app on the chassis I get the warning that there is a series of "Unknown warning"s and they are all related to the DAQ dll nilvaiu.dll - "Error validating external library".  As it turns out, I can get the correct functionality of the VI above which pings for a connection; it is only when I attempt to run the app at large that I am getting a failure (sorry for the misleading entry above).  So, that being said - Marco, it is not feasible for me to provide the vi (see the hiearchy below to understand).  The architecture is highly LVOOP based and there are a lot of external libraries used (STM, OpenG, etc) as well as some config stuff that would have to be included for proper execution. 

Does anyone understand why I might get this warning?  I don't understand what validating an external library is....

Peace Matt

[StephanieA]

Hey Matt,

From what I understand, you can run the VI fine, but when you run your entire application, the subVI does not execute properly. You have a very complex architecture and I was wondering if you could do a bit more troubleshooting. Can we work our way up and see if running other subVIs that will call into this VI cause the same errors when debugging in the chassis? Let me know how that goes and I'll keep looking into the unknown errors you are receiving in the mean time.

[cirrusio]

Hey Stephanie,

Thanks for the reply.  It does seem that way.  But, I think the problem is that the application is actually not executing - i.e. there is some error that I don't see when I hit run on the VI, but pops up when the executable is run.  This means that I can run the VI on the chassis through the project explorer but the application does not always run properly when run using the executable.  Does that make since?  I suspect that I might be taxing the memory on the RT machine with the above heiarchy (it's LVOOP dependent so there are a LOT of VIs).  I just don't understand why it always runs properly when started from the host but not when the application is run from the executable.

Peace, Matt

[StephanieA]

Matt,

This does seem like weird behavior. I have not seen this before and without a reliable means to reproduce the error on my end, the help I can provide will be limited. What version of LabVIEW are you using? The only suggestions I have now are to tweak some of the build specifications when building the executable. You said the application does not always run properly. How often does it run correctly vs. incorrectly?

[cirrusio]

Any attempt is a good one, Stephanie  as this is incredibly frustrating.  More often than not, the application does not fire correctly and I have yet to pin down any correlation with operation.  As I told Marco above, this project is heavily LVOOP oriented and I suspect that I might be having memory issues (a little disconcerting as the project has the potential to get bigger).  I am running LV 2009 now.  Any suggestions would be appreciated, so send on what you got!  In the meantime, I am trying to reduce my memory footprint by reducing some acquisition rates and making sure most everything is in place.

Cheers, Matt

[cirrusio]

On another note that might be of some use to me - is there a way to view the error logs generated on the target in which I can retrieve a time stamp?  Currently all I can do is grab them via ftp and I get a string of errors listed in XML with no time stamp (not particularly useful to me).

[StephanieA]

Hey Matt,

One suggestion I have is when you are building your executable, we could try building in with the LabVIEW 8.x layout. In the Application Builder, click the Advanced tab, and then check Use LabVIEW 8.x file layout. Can you try this out and let me know if your application runs more consistently? How did attempting to reduce your memory footprint go?

To address you last issue, when you open an error log file, the very first line I see is the Date the log was taken along with a timestamp. Is this not the case for you? You mentioned you get a string of errors. Can you summarize your error log or possibly post it for me to take a look at?

[cirrusio]

Stephanie,

I get the following error when I do this:

Visit the Request Support page at ni.com/ask to learn more about resolving this problem. Use the following information as a reference:

Error 1357 occurred at AB_Source_VI.lvclass:Copy_SourceItem.vi -> AB_Build.lvclass:Copy_Files.vi -> AB_Application.lvclass:Copy_Files.vi -> AB_RTEXE.lvclass:Copy_Files.vi -> AB_Build.lvclass:Build.vi -> AB_Application.lvclass:Build.vi -> AB_RTEXE.lvclass:Build.vi -> AB_Engine_Build.vi -> AB_Build_Invoke.vi -> AB_Build_Invoke.vi.ProxyCaller

Possible reason(s):

LabVIEW:  A LabVIEW file from that path already exists in memory, or exists within a project library already in memory.

Visit the Request Support page at ni.com/ask to learn more about resolving this problem. Use the following information as a reference:
Error 1357 occurred at AB_Source_VI.lvclass:Copy_SourceItem.vi -> AB_Build.lvclass:Copy_Files.vi -> AB_Application.lvclass:Copy_Files.vi -> AB_RTEXE.lvclass:Copy_Files.vi -> AB_Build.lvclass:Build.vi -> AB_Application.lvclass:Build.vi -> AB_RTEXE.lvclass:Build.vi -> AB_Engine_Build.vi -> AB_Build_Invoke.vi -> AB_Build_Invoke.vi.ProxyCaller
Possible reason(s):
LabVIEW:  A LabVIEW file from that path already exists in memory, or exists within a project library already in memory.

Any thoughts as to what this might be attributable to?

Matt