producer/customer architecture sync

[JÞB]

As Felix says- Always- Always- Always add an "end" command in your queues, the Producer can release without destroying, then let he CONSUMER force destroy the empty queue.  IMHO this approach is much more maintainable and the consumer operation much more intuitive.  It also prevents the follow on code maintainer from libeling your good name.

[krivan]

I implemented Felix's solution and it is working at the moment. The only thing I noticed is that the occupied memory space is crawling up slowly even if I put a 100 ms delay  in the producer loop.

Any ideas how to avoid this? VI is attached.

[deyyoung]

I don't think you need the shift registers on the queue wires; that could be causing your problem.

[Mark_Yedinak]

When you post code you should make sure you post all of the code. It comes up with lots of missing VIs.

[krivan]

Yes, I forgot the dependent VIs. Sorry. See attachment.

[SteveChandler]

Although slightly off topic from what this discussion has evolved to, I found this cool nugget on communicating between loops which was your original question. It shows almost every way that you can do it.

[Mark_Yedinak]

I'm not seeing any memory increases when I run the application. How long are you running it for? I don't see any strange behavior.

[krivan]

I ran it for hours and during this time [according to the Windows Task Manager] the occupied memory space of the LabVIEW.exe increased from ~120 MB to 518 MB.

Also strange that when I clicked on the STOP button, the TDMS Viewer popped up, nothing was displayed in it, I saw only that the occupied memory space dropped and started increasing again...

[krivan]

Hi,

I modified the code, it works better now, while acquiring there is no memory increase any more, only when the TDMS tried to open the file. However regarding the TDMS output I ask for assistance because I get very large matrixes at the end...

Basically the code acquires data on 16 channels 1000 points at 10kHz. The acquired waveform data points are averaged and are stored in a 64x64 large matrix. It continues until every matrix element is substituted by measurement results. The 64x64 matrixes are temporarily stored in a 1000 element long 3D array. After the 3D array has been filled up the data is transferred into the queue and streamed out into file.

The problem is that although the important data is correctly written in the file but I get lots of zeros at the end. The matrix is 64 x m instead of 64 x 64 where m is 3-4-5 times larger than 64, don't know the exact number. It happens to every group in the TDMS file.

I did defragmenting as well but it actually does not bring any good so I skipped it.

The size of the TDMS file is always increasing rapidly however that shouldn't be the case. The matrix contains double type numbers, it is 8 byte each. A 64x64 matrix should be 32 KByte. I transfer 1000 matrixes so 32 MB into the queue

I attached the VI and the tdms_index of the most recent file [tdms file: 1.19 GB, tdms_index: ~300kB, acquisition time was less than a minute]

Can somebody please advise what I am doing wrong?

Thanks,

Krivan

[krivan]

In the meantime the problem has already been solved.