bgapske

We have suffered similar issues with our plugin-based application using packed project libraries. Any time we loaded more than one packed library that called the same "inlined" VI (say for instance, a VI in our reuse library) as another loaded packed library, it would break with a similar message. Individually they loaded fine. In the end we just turned off the inline feature on the reuse code and all was well. We haven't yet got around to thoroughly investigating and reporting the issue, but I might suggest experimenting with removing the inline settings and trying again.

I'm not sure. Apparently the .licx file just tells the visual studio compiler to use some sort of license compiler when building an application. The compiled application then includes information which enable certain components to determine if the calling application is licensed to use them. My first attempt at contacting NI support resulted in me hearing the crickets chirping...though it looks like some of the measurement studio products use this same technology. Hopefully they will find the right person to talk to and get back to me with good news...

I'm curious if anyone has had any luck calling 3rd party .net code from LabVIEW that requires a licenses.licx file to be "embedded" into your executable (or else the 3rd party code will complain that it is not licensed.) Apparently this is a common scheme for people using visual studio. I have a feeling that I may be out of luck here...

A couple of my recent projects involve a number of RT targets and a central Host (or another RT target) I tend to prefer basic TCP for a couple reasons. Mostly because my RT targets have been pretty taxed when it comes to computing resources, and with TCP you can get high throughput with little overhead. (and you don't have to install the services that support shared variables,remote panels, web services, etc if you don't use them) One of my systems works similar to an example in the NI Simple Messaging Reference Library. I have the RT target acting as the “server” and listening for connections from the host. When the connection goes down, the RT target stops trying to use it and waits for the host to reconnect. I’ve had no issues with this to date. I can leave my targets running and connect to them whenever I want with the host application. The other reason I prefer TCP is that one of my systems (which I inherited) makes heavy use of NSV and remote panels and I’ve had a horrible time debugging it. This could very well (and probably does) have more to do with the way the code was written rather than NSVs or Remote Panels themselves, but the experience has left a negative impression with me. Warranted or not. The downside of TCP of course is that you may have to write more code. I do like that you can view the values of NSVs in the System Manager.

As Mellroth already suggested, I would certainly remove the call to configure the FIFO from the loop. According to the LabVIEW Help: "Before the new depth is set, LabVIEW empties all data from the host memory and FPGA FIFO." It doesn't specify whether the method checks that the new depth is different than the current programmed depth, but i wouldn't risk it... -Brian

Who is this "0bama" guy you keep referring to?