Workaround for 5132 acquisition limitations?

[mlang]

I was asked to spec out a high speed DAQ system for a laser scanner that detects sample height. The system scans at 10MHz (line to line rate = 500Hz). Figuring 4 samples/pixel, I figured something over 40MS/s would suffice. Max scanning time is <5sec. I used a 5114 for a similar application @ higher data rate (but much lower line to line rate), but since I didn't need the high data rate, I gave into the "NI recommends" propaganda/product advisors and settled on the 5132.

There might still be hope, but the more I play w/ the device, the less sure I am that it's going to work. In hindsight, there should have been more information up front as to the limitations of the 5132/5133 have that NONE of the other digitizers have (such as links to: Supported features, PCI-based state diagram: vs. USB-based state diagram, USB Acquisition Benchmarks) ...of course I found these issues quickly once I started digging into my initial difficulties w/ the 5132.

As I calculate it, I can get ~700 lines before maxing out the onboard memory (32MB version) and then I'm stuck. I end up missing many lines by the time the device is ready for another acquisition. If I setup an acquisition to capture one line at a time, fetching and then try to re-arm before the next, there's a ~25ms lag between the end of fetching and initiation of another acquisition and I end up getting 1 out of every 30 or so lines. I suppose I'm starting to bump up against the limitation of not being able to simultaneously fetch while acquiring (another fact that didn't pop up during initial product search).

My one hope is if I can slow down the system to a scan rate of 1MHz, then I can acquire/fetch/acquire/fetch at 4MS/s. My question/issue for this possibility is this: I can set the device to free-run w/ a software trigger that never happens and just grab pre-trigger samples from the board indefinitely. This would require software start/stop and since my application doesn't really know when the scanning takes place, it could save a lot of zeros to disk by the time scanning actually happens. The samples are also "floating in space" w/o reference to a trigger 'absoluteInitialX' time. If I use a trigger I fix those issues, but (I assume) I still have the 20-30ms where I'm reading out the data and reinitializing the acquisition. If that's my only option, I don't think even 1/10 operating speed would get me 20-30ms between lines to reset the device.

Does anyone see any trickery you can do w/ the 5132 that I'm missing?

If by getting the 5132 I did just do a face-plant against the concrete sidewalk of incompatible hardware, what are my other options?

Since I already sent out the fixed-price invoice, any hardware changes are out-of-pocket for me. I could grit my teeth, shell out $500 more + restocking for the 5132 and go for the PCI-5102 (btw NI, what's w/ the ice-age PCI architecture still for your digitizers?) ...if I was sure it would 100% work for my application. So, in case it helps, here's a more detailed description of my application:

Channel 0 = Start of Line signal. Used to trigger data acquisition, TTL, period = ~2ms

Channel 1 = Data. Starts ~0.5ms after start of line. 0-200mV analog, frequency = 10MHz. 8-bit digitization is fine. Pattern to scan can be up to 12k x 12k pixels. Border regions on top and bottom that generate triggers but no data make the max # of lines somewhere around 20k.

So, since the 5102 doesn't appear on the Supported Features matrix, can I assume that the 5102 supports multiple records? If I tailor the trigger delay such that I only need 48k samples/line, can I make a record for every line (up to 20k) if I'm removing the data from the buffer at the same time? The memory is fairly limited on the 5102, but you should be able stream 20MB/s from the buffer to disk fairly easily. How does the ability to transfer samples directly to host memory affect things? I think I could live w/ 20MS/s if I had the absoluteInitialX from the trigger for each line. I don't need the sample rate of the 5112 and the extra $1900 would really break the budget. Spec-wise, the 5132 is perfect if not for missing the multiple record/continuous acquisition features. (which are quite big features for my application)

[Efrain_G]

Dear mlang,

I am really sorry that we did not make you aware about the capablities of the USB 5132/5133. At this point I would like to offer you a number where you can contact a local sales representative so that we can see what we can do for you. This number is 1 866 ASK MYNI. 

As far as your application, you are unfortunately right, the 5132 does not allow to fetch while acquiring. Therefore, we will be limited to the onboard memory size and the speed of data transfer from your board to the PC memory.

[Stephenah]

As of Scope 3.6 the 5133 and 5132 can fetch while acquiring.  The fetch performance will still be similar to the benchmarks found on  USB Acquisition Benchmarks. 

Scope 3.6 will also allow the 5133 and 5132 to use all onboard memory to acquire one channel if only one channel is enabled.  It sounds like you have the 32MB/ ch version, so in this case you could configure only one channel and acquire almost 64M samples before running out of memory.

[mlang]

I updated NI-SCOPE to 3.6 and tried the attached "niScope test v2.0.vi" and indeed, could fetch up to ~8MS/s before I could see the buffer start to overflow based on the # of samples fetched, which seems to agree with Stephenah's assertion.

I do have one question about arm vs/ reference triggers based on my test VI..."v2.0" works fine since I call out a software reference trigger (but never generate one) and just consistently read out pre-trigger samples. But the absoluteInitialX time base always stays relative to the program start and I was wondering if it's possible to continuously fetch pretrigger samples, but have the time base relative to an actual pre-trigger. So I put together "v2.1" (attached) where I still call out a software reference trigger, but specify the ARM trigger as PFI1 (the external trig input to the 5132)...but it doesn't work. I must not quite be getting the function of the 'Start Trigger Source' specified via the property node vs. the reference source which is setup via the "configure trigger" VI. I was under the assumption that the 'acq. arm' source served as the time base for pretrigger samples and the reference trigger served as the "pretrigger stop" command, upon which the device acquires the record length and finishes the acquisition.

Am I missing something?

Unfortunately, it looks like I was right and even w/ the continuous acquisition feature, 8Ms/s is still probably too low, especially w/o any pretrigger sync timing information. So I'll probably in the meantime try to connect w/ the local sales rep and see what I should do. Anything I should mention other than my current sob story?

[Stephenah]

It looks like you have correctly configured the PFI line for a digital start trigger. You need to make sure that the start trigger you send into the PFI line reaches 3.3V for at least 20 ns.  Is it possible that the digital signal you are using to trigger on isn't conforming to those specifications?  Once you get the start trigger working then the acquisition will start when the start trigger is received and since there isn't a reference trigger the absoluteInitalX time will be relative to the start trigger.

The USB data transfer rate depends on the system and the fetch method, but even in a great system with optimized code the fetch speed of the 5133 and 5132 will top out at around 16 - 20 MB/s.

Stephen

[mlang]

Right now I've got an Arduino making me test signals so the trigger is TTL, though I can switch the entire device over to 3.3V logic. Either way, it still sits there. If I specify a timeout of 0 and # of samples to fetch as -1, I get either a "maximum time exceeded" error if I fetch relative to pretrigger or a "requested data has been overwritten in memory" if I fetch relative to the read pointer. Even if I make the timeout non-zero, it still times out.

[Efrain_G]

Dear mlang,

You probably do not want to set your number of samples to fetch as -1. Have you tried a different number of samples. Feel free to post the code that you are using now so that we can take a look at it.

Regards,

Efrain Gutierrez

Applications Engineering

National Instruments

[mlang]

The test code 3 posts up is what I've been trying. It doesn't seem to matter the # of samples I fetch, specifying PFI1 as the acq. arm trigger still throws both those errors depending on whether the timeout is zero or not.

[dansch]

Hi mlang,

At first, I tried out your code and the shipping example niScope EX Fetch Forever with the start trigger functionality added, and everything worked fine. However, after some additional testing, I believe we found a bug of sorts. There appears to be an issue when the fetch function is called before a trigger actually occurs and the acquisition begins. Normally, the fetch will wait for a trigger and then fetch samples according to what the user requests, but with the USB-513x, there is an issue with trying to fetch when the acquisition has not yet started. If you query the "Points Done" property after calling the initiate function, you will notice that it incorrectly reports a value of 1.84467E+19, and so once the fetch function is called, it immediately throws an error that the requested data has been overwritten in memory. Therefore, I have attached a workaround that queries the Points Done attribute and does not allow the fetch to be called unless the Points Done value is valid. I implemented this within the fetch loop, but you could also have it in a separate loop prior to the fetch loop such that you do not enter the fetch loop until the Points Done value is valid, indicating the trigger has been received. Hope this helps!

[mlang]

Hi Daniel,

Thanks for the tip, that does get me past the error. However, now that I can continuously acquire using PFI1 as my trigger, the absoluteInitialX still just keeps counting up, and not resetting each time PFI1 pulses.

In any event, I wasn't able to go much faster than 8MS/s before the buffer starts filling up past my system's ability to transfer data. It's a new system, so it theoretically should be able to reach that 20MB/s transfer (some fast USB flash drives I have can achieve that rate and higher) but it sounds like I need to call the local sales rep and see if the 5102 could work w/ it's limited memory.

Perhaps there's a demo around nearby I could get a hold of and test out to see if I can stream it off or try out the transfer data directly to system memory thing.