Multifunction DAQ

cancel
Showing results for 
Search instead for 
Did you mean: 

Current Read Position exceeds size of buffer? VB6 with NIDAQmx 9

Solved!
Go to solution

I have an application written in VB6 that does continuous AI and AO, with both using the internal Ctr0 as the clock to ensure they are synchronized.   It seems to work very well.  I'm using a USB-6212 and a recent version of NIDAQmx.

 

I am tracking the Current Read Position by calling DAQmxGetReadCurrReadPos_VB6 in the EveryNCallback routine.

 

Strangely, the value reported for each call correctly increases by the number of samples returned (eg 128) but instead of wrapping round when it reaches the upper boundary of the buffer (eg 16 * 128) it just keeps growing ad infinitum.  No error is reported by the call to DAQmxGetReadCurrReadPos_VB6 or anything else.

 

Am I misunderstanding something?  This functions seems to be just returning the total number of samples read, not the position in the buffer.

 

What I had expected was the value of Current Read Position to be:

128,  256,  384,  etc.  up to the limit of the buffer eg 16 x 128 = 2048 at which point it would start again at 1 (or zero depending on how you set up your arrays). 

 

Van

 

 

0 Kudos
Message 1 of 7
(4,049 Views)

Hi afmstm,

 

It appears as though the output of the DAQmxGetReadCurrReadPos may be a pointer.  Have you tried getting a value from that pointer location?  I believe you are correct in stating that it should display the current position in the buffer in samples per channel.

 

Lynn

National Instruments
Senior Systems Engineer
0 Kudos
Message 2 of 7
(4,028 Views)

Hi Lynn,

 

Do you mean pointer as in the sense of a C pointer into memory space?  That can't be correct because the values returned are small, and each time it gets larger by an amount equal to the amount of data read.  It seems like it works correctly up until it should "wrap around" but it doesn't.  Here is an example from the start of execution.  The relevant code is:

 

   DAQmxErrChk (DAQmxReadAnalogF64(mTaskHandle, sampsPerChan, 1#, DAQmx_Val_GroupByChannel, _
               AIData(0), sampsPerChan, sampsPerChanRead, ByVal 0&))


   DAQmxErrChk (DAQmxGetReadCurrReadPos_VB6(mTaskHandle, readpos))
   Debug.Print "Read position = " + CStr(readpos)

This code is in the EveryNCallback routine, which is called every time 512 values are read.

 

Output, when sampPerChan = 512.

Read position = 512
Read position = 1024
Read position = 1536
Read position = 2048
Read position = 2560
etc - it just keeps getting larger and larger.

 

In fact, what this function seems to be returning is the total number of A/D readings made since the program started. 

 

Thanks,

 

Van

 

 

0 Kudos
Message 3 of 7
(4,020 Views)

Hey afmstm,

 

If you change the sampsPerChan, do you see the same behavior?

 

Lynn

National Instruments
Senior Systems Engineer
0 Kudos
Message 4 of 7
(4,003 Views)
Solution
Accepted by topic author afmstm

Hi afmstm,

 

The behavior you are seeing is indeed the correct one, and I agree that the description for it is misleading.  The current description says: 

   "Indicates in samples per channel the current position in the buffer."

The description should be interpreted as:

   "Indicates in samples per channel the current position in the acquisition."

So yes, to get a relative position within your buffer you need to perform a modulus operation.

 

That being said, this is not the same thing as "total number of A/D readings made since the program started" as you said.  That would be the Total Samples Per Channel Acquired attribute.  There is rarely going to a chance where these two attributes align.  For example, to read N samples successfully the following must be satisfied:

   Total Samples Per Channel Acquired - Current Read Position = N

 

Another distinction is that you, the user, can modify the Current Read Position using the Relative To and Offset properties.  By default you will be reading relative to the Current Read Position which creates the behavior your described.

 

I know this stuff can be confusing, but this level of streaming manipulation is a very advanced DAQmx concept.  Let me know if this brings up any more questions or concerns!

 

------
Zach Hindes
NI R&D
0 Kudos
Message 5 of 7
(4,001 Views)

Zach,

 

Thanks much for the clarification.  This makes a lot more sense now.

 

The behavior I want is to always read the most recent N readings when I call DAQmxReadAnalogF64 (I don't care if I lose some data in the mean time).  To do that, I presume I set Relative To to DAQmx_Val_MostRecentSamp, and set Read Offset to -N.

 

Van

0 Kudos
Message 6 of 7
(3,995 Views)

That is exactly how I would recommend doing it!

------
Zach Hindes
NI R&D
0 Kudos
Message 7 of 7
(3,984 Views)