NI PCI-5152 Trigger Rearm Speed (Start Trigger and Reference Trigger)

[KaiKeem]

Hello,

First off, please have a look at the timing diagram

I am using two NI cards. PCIe-6353 and PCI-5152.

PCIe-6353 generates both of the digital trigger signals (start and reference) and sends them through the RTSI cable (RTSI0, 1) to PCI-5152 high speed digitizer. 

I wrote a simple working VI based on one of the example VIs coming with LabView (niScope EX Configured Acquisition) for testing.

It works, however I found a few problems.

1. One iteration takes too long time. Since the frequency of the reference trigger is 17 KHz I hoped to see at least 15000 per second in the number of iterations indicator on the front panel but I got much much less than that like 40 per second.

2. I figured that 'Is task done" VI slowed down the loop to a great extent so I removed it from the loop and put it in another seperate loop. Then, the program somehow gave me an error. Under some conditions it did not give any errors. But, even when it worked, the iteration speed was much slower than I expected (around 200 iterations per second)

3. When I take that 'Initiate Acquisition' VI out of the loop, the digitizer does not seem to get triggered more than once. It gets triggered once. I assume that 'Initiate Acquisition' VI has to be in the loop with Fetch VI. When both of the VI are in the same loop it works but again it is very very slow. I suppose rearming the digitizer takes a long time. 

This is what I want to achieve. PCI-5152 High Speed Digitizer fetches a certain number of samples (around 5000 ~ 25000) for a certain sampling duration (around 50 us) punctually by getting triggered every 60 us (or 65 us, but definitely longer than the sampling duration). However, I do not seem to achieve the speed I aim for. The start trigger is not crucial. It can be omitted.

Could anyone help please? The key is the speed!!

[TimmTheEnchanter]

Hi KaiKeem,

1. Since the frequency of the reference trigger is 17 KHz I hoped to see at least 15000 per second in the number of iterations indicator on the front panel but I got much much less than that like 40 per second.

This loop is iterating once for every time all the functions finish within that loop (e.g. the Initiate function and the Fetch function are called, some property nodes are read, the waveforms are plotted, etc.)  This has nothing to do with the time for which each record is acquired.  Records are acquired in hardware time (deterministically, and independent of NI-SCOPE function calls.)  However, your Fetch function calls execute in software time (much more slowly and less deterministically, whenever your host PC gets around to finishing all the processing and starting the next iteration.)

These hardware time and software time concepts are not really related, so it doesn't surprise me you're seeing much fewer iterations than you expect.  Currently you only have a single-record acquisition set up in your code.  Your hardware acquisition is stopping and waiting for your code to re-initiate the same single-record acquisition.  I would recommend you look at the multi record example, not the configured acquisition example. 

Finally, if you use the right example (multi record) you won't be able to use the For Loop Iteration Count to tell you how many records are acquired.  Instead, you can use the "Records Done" property node/attribute under Fetch>>Records Done.  You should see this increase at roughly the rate you expect at 17kHz. 

Keep in mind you are subject to rearm time (specified on p.12) on this digitizer.  With the Trigger Holdoff set to 0 (default) your maximum trigger rate is 1/(rearm time [s] + record length [s]).  If you exceed that rate, you'll miss triggers.

2. I figured that 'Is task done" VI slowed down the loop to a great extent so I removed it from the loop and put it in another seperate loop. Then, the program somehow gave me an error. 

Why are you putting this in your loop?  This VI polls (in software time) if the DAQmx Task is finished, not if the NI-SCOPE task is finished.  I'm not sure what you're hoping to accomplish here.  Either way, it is expected to slow down your loop somewhat, because it is using software to poll another instrument (DAQ, not a digitizer) to find out if its task is complete.  

Any software communication you make with several instruments in the same loop will slow down the overall loop execution speed.  If you are seeing some error with this, I'd recommend you get it down to a reproducible subset of your code, take careful note of the error, and search for it on ni.com.  If you can't figure it out, then feel free to post in the DAQ forums and ask about the error.

3. When I take that 'Initiate Acquisition' VI out of the loop, the digitizer does not seem to get triggered more than once. It gets triggered once. 

Again, this is because you currently have only configured a single record acquisition.  Look at the multi record shipping example and compare.  You need to specify the number of records in the configure horizontal parameters VI (it defaults to "1") and then you need to set up your Fetch function accordingly to get the right records in the right order and so forth.  There are several other streaming multi record examples if you search around ni.com.

This is what I want to achieve. PCI-5152 High Speed Digitizer fetches a certain number of samples (around 5000 ~ 25000) for a certain sampling duration (around 50 us) punctually by getting triggered every 60 us

This seems reasonable, so long as you've run the math and you aren't trying to trigger more quickly than your rearm time + your record length.

Also, the maximum amount of data you can store on your digitizer is a combination of the record length and the number of records.  Be sure to check out the "Allocated Onboard Memory Per Record" section of the Specifications (p. 17) to find out what is your maximum limit for the digitizer you own (with whatever memory size it has). 

-Andrew

[KaiKeem]

Thank you for your reply, Andrew.

I followed your advice and got a much better working VI.

However, I have faced other problems.

I set different number of records (500, 1000, 2000, 4000) and lengths of a record (500, 1000, 2000, 4000).

The acquisition duration is 50 us and the trigger period is 63 us therefore, the rearm time (8 us) is well considered.

I put both an 'initiation acquisition' vi and a 'multi fetch binary' vi in a loop so that acquisition takes place every set number of records, for example every 500 records or 4000 records.

What I observe is the data aquisition is still not fast enough I guess mainly due to the re-initiation step for every loop.

The length of a record does not affect the overall processing time since the required sample rate is far below PCI-5152's maximum capacity (1GSamples/second).

However, the number of records does affect the overall acquisition time and a unit time per record. 

8 cycles of 500 records and 1 cycle of 4000 take different times. 1 cycle of 4000 is faster regardless of the length of a single record. 

However, in both cases, they take longer than they should when the number of cycle is large like 300 or 400.

I assume it is due to the 'initiate acquisition' step.

Having read some tutorials and forum posts setting a very large records number and using producer/consumer/queue structure would seem the right way to go.

Here are some issues.

1. I cannot put in too large number like 1 billion. If I do labview gives me an error message saying "Error 1097 occurred at Call Library Function Node in niScope Multi Fetch Binary 8vi: Possible reason(s): LabVIEW: An exception occurred within the external code called by a Call Library Function Node. The exception might have corrupted the LabVIEW memory. Save any work to a new location and restart LabVIEW". 

2. I do not seem to get the producer/consumer/queue structure to work. I get this error message "Error 1 occurred at Dequeue Element, Possible reason(s): LabVIEW: An input parameter is invalid. For example if the input is a path, the path might contain a character not allowed by the OS such as ? or @. NI-488: Command requires GPIB Controller to be Controller-In-Charge"

I attached the buggering vi.

3. I am still not sure how to move the data in the onboard memory to the LabVIEW's memory during a cycle of the while loop. If the set number of records is huge the queue will not receive anything from the 'multi fetch' vi until the vi's job is competely done, will it? I looked into the help file, other tutorials and forum posts but I don't completely comprehend the producer/consumer/queue structure. It would be great if you could help me understand.