Cannot Retrieve Counter Input Measurements from USB M Series

[John_P1]

I have an application where I need to measure an indefinite number of semi-periods using a buffered counter input task on a USB M Series (6221).  Since the number of pulses is indefinite, I have made the task continuous (but a finite task with a larger buffer than my actual number of semi-periods gives the same behavior).  I start the counter input task and then trigger an external pulse generator.  I receive a signal telling me the external pulse generator has completed, and at this point I know that I can read back all acquired samples.

I anticipated that (for a low number of pulses) reading -1 would simply give an empty array as my samples would be sitting on a USB hardware FIFO and DAQmx would have no way of knowing about them (indeed this is true).  However, it turns out that reading any finite number of samples does not initiate the transfer and instead results in a timeout (even with the timeout set to the default 10 seconds).  It seems that after DAQmx Read is called an additional pulse is necessary to initiate the transfer of the buffer to software (as if there were some sort of pipeline).  However, for this application to work I need to read after the last pulse has been generated so I can measure all of the pulses.  Generating an extra pulse after reading does allow me to read back my full buffer, but I can't afford to send an extra pulse (which would trigger my pulsed-power curing system) just to read back my data.

Here is a simple reproducing VI:

I should also mention that the behavior is correct on USB 621x (and so probably X Series as well).  That is, reading a finite number of samples initiates the transfer (no additional pulse is necessary) so I can read 1 sample followed by -1 to get all of my data.  Internal busses (PCI/PXI/PCIe/PXIe) don't have the USB FIFO and so I wouldn't expect them to show the behavior either.  To reproduce you would need to run this on a USB 622x, 625x, or 628x.  

If I make the task finite and provide the correct number of pulses it works (I can just read back the desired number in one go), but as I don't know how many pulses will be generated I have to make the task either continuous or finite with some larger number--in either of these cases it seems impossible to get all of my data back.

Does anybody have a way to initiate the transfer from a (non bus-powered) USB M Series semi-period task once the signal source has stopped generating pulses?  Changing hardware (or some other solution like time-stamping a DI change detection task) isn't an option to me as we have several systems deployed to customers already and this particular input is hard-wired to a PFI line of a USB 6221 OEM.  The USB Xfer Request Size property doesn't seem to be supported on USB M Series for semi-period tasks.  I've also tried querying Available Samples per Channel (thinking perhaps this might initiate a transfer) but it didn't make any difference.

Best Regards,

[John_P1]

I have a workaround--it turns out that my existing hardware connections also include this trigger line routed to an analog input so I am now sampling the pulse signal along with my other analog data and no longer using a counter to measure the array of semi-periods.  This is not ideal as it affects my maximum per-channel ai sample rate and the resolution of the semi-period measurement is much smaller than I would have been able to achieve with the counter.  Future systems we ship will also have this line jumpered to a digital input on port 0 so I can take advantage of correlated DIO to make the measurement and avoid these two drawbacks.

So, I guess I'm good to go for now, but if an NI employee can confirm they can reproduce the same behavior and let me know whether or not it might be fixed in a future DAQmx version (or even just provide a CAR ID) I would appreciate it.

Best Regards,

[Nathan-P]

Thanks for the post, I'm looking into the problem, trying to aquire the hardware, but there may be some more delay in getting back to you due to NI week.  Thanks!

[ZachHindes · Accepted solution]

Hello again John!  You sure do push our products to the bleeding edge!

Unfortunately, in this case, this is the intended behavior.  NI Signal Streaming technology allows for us to do high bandwidth applications across packet based buses such as USB, Ethernet, and Wireless.  Unfortunately, our first generation DAQ products to use NI Signal Streaming technology were based on the STC2 ASIC which wasn't originally designed with NI Signal Streaming in mind.  Counters, in particular, are a special cirumstance where it is especially quirky.  When you call DAQmx Read, we usually indicate to the device to send across all the necessary data that you've requested in lieu of creating a maximum sized packet for the best use of the USB bandwidth.  In the counter, case, however, we actually have to indicate to the device to send one more sample than you actually want.  The reason for this is that we need to manually check for error conditions on the counter subsystem before we send you any data that may be invalid.  Because of that we inject an additional step in the chain of events before the data is sent across the bus to ensure the data that we are sending is, in fact, valid.  This requires us to acquire one more sample of data than we expect to kick the subsystem into indicating any error conditions that may have occurred.

Like you noticed, this should only be an issue on Self-Powered USB M Series devices.  Bus-Powered USB M Series devices (USB-621x), X Series (USB-63xx), and all plugin devices should not have this issue.

[John_P1]

HI Zach,

Thank you for the response--even if there is no other workaround I'm still glad to know that there is a reason for the quirky behavior.

Best Regards,