Multifunction DAQ
Differences between 64xx and 63xx multifunction hardware
I have a project that has been using a USB-6341 successfully for a several years. It does some straightforward hardware timed DO, bit-banging a protocol at ~1 MBit data rates for some really low-level custom protocol testing.
Recently I needed to duplicate the test station. The mioDAQ option is cheaper than another 6341, so I got one to try out.
Unfortunately there seems to be "something" different about it. I've run the same code on both, and it seems that the mioDAQ is missing some of the initial samples.
Is there some difference in how these two cards operate for hardware timed digital output? On paper, the 6421 should be better. It's USBC, has a DO FIFO of 8,191 samples, and claims up to a 10 MHz DO sample clock. The 6341 is USB 2.0, has a 2,047 DO FIFO, and maxes out at 1 MHz on its DO sample clock.
My application generates several million samples so I haven't nailed down EXACTLY what's going on yet. I'm currently playing with my oscilloscope to try to verify exactly what's happening to get a minimal reproduction.
But my basic question- Is there any difference in the 64xx and 63xx multifunction DAQ hardware that requires different configurations?
OK, the oscilloscope got me data much faster than I thought. There's definitely something weird going on here. I opened up the Digital - Finite Output example. My settings were no trigger, desired sample rate of 921600, source of OnboardClock. I did replace the Data to Write with a simple boolean array of 96 samples doing a recognizeable pattern.
Running the example code with the 6341, I get the following on the scope:
The VI reports an actual sample rate of 917431, which is expected. Total waveform length generated is about 103 µs.
Changing to a 6421 gets me this:
It idles high, then goes low and stays that way for nearly 14 ms. After that 14 ms, I see the following:
Very similar... except for the very start.
Zoomed in on the 6341, you can see that it starts high then goes down to low 3 times before staying low- a pattern of [...]11110101010000[...]. A total of 7 total transitions.
And the 6421- you can see that it went low for ~14 ms, then went high, then started going low. The pattern was [...]11110000[...]10101010000[...]- this is a total of 9 transitions, including the one offscreen.
The output array is supposed to be [...]111110101010000[...], or 7 transitions.
The 6421 is apparently adding a transition to Low, idling about 14 ms, then going back to High, THEN executing my profile. It's adding an extra "bit" to the datastream.
Example code is attached.
Edit: Forgot a dependency
Taking some more data, as I know that last bit was probably confusing.
This time I'm writing the data 101. Written repeatedly, you should see the line idle high, drop low for one count, then go high again. On the 6341, that's exactly what you get:
However, on the 6421, it again drops to Low for ~14 ms, then does the pulse:
And zoomed in at the end:
This smells of a code delay, so I added some delays... lo and behold, calling DAQmx Write- before the task starts, and with Auto start disabled, the output will drop to Low until you call Start Task, at which point it writes the 101 data. Adding a delay between those functions increases that delay. For example, a delay of 1000 ms between Write and Start gets this:
More testing to come...
And one final bit of data. Playing around with Control Task, I found that, when you Commit this device, it sets the output Low seemingly immediately, then writes the data to the output when you call Start Task.
Still no idea why it's behaving this way. I'm not calling any resets or anything, plus the startup states for both devices are identical, and I'm using port 0/line 0 on both, so I should have all the same features.
@Kevin_Price wrote:
Tossing out some thoughts, but bear in mind I've never used a 64xx device and only just now did a cursory look at the specs page. I also read through the related thread on the higher-traffic LabVIEW board.
One thing I noticed is that the 6421 shows 16 DIO lines on port 0 that can be used hw-timed waveform DIO OR can be used as PFI timing signal terminals. This is a departure from prior generations of MIO devices (X-series, M-series) that strictly separated port 0 for waveform DIO with NO PFI functionality and ports 1,2 (etc.?) for PFI functionality AND static DIO (though, obviously, only one can be granted resource rights to drive the line as an output.)
Dunno what role this would play in your observations, if any at all.
I gather that an explicit "commit" causes the 6421 to go Low but not the 6341. It has sounded like the same thing happens upon a pre-start Write without an explicit commit -- do I have that right?
You've mentioned that both 6421 and 6341 were configured with the same default power-up output states, but didn't say whether they were defaulting High or Low. Have you experimented with changing both to the other default state? I imagine you'd want to try setting up your writes for both 101 and 010 in each case too.
Another thought just to probe at this thing a little more... How about experiments setting both devices up for software-timed DIO? What happens there if you commit before writing? Again, dunno what to do with the answer, just probing around to fill in some blanks in hopes that a little insight pops out.
- also puzzled,
Kevin P
Great questions as always, Kevin!
Correct in your statement about the commit. Calling pre-start Write, or Committing the task, causes the output to go Low. I'm assuming it's the Commit that's doing it, as the pre-start Write puts it into the Committed state (I think). It's interesting to note that no data has been written at that point, so writing 101, 010, or even 111 has no effect on what's happening.
I tried playing with the power up states as well, and nothing I did changed this behavior. The Help explicitly says it's for "when the device is powered on or reset", so I think those states may be a red herring. Setting it to High or Tristate causes the line on the 6421 to go Low on Commit, so it seems unrelated.
I've played with some software timed DO and don't see any similar behavior, though I don't think I've tried explicitly Committing it in Software Timed mode. That's a good check and I'll see if I can give it a try soon.
Also, FWIW, I submitted a support ticket to NI, who has been able to reproduce the issue on their end. They've acknowledged this isn't ideal behavior and we're looking at workarounds right now.
I have been in contact with NI tech support, and they have confirmed this is a bug. They're working on a fix but have no ETA.
Another update from NI tech support: this now has bug number 4012966. No ETA for a fix yet, but they have suggested a workaround; it seems that the bug doesn't show up the FIRST time you run a task, so if you call DAQmx Reset Device after each run, it shouldn't show up. I haven't confirmed this myself but the R&D team seems to have vetted it. This will definitely get me going for now; hopefully they can figure out the root cause and make a patch, but who knows when that'll be.
