Digital I/O

cancel
Showing results for 
Search instead for 
Did you mean: 

Streaming Dynamic Acquisition will not work when acquiring record in digital waveform format

I have a 6544 card that I am programming with LabVIEW / HSDIO driver. I was able to run the example "Continuous Acquisition - Stream to Memory.vi" with no problem. If I remove the case structure, and change the polymorphic instance of "niHSDIO Fetch Waveform" from 1D U32 to "Wfm Data Type", the example breaks. I have attached this modified version to this post. The "Fetch Backlog" property does not work any more. Instead of going back to zero after acquiring the record, it just keeps counting up and up until I get an error. The error says that I am trying to acquire a record that has been overwritten. Is this a bug, or is there a workaround? I cannot use integer data type for my application because I am generating my compare data in digital waveform data type.

0 Kudos
Message 1 of 10
(6,489 Views)

Hello J_osh_o

 

I wouldn’t immediately call this a bug. I would see this more as expected since the Waveform has more overhead than fetching the binary U32 information. With the niHSDIO Fetch Waveform there is a more information  in acquiring this data thus you will see a backlog. When you picked the waveform mode where you able to acquire any data before the error?  Have you taken a look at using a -1 as the samples to read and utilize the niHSDIO Configure Acquisition Size VI?

 

Regards,

 

Izzy O.

Applications Engineer

National Instruments

www.ni.com/support

0 Kudos
Message 2 of 10
(6,455 Views)

I have used both the "number of samples" input on the "fetch" vi as well as the "config acq size" vi, I didn't see any difference. After more investigation I still think it is a bug. It is a bug but it doesn't matter because the delay associated with fetch as wfm is so terrible that streaming is impossible. I was able to verify this by adding a dummy fetch as U32 after the fetch as wfm. The fetch as U32 would take care of the update of the "backlog" property. The fetch as waveform took about a quarter of a second, outrageously long. So I am giving up on using digital waveform format. I am building my own VI to translate between ASCII and U32 format. The U32 format seems to work ok on my PC up to about 15Mbps. This is still pretty slow, probably due to the fact I am using MXI and not an embedded controller.

0 Kudos
Message 3 of 10
(6,452 Views)

Hi j_osh_o,

 

The reason you are seeing reduced streaming rates with the Waveform Data Type (WDT) vs binary data type is based on how we implement the handling behind the scenes.  WDT is a multi-state type which includes not just 1's and 0's but Z, as well as the compare states L, H, and X.  However, you cannot store all six states in a normal binary format, so the amount of data needed to store that many states increases, thus increasing the data passed as well as the amount of processing done on the data once the fetch retrieves it.  It is going to be a slow process, and therefore most types of hardware compare applications cannot be achieved at maximum rates.

 

If you are looking to do some type of data comparison, it can still be done in software post processed. That way, you can still stream binary two state data from your board very quickly, and once you have all the data you can have software compare the expected response vs actual in the host processor.  This is not as fast as hardware compare, but it still allows you to compare data if you do not care about having it on the fly.

 

The bandwidth in your system will be determined by the pipeline you have set up between your HSDIO board and your host processor. MXI links typically run at 100MB/s, the 6544 can acquire at 660MB/s and generate at 400MB/s.  PXIe on the 6544 can sustain 800MB/s rates (actual rates are slower due to software overhead that has to be done).  So when calculating your maximum bandwidth, you look at the tightest bottleneck, and that defines your maximum rate.  Given what you have said, I would expect 100MB/s as a max.

 

If you are transferring U32 data, that is 4 bytes of data per sample acquired.  You would be able to stream 25MS/s (megaSamples per second) since each sample is 4 bytes, 100/4 is the stream rate.  If you are getting below that, you can try tweaking the streaming binary example block size to maximize the efficiency of the data pulled from the board and increase the rate.  There is usually a streaming "sweet spot" where you pull large enough chunks to keep up with streaming but not too large that onboard memory overflows.

 

More streaming examples for HSDIO can be found at ni.com/streaming and clicking on the HSDIO hyperlink.

Kyle A.
National Instruments
Senior Applications Engineer
Message 4 of 10
(6,432 Views)

Hello J_osh_o,

 

Like I mentioned previously it is expected that fetching waveform should be slower than fetching binary data, since the driver has to do some work during the fetch process in order to present binary data as waveform data. As for the MXI connection could you tell me what MXI connection you are using? I would assume it is PCIe-PXIe MXI connection since the 6544 is of the PXIe form factor. With that assumption (yes MXI is slower than Embedded Controllers) I would expect a MB/s limit not the Mb/s limit you mentioned. How many channels and how much data are you attempting to stream across your MXI connection? Are you pulling of an adequate amount of samples from the FIFO, is your acquisition loop running quickly enough?

 

Regards,

 

Izzy O.

Applications Engineer

National Instruments

www.ni.com/support

0 Kudos
Message 5 of 10
(6,422 Views)

I can load 64M samples as my buffer. I am using buffer/10 samples as my streaming write. I am using U32 format. I have removed all the display indicators from the gen-acquire loop and added a separate consumer loop for comparing the data to expect. It seems like I am limited to ~20Mbps. 20Mb x 32 channels / 8bits/byte  = 80MB/s which is close to the 100MB/s of the MXI connection. I will play with the write block size, maybe I can get closer to 100MB/s.

0 Kudos
Message 6 of 10
(6,418 Views)

Hi j_osh_o,

 

Verifying the model of the MXI device will be important to determining the maximum bandwidth, are you using MXI or MXIe? MXIe will have higher bandwidths, as mentioned before.  For 25 MHz on all 32 channels, I would guess the chunk size you'd want to use will be around 2.5MS (1/10th buffer size) or down as far as 1MS.  The reason is to limit the amount of times software initiates the fetch call (slow process) so that the actual fetching of data is performed most of the time (very fast process).

Kyle A.
National Instruments
Senior Applications Engineer
0 Kudos
Message 7 of 10
(6,410 Views)

The interface between the laptop and the PXI chassis is: NI PXIe-ExpressCard8360, ExpressCard MXI for PXI

0 Kudos
Message 8 of 10
(6,399 Views)

For that particular MXI interface, based off the product page here, you have 110MB/s bandwidth.  This should be your limit.  Rates will also be affected by your laptop processing power, but its usually dependant on how much SW processing you are doing in your program and how you architect the program (producer/consumer architecture vs in loop processing, former is very efficient and the latter is inefficient).

 

I'm also curious as to how you are interfacing with a PXIe card using a PXI controller, what chassis are you using?

Kyle A.
National Instruments
Senior Applications Engineer
0 Kudos
Message 9 of 10
(6,394 Views)

Maybe I'm confused, but if you are using PXIe-ExpressCard, your bandwidth is 214MB/s, per the product page.

Kyle A.
National Instruments
Senior Applications Engineer
0 Kudos
Message 10 of 10
(6,389 Views)