PCI 6071E finite sample interval scanning

[eLions]

Hi Greg H.,

If we use external update clock, and configure the device to take 64x3 (3 samples per channel) samples, if we send three set of clock pulses---each contains 64 update edges. Will this work as well?

Thanks,

eLions

[Greg-H]

eLions,

To explain the first part, lets suppose you have a program that, in a single loop, displays elapsed time and counts the number of times "Virtual Instrument" is used in a text file.  Most likely this would execute so quickly you would see no jumps in the elapsed time indicator.  Program enters while loop, subtracts previous time from new time, updates indicator, then goes into the text file part, and finally repeats the process.  Now lets replace the text file with the entire internet.  Obviously this is going to a lot longer (several hours in fact).  So now the loop follows the same flow but the amount of time between the indicator updates for elpased time is long it will appear to count by hours.  Clearly this is an extreme case; however, when you start trying to time things at the millisecond level, these small programatic delays add up quickly.  So that is what I meant by actualy time being based on SW speed.  It is a combination of how efficient your code is and how fast your computer is.

To implement you would still use the pause trigger.  You will just need to set up your own timer to track when the trigger is activated.  Using a wait is definitely not the way to go.  I would suggest trying a tick count inside and outside your while loop.  You can take the difference of these two inorder to count elapsed time.

Regards,

Greg H.

[Greg-H]

eLions,

First do you want three smaples on each channel every time or one sample on each channel every time for a total of three samples per channel?  I would use one edge off the clock and have all the channels start with the same edge.  If you set them all up in the same task, there is no reason to have 64 edges coming in.

Regards,

Greg H.

[eLions]

Hi Greg H.,

Thanks for your note. For the purpose of precise timing the software wait may not be good enough for the experiment and we will probably use a external update clock. 

Q: "First do you want three samples on each channel every time or one sample on each channel every time for a total of three samples per channel? "

A: We want one sample on each channel every time. Once we finished acquisition of 64 samples, we may wait for a few ms to read next set of 64 samples (again one sample on each channel). 

"I would use one edge off the clock and have all the channels start with the same edge.  If you set them all up in the same task, there is no reason to have 64 edges coming in. " 

Maybe this is the point where I was confusing. Do you mean if I configure the device to use external update clock, then by sending one clock edge (rising), all channels will start with this edge (without  additional clock edges) ?

I originally thought the device needed multiplexing and one clock edge per channel per sample, please confirm this is incorrect.  If so, is there an internal timer that control multiplexing(from channel 0 to channel 63)? 

Please advise the following pseudocode will do the job: 

DAQmxCfgSampClkTiming(taskHandle,"/Dev2/PFI0",CLK,DAQmx_Val_Rising,DAQmx_Val_FiniteSamps,3);

DAQmxStartTask(taskHandle);

DAQmxReadAnalogF64(taskHandle,3,TimeOut,DAQmx_Val_GroupByScanNumber,InterleavedData,64*3,&NumPerChnRead,NULL);   //using interleaved fillMode

On hardware: 

1st clock edge received, acquire 64 samples (one per channel);

after 3ms, 2nd clock edge received, acquire 64 samples (one per channel);

after another 3ms, 3rd clock edge received, acquire 64 samples (one per channel);

Thanks,

eLions

[Greg-H · Accepted solution]

eLions,

You do not need to worry about timing the multiplexing, the device will do this as quickly as it can.  The only issue you would have with the multiplexing is if you go to quickly that there is residual voltage in ADC that affects your signals.  If this is happening, it will be apparent right away.  You can configure all one sample 64 inputs on the same task.  Then use one single rising edge to trigger the samples to begin.  The only delay you will have between the first sample and the 64th is a result of the multiplexing through the ADC.  If you are using the external clock you will need to configure one of the counters to monitor this.  You will also need to configure a trigger on the analog task so that it knows to start on every rising edge of the sample clock. You will also need to make this retriggerable.

"On hardware: 

1st clock edge received, acquire 64 samples (one per channel);

after 3ms, 2nd clock edge received, acquire 64 samples (one per channel);

after another 3ms, 3rd clock edge received, acquire 64 samples (one per channel);"

What are you going to use for an external clock?  I assume with the delays this is configured on the sample clock end of things.

Regards,

Greg H.

[eLions]

Hi Greg H.,

"The only issue you would have with the multiplexing is if you go to quickly that there is residual voltage in ADC that affects your signals."

-This won't be a problem and if it is a problem, then we will wait slightly longer between each set of 64 samples. 

"What are you going to use for an external clock?  I assume with the delays this is configured on the sample clock end of things."

-We will use a TTL signal generated by our timing computer (output frm on echannel of PCI6534). The delays between each clock edge will be controlled by the timing. 

"You can configure all one sample 64 inputs on the same task.  Then use one single rising edge to trigger the samples to begin.  The only delay you will have between the first sample and the 64th is a result of the multiplexing through the ADC.  If you are using the external clock you will need to configure one of the counters to monitor this.  You will also need to configure a trigger on the analog task so that it knows to start on every rising edge of the sample clock. You will also need to make this retriggerable."

-Could you give a hint what the counter will be used for?  The following code (to my understanding) will start device on every rising edge of the sample clock and retriggerable 3 times. 

DAQmxCfgSampClkTiming(taskHandle,"/Dev2/PFI0",CLK,DAQmx_Val_Rising,DAQmx_Val_FiniteSamps,3);

 Thanks,eLions

[Greg-H]

eLions,

""/Dev2/PFI0""  is exactly what I was talking about, I missed this in your previous post, sorry.  Everything you said looks good.  I think this will work well for your application.

Regards,

Greg H.

[eLions]

Hi Greg H.,

"You do not need to worry about timing the multiplexing, the device will do this as quickly as it can.  The only issue you would have with the multiplexing is if you go to quickly that there is residual voltage in ADC that affects your signals.  ...   The only delay you will have between the first sample and the 64th is a result of the multiplexing through the ADC. "

-Regarding the speed of multiplexing, from the DAQmx function reference "If you use an external source for the Sample Clock, set this value to the maximum expected rate of that clock." So to avoid unnecessarily rapid ADC multiplexing, even with external update clock can we still set clock rate in the following function to slow it down?  

DAQmxCfgSampClkTiming (TaskHandle taskHandle, const char source[], float64 rate, int32 activeEdge, int32 sampleMode, uInt64 sampsPerChanToAcquire); 

Suppose we set the rate to be 100kHz and the device function properly at this rate. Would the delay between 1st and 64th sample resulting from multiplexing through ADC is 64*0.1=0.64ms?  

Thanks,

eLions.

[Greg-H]

eLions,

Yes you can do it this way.  You can also not set it and check to see if you are getting incorrect value becuase of the residual voltage and then adjust accordingly.  The device is not going to slow down the multiplexing based on your external clock.  The device is always going to run at max speed unless you tell it to slow down as you mentioned.

Regards,

Greg H.