Named LabVIEW FIFO and Application Instance/DLL

[Bradley Hughes]

Hi All,

I'm working on a sensor logging application in LabVIEW 8.5.

Each sensor driver (written in LabVIEW) has its own loop and has a corresponding named-FIFO that the most recent read values are written to. One of the drivers uses VISA for RS-232 and another uses DLL calls to a library that interfaces with a USB-I2C convertor. 

The main logger reads from all of the FIFO's, concatenates the data in chronological order as they are sampled from the FIFOs, and writes to a combined log file. 

The third logger that I'm adding now must be written in C due to the nature of the sensor it interfaces with. Each set of new data that comes in will be written to file. I'd like to pass a message from the C program to the main logger that includes the file name and position of the written set of data; this information will be concatenated into the main log for time sync purposes. 

My first hunch for easy synchronization is to write a VI (compiled as a DLL using the LabVIEW application builder and called from C) that will use a named FIFO to pass a string from the C logger to the main logger. But, I'm not sure how named FIFOs are shared between application instances. 

That is, if I have a named FIFO reference "test" in a VI compiled and called as a DLL and a named FIFO reference "test" in the Main Application Instance (or a project's specific application instance running on the same Windows machine), do they point to the same structure? Or, are they specific to each instance? If they are specific to each instance, what do you suggest as a method to be the least hassle to get data between applicaiton instances?

Thanks in advance!

Bradley Hughes

[rolfk · Accepted solution]

---

My first hunch for easy synchronization is to write a VI (compiled as a DLL using the LabVIEW application builder and called from C) that will use a named FIFO to pass a string from the C logger to the main logger. But, I'm not sure how named FIFOs are shared between application instances. 

That is, if I have a named FIFO reference "test" in a VI compiled and called as a DLL and a named FIFO reference "test" in the Main Application Instance (or a project's specific application instance running on the same Windows machine), do they point to the same structure? Or, are they specific to each instance? If they are specific to each instance, what do you suggest as a method to be the least hassle to get data between applicaiton instances?

Thanks in advance!

Bradley Hughes 

---

Queues, Semaphores etc are not shared at all between application instances (well they were in LabVIEW 8.0 but that was really a bug). However just because you call a DLL that uses a LabVIEW DLL with a queue does not necessarily mean that you work in two different application instances. If howwever you intende to write an independant C program that runs as seperate process you can definitly not connect back to a LabVIEW queue in this way. The LabVIEW DLL will be loaded into the according LabVIEW runtime engine but in the context of your C program process.

Even if you would make this a C DLL that you call from within your LabVIEW application and that calls said LabVIEW DLL to communicate through the queue you can be in problem. This will only work if the LabVIEW DLL and the LabVIEW application that calls your DLL is written in the same LabVIEW version. In that case the DLL is loaded into the already running LabVIEW development system or in the case of a built applciation in the already running runtime system. Once your main LabVIEW app and the LabVIEW DLL are not the same version, the DLL will be launched out of process in the according runtime system and as such it will really execute in its own process.

Rolf Kalbermatter

[Bradley Hughes]

That answered my question; thanks! I'll structure it a bit differently witn DLL calls to do the acquisition and pass back a byte array for the filename instead (from the C functions to LabVIEW.)

Bradley Hughes

[mitulatbati]

Hi Rolf,

I believe, you can answer my question as well.

I have a dll with some functions, which dll has been  compiled in LabView. As a part of this dll, an engine runs in the background. This engine collects data, and I can communicate with the engine via Notifier/Queue. So that an "asking" VI sends a request to the engine, the engine answers. It wors fine, if I let it run in LabView. But if I compile it to a dll, it doesn´t work - altough both VIs (which requests data from the engine, and the engine) are parts of the same dll. For my understanding, I work in the same application instance. Or not? Why doesn´t it work?

regards

MB

[mitulatbati]

... I have forgot to mention a tiny thing. I call the dll to start my engine directly from TestTtand. I request the data in LabView, so that I call the same dll in LabVIEW.

I already tried to use Memory Mapped Files, but without success.

[rolfk]

---

@mitulatbati wrote:

... I have forgot to mention a tiny thing. I call the dll to start my engine directly from TestTtand. I request the data in LabView, so that I call the same dll in LabVIEW.

I already tried to use Memory Mapped Files, but without success.

---

I would guess this makes all the difference. As far as LabVIEW is concerned TestStand launching the DLL process creates its own runtime engine instance, and when you then try to call that DLL from within LabVIEW it gets loaded and instantiated in the LabVIEW process again. Obviuosly the two DLL instance can't share anything that is not shareable for out of process use.