Continuous Acq using PXI 6552

[Ana P]

Hi Michael,

I understand that you want to continuously acquire data from a 6552, the fact that you are using a 20 MHz sample clock shouldn’t be a problem since the specification of this card is 100 MHz maximum clock rate. In order to truly understand what could be going wrong in this case we need to know more information about your system. You say you cannot run this vi at 20 MHz, can you run it at other rates? What behavior that is not expected are you seeing at 20 MHz? How much data are you trying to acquire? Is this a PCI or PXI card, are you using a controller in the PXI chassis? In what slot do you have the 6552? Is this the only module in the chassis? If streaming to disk is a requirement in your application, I would like to point you to this article in developer zone that has examples of continuous acquisition while continuously streaming data. Please, try running the vis in the advanced folder and let us know the results. These examples use the Win32 File IO vis, that are useful for read/write large amounts of data at high data rates. You can find them in this developer zone.

[Michael Collins]

Hi Ana P,

When running at a clock rate of 20MHz I get the following error

Possible reason(s):
Driver Status:  (Hex 0xBFFA4BFB) DAQmx Error -200004 occurred:
Measurements: Data requested has been overwritten in the device memory.

Status Code: -200004

To answer your questions

You say you cannot run this vi at 20 MHz, can you run it at other rates?  Yes I can run at 5Mhz, Anything higher gives the error above 

What behavior that is not expected are you seeing at 20 MHz? Error above

How much data are you trying to acquire? 1M of data in total

Is this a PCI or PXI card, are you using a controller in the PXI chassis? PCI card

In what slot do you have the 6552? PCI Slot

Is this the only module in the chassis? Only NI I/O card in the PC

If streaming to disk is a requirement in your application.  Streaming may not be a requirement.  I am trying to prove that the I/O card is capable of the measurement I require to perform.  Records have their limitation.  See attached description of what I'm attempting to do.

Thank you for your help on this.  I was investigating it a few months ago but got side-tracked so I'm back trying to resolve it now.

Regards,

Michael

[Chris_D]

Hey Michael,

How many channels are you acquring on? I say this because you can adjust your data width, which is ultimately adjusting your sample size. You can see more info below.

HSDIO Data Width and Memory Allocation
http://digital.ni.com/public.nsf/allkb/E5170A54988EF81A8625725A006103BB?OpenDocument

At the best case, with a data width of 1 byte, sampling at 20 MHz means we will be aquiring 20 MB/sec of data. The error that you are receiving indicates that you are running out of memory. Since your onboard memory size is only 8 MB this means we have less than a second to fetch the data off the device to make room for more samples, else we will run out of memory. Since we are receivinig this error, it means we aren't fetching enough fast enough.

We should be able to fetch close to 100 MB/sec depending on your computer (theoretical speed of PCI bus is 132 MB/sec). I would suggest trying to increase the Number of Samples To Fetch Per Cycle. You can play around with this number to get the best results. Increasing this number should allow the VI to run for longer before receiving the error. I cannot guarantee that it will be able to go forever, it just depends on the speed of your system. In summary, we just need to make sure that we are fetching faster that we are aquiring and you should be able to run forever.

[Michael Collins]

Hi Chris,

I intend to acquire on one channel only.  Ok my issue is not going to be that of fetching the data back at any great speed.  If it takes in the order

of seconds to do this that is fine.  So my issue is the speed of acquiring the data and the limitation in the memory size.  So i will be writing

and reading to the part simultaneously.  For every 20 clock cycles I require a read.  If I write and read everything simultaneously I will require

20M of memory to store my readback values.  But I'm limited to 8M of my card.  So ideally I need to trigger a readback on the 20th write

clock pulse.  So fetching the data back is limited by the speed of my computer, that is fine.  I need to do some more investigation.  Do you think

what I'm trying to achieve is possible.  So I want a continous clock to 20MHz to be driven to my part with no interrupts to this clock.  And after

every 20 clocks to acquire data on one channel, until 1M of data is gathered.  Then when complete, read back all the data. 

Regards,

Michael

[Chris_D]

Michael,

I think this is definitely possible. One possible implementation would be to create a waveform of 20 clock cycles and use a script to output a marker event on the 20th sample. This would output a pulse everytime that 20th sample is generated. We can use that pulse to trigger an acquisition thus reading on every 20th clock pulse.

There are some examples in LabVIEW at Help » Find Examples » Hardware Input and Output » NI-HSDIO that can help you get started with this. You can see the Dynamic Generation and Acquisition - Demo.vi and the Dynamic Generation with Marker Event.vi to get your started with the markers.

Let me know if you have any other questions!

[Ryan_M]

Using markers every 20 samples is a good way to generate a repetitive signal.  A couple quick caveats for this implementation.  The clocks need to be free running so you'll need to create some "dead time" in your script.  That is, make sure the marker driven pulse train is being generated before you intended to start using it to acquire data.  Also, marker assertion is deterministic but deassertion is not.  That is, if you tell a marker to assert on sample 20, you'll see the rising (or falling edge) on sample 20, but the falling (or rising respectively) will be some time later depending on some non deterministic characteristics.  for this reason, you'll want to make sure your active edge is the assertion of the marker.  Furthermore, you'll need to pay attention to the duty cycle of the resulting signal.  Page 15 of the specifications calls out a 25% to 75% duty cycle requirement for frequencies < 50MHz.  You may want to use a data line instead of a marker in order to make sure you achieve the required duty cycle.

[Michael Collins]

Hi,

Thank you for your continued help on this subject.  Yes what you suggest is what I was originally trying, unsucessfully mind!  So I can generate my script trigger successfully and view through PFI0, every 20 clock pulses etc.  See attached ammended file.  However I'm still confused as to how to "connect" this trigger out signal back into my acquisition.  I've a pattern match set-up so that I can view the output.   However which configuration of Trigger set-up should I use.  I imagine it's Digital Edge Ref Trigger as opposed to start trigger?  If I select start trigger it will acquire the data back at the clock running rate.  If Digital Edge Ref trigger is the correct setting  what should I set the pretrig samples number to?  Any further help appreciated, or my example ammended may point me in the right direction.

Thanks,

Mike

[Chris_D]

Hey Michael,

You are exporting your marker on PFI0. In order to trigger off of this signal we will have to physically connect it to another PFI line (ex. PFI1) and specify that line as source for the trigger. I would not recommend using pattern matching for this. You can use a Digital Edge Start Trigger and a Digital Edge Reference trigger depending what data you want. With a start trigger, no data will be acquired until the start trigger is received. A reference trigger occurs after the acquisition has started and you can choose how many samples you want to save before and after the trigger or pre-trigger and post-trigger samples.

Additionally, we may not need to route the signal out through a PFI line. We can do this routing internally if needed using the PXI Trig Lines. Just export the marker to one of the PXI Trigger lines and then select that same line as the source for the trigger.

You can still try this out with the markers, but if you are still having troubles we way want to take Ryan's approach above by instead using a data line instead of the marker to output the trigger signal.

[Michael Collins]

Hi Chris,

I have implemented what I think it correct with regard to the Start Trig Edge and the Ref Trigger Edge.  While monitoring PFI0 signal with repect to the generated signals I can observe the the acquisition does take place at the position of the generated marker, for the programmed number of samples.  Alsio Pre-trigger samples is working correctly and can acquire samples before trigger point.  However I am only getting one section of acquired data corresponding to the first trigger marker, I wish to readback 5 in this case, corresponding to my script statement "repeat 5".  I can observe 5 markers at PFI0 at their correct location so my generation is working.  But the aquisition is only working for the first one.  Any thoughts?  Also I also need to program the readback clock to be the same at the generation clock or my program won't run.  Can these not be independent?  Or should I be able to omit the readback clock seeing as I only wish to readback on the marker?

Thanks,

Michael

[Chris_D]

Michael,

Each trigger has a time cost to rearm. This may be why you are missing the marker pulse. Rather than outputting 5 markers and acquiring 1 sample for each marker you can try to output 1 marker pulse and acquire 5 samples. Just remove the repeat statement in the script and change the Number of Samples to Acquire control for the acquisition to 5.

Also, when using the onboard sample clock, your acquisition and generation rates must be the same. If you needed different rates you would have to use an external sample clock.