How to read Buffer from dll

[rolfk]

That API is kind of involved to understand and I haven't really studied it but my understanding of it is that each call to addSensor() needs to be matched with EXACTLY ONE call to releaseSensor() for that channel. You putting the releaseSensor() inside the loop definitely feels wrong.

And you are not using the VIs I created at all. They were specifically meant to work to above mentioned understanding and also deallocate the buffer created in the addSensor() VI, although you have to wire that pointer specifically between the addSensor() output to the according buffer input in releaseSensor(). To hide that in a more LabVIEW friendly way, one would have to use LabVIEW classes to store the communication handle and the buffer pointer per sensor in the class private data instead.

[Kern86]

I had some issue with integrating your VIs into my library. That's why I have adapted my subVIs to your specifications.

I have also connected addSensor buffer output to the input of the releaseMemory,as you did it. The problem is, that VI releaseMemory releases the memory already read by readSensor, which is why I placed it directly after readSensor in the while loop. I haven't integrated the subVI removeSensor yet, that removes the sensor.

So the connection from addSensor buffer out to releaseMemory buffer in causes a crash of LabView.

[rolfk]

Well I might then have misinterpreted the function of releaseMemory() and the DSDisposePtr() call should then be placed in the removeSensor() VI instead. Apparently releaseMemory() is not really releasing anything but simply adjusts the underlaying memory index for the sensor in question, that the memory portion that the returned pointer by readSensor() has been properly read and is now free to be reused. So it is not really releasing anything but rather just marking the buffer as processed so it can be reused.

That is the problem about interpreting function names. They can mean something pretty different than what they really do.

But to return to something you mentioned earlier: the pointer returned from read Sensor() may of course contain already data beyond a single block but according to the header file only one block is supposed to be read after every call to this function.

<param name="data">
/// Array von Daten. Die Anzahl der zurückgegebenen Samples entspricht der
/// Blockgröße des Buffers.

Translated it says: Array of data. the number of returned samples corresponds to the block size of the buffer.

Myunderstanding of this is that the block size is what you pass in to addSensor() (and the entire buffer is block_size * number_of_blocks samples).

[Kern86]

Yes you're right, i got some new information. The buffer is a circular buffer and the size is defined by blockNumber * blockSize.

readSensor outputs a pointer to the first element in the block, which I then read according to the size set at the BufferOut input, then the pointer address is incremented by the block size * 4 (int32). So it's exaclty as you wrote. So with a smaller blocksize I have to iterate the while-loop more often to get the data.

So, to make readSensor work properly there have to be at least the number of blocksize entries written in the buffer to not get the error message of "not enough data".

So back to my issue that I only can start my VI in highlighted mode or with a timedelay and afterwards I only get on block of data, this might be a timing problem? From my understanding there are either less values than one blocksize in the buffer or it came to an overflow and readSensor can't work anymore? Unfortunately I can't check this before monday.

The other problem I showed in the screencast that readSensor stops reading from buffer when I highlight something in the frontpanel can't be this buffer problem I explained above, right? Have you ever heard from something like this?

[rolfk]

---

@Kern86 wrote:

So back to my issue that I only can start my VI in highlighted mode or with a timedelay and afterwards I only get on block of data, this might be a timing problem? From my understanding there are either less values than one blocksize in the buffer or it came to an overflow and readSensor can't work anymore? Unfortunately I can't check this before monday.

For that you have the function fillSensorBuffers() if I understand its description correctly. It seems to be supposed to block and only return after at least one block of data is available to read.

The other problem I showed in the screencast that readSensor stops reading from buffer when I highlight something in the frontpanel can't be this buffer problem I explained above, right? Have you ever heard from something like this?

---

Well when you single step or do execution highlighting, your program is million times slower and then it is of course very likely that the circular buffer has overflowed in the meantime.

[Kern86]

Ok, I will try that. Unfortunately not before Monday.

I guess I have expressed myself incorrectly since this issue happens in several cases. After some preparation the VI works and plots the data correctly. But as soon as I highlight/mark an entry inside of the numeric control, readSensor stops to read any data from the buffer.I repeated this several times and as soon as I clicked into the numeric control and marked the numbers inside, the issue happens. During this I did not use the highlighted execution.

[Kern86]

Hi Rolf,

I just want to give you a short response. The data acquisition is working now, it was indeed a timing issue that caused a buffer overflow and the problem in plotting the data.

Thank you again for your help, I appreciate that!

Best regards

Lukas