memory mapped file access problem

[mitulatbati]

Hello,

I have written a kind of engine, compiled in a dll. I´m using Memory Mapped Files (MMF) to enable communication between the engine dll and LV/TS/CVI etc.

There are two MMFs built in the dll:

a.) one stores a big amount of data. These data can be asked from the engine

b.) one serves as a semaphore, or better to sayy handshaking. This one is 1 byte long. If I write 1 to this byte, the engine collects data, and puts them into the MMF described in a.) When the engine is ready, it cleard the byte to 0.

So I set the byte to one, wait until the byte is 0 again, then I read the delivered data. This works fine, if I do everything in LabView. But if I call the "asking" VI from TestStand, it works by turns. Once works, the second time not, then works again, then not.

I thought, if I run a VI in LV, the same should happen if I call it from TestStand. It seems not to be the case.

Furthermore I thought, that a memory mapped file can be used independent of the platform.

Any help?

[RuedigerE]

Hello,

is it possible that you attache the DLL, MMFs, LV and TestStand files. It looks like TestStand needs to calls to the LV VI in order to successful write to the MMF.

Regards

Rüdiger

[mitulatbati]

Hello Rüdiger,

thanks for the reply. How do you mean "attach"?

[RuedigerE]

Hello,

I would like to reproduce this issue. Could you narrow down the problem to a simple code example and post this example so that I'm able to reproduce the issue?

Below you will find a basic example for MMF and LV.

http://zone.ni.com/devzone/cda/epd/p/id/2778

Regards

Rüdiger

[mitulatbati]

Hi,

it's not so easy to narrow all my codes.

But I also have written a library for memory mapped file, used the kernel32.dll.

[Leguim]

Hi,

This example is very interesting for me. I'm trying to split my aplication in several ".exe". But I need to use larger files.

Anyone knows how to modify this VIs in order to achieve write more than 4096 bytes?

Regards.

[rolfk]

Old post but the memory map is NOT limited to 4096 bytes. However whoever calls the CreateFileMapping() function first will determine what is the maximum size of the file that backs up the memory map. And calling CreateFileMapping() again for the same object will then behave like OpenFileMapping(). The size parameter is ignored and whatever size the first CreateFileMapping() call used will be used again.

[wiebe@CARYA]

This is old... Not sure if a solutions is even being watched?

In LabVIEW, there is one VI that handles the interlock. So as long as everything is done from LabVIEW, it's fine because the VI is not re-entrant (or not called in parallel). So the VI can only executes once at the same time. When called from LabVIEW and TS, the VI is executed in parallel.

Reading and writing of the single byte takes several steps. So this might be happening:

1) LabVIEW sees a 0, and continues.

2) TS sees a 0, and continues.

3) LabVIEW writes a 1.

4) TS writes a 1.

5) Both start writing... 

IIRC (and quick google seems to confirm that) memory mapped files have options to lock files when opened, just like normal files. That would provide a safer interface.