Multifunction DAQ

cancel
Showing results for 
Search instead for 
Did you mean: 

DAQmxReadDigitalLines odd behavior

I am confused by the documentation and behavior of DAQmxReadDigitalLines(). The function has parameters sampsPerChanRead and numBytesPerSamp. These should tell you how many bytes were read in a given call.

Now I do something like this (please pardon the elipses):

DAQmxCreateTask(...)
DAQmxCreateDIChan(... "dev1/port0/line0:3", DAQmxChanForAllLines)
DAQmxCreateDIChan(... "dev1/port0/line5:7", DAQmxChanForAllLines)

DAQmxReadDigitalLines(... &sampsPerChanRead, &numBytesPerSamp)

This reads just one sample, as I have not configured any timing for it. The values of the parameters are
sampsPerChanRead=1
numBytesPerSamp=4

but I see that the data array has 7 bytes set. This looks like a bug to me: the value of 4 bytes would seem to come from the fact that I configured 4 lines in the first call to DAQmxCreateDIChan(). The actual 7 bytes read would seem to come from the fact that I configure a total of 7 lines in the task.

My guess is that this isn't the way I was expected to do this, so this case was overlooked.

Is that right?

Thanks for any light you can shed on this matter.
John Weeks

WaveMetrics, Inc.
Phone (503) 620-3001
Fax (503) 620-6754
www.wavemetrics.com
0 Kudos
Message 1 of 3
(4,278 Views)
Hi John, what you're seeing isn't a bug, but I agree that it could probably be documented a bit better.

By using the DAQmx_Val_ChanForAllLines option in your two calls to DAQmxCreateDIChan, you've created two channels: one with 4 lines, and one with 3. When you call DAQmxReadDigitalLines on this task, you get back 4 for numBytesPerSamp because the data will be returned in readArray in 4-byte chunks (because the 4-line channel is the largest channel in your task). The first four bytes in readArray correspond to the 4 lines of the first channel (lines 0-3). The next four bytes correspond to the the second channel, but only three of these bytes are filled because there are only 3 lines in the second channel. If you had read 2 samples per channel you would see that the first seven bytes are filled, followed by an unfilled byte, then followed by another seven bytes.

The documentation of the readArray parameter attempts to convey this info, but doesn't do a perfect job. 🙂

readArray uInt8 [] The array to read samples into. Each numBytesPerSamp corresponds to one sample per channel, with each element in that grouping corresponding to a line in that channel, up to the number of lines contained in the channel.

If you had used the DAQmx_Val_ChanPerLine option when calling DAQmxCreateDIChan, you would end up with 7 channels (one line each), and when you called DAQmxReadDigitalLines, numBytesPerSamp would be returned as 1.

Let me know if I can help further.
Joe
Message 2 of 3
(4,267 Views)
Thanks, Joe.

Your explanation makes sense, and it's one option that I had considered. But I prefer actual confirmation instead of speculation...

In fact, I contrived the example to test exactly that point. For my needs, you are probably correct that using ChanPerLine would be the right way to go.

Again, thank you.
John Weeks

WaveMetrics, Inc.
Phone (503) 620-3001
Fax (503) 620-6754
www.wavemetrics.com
0 Kudos
Message 3 of 3
(4,254 Views)