Misunderstanding NIDAQmx Timebase Revisited

[CreviceDweller]

I'm using a USB-6251 with the analog sampling driven by an encoder.  In some cases the user wants to divide the encoder to achieve a lower sampling rate.  I used code similar to that described in the previous posts on "Misunderstanding NIDAQmx Timebase".  This solution worked for relatively low sample rates but fails when the sample rate exceeds about 120000. 

In this code, if the divider is 1, the code works up to as high a sample rate as i can reach, approximately 500000.  If the divider is two, and the sample rate is less than 120000 when the code is started, then it works until the encoeder speed is increased so that the sample rate exceeds 120000 where the sampling simply stops. 

If the encoder speed is above 120000 when the code is started, the actual divider appears to be increased until the sample rate is less than 120000.  No errors are returned from any of the function calls. 

I have tried several variations of this code and several variations of the daq_card.max_scan_rate value(s) without any difference in the performace.  normally the daq_card.max_scan_rate value is 1250000 for the USB-6251.  I have tried several different values in the two locations where the value appears in the DAQmxCfgSampClkTiming() function. 

Data is read from the USB-6251 to a PC 12 times per second.  I have tried setting the buffer size just above the minimum for the sample rate and read time and also well above that size with no change in performance. 

My code (edited to remove error checking):

                    sprintf (chanString, "/");
                    strcat (chanString, devName);
                    strcat (chanString, "/PFI0");

                    if (daqencdiv == 1) // No division (Division by 1)
                    {
                        // connect the sample clock directly to PFI0
                            status = DAQmxCfgSampClkTiming (acqTask1, chanString, daq_card.max_scan_rate, DAQmx_Val_Rising, DAQmx_Val_ContSamps, daq_card.max_scan_rate);
                
                    }
                    else // If the encoder is to be divided 
                    {
                        // Suggestion from Discussion Forum 3/18/08
                            // choose "Onboard clock"
                            status = DAQmxCfgSampClkTiming (acqTask1, NULL, daq_card.max_scan_rate, DAQmx_Val_Rising, DAQmx_Val_ContSamps, daq_card.max_scan_rate);

                        // Select PFI0 as "Onboard clock" source
                        status = DAQmxSetSampClkTimebaseSrc( acqTask1, chanString);
                        // Set Onboard Clock divider to daqencdiv
                            // Note that this will not work for daqencdiv = 1.
                        status = DAQmxSetSampClkTimebaseDiv( acqTask1, daqencdiv);

                 }
                // Start Acquisition Task
                status = DAQmxStartTask (acqTask1);

[Brandon_B]

Hello CreviceDweller,

So if I understand correctly it sounds like you are taking an encoder input and using that value as the sample clock for an analog task.  Is this correct?  You also mention that you would like to divide down the rate of the encoder in order to achieve a lower sampling rate for your analog task.  I tried searching for the previous post that you mentioned but was unable to find the forum that you were referencing.  You mentioned that when the divider was 2 and the sample rate was below 120,000 that everything worked fine.  When you say the sample rate, are you referring to the analog sample rate (meaning the encoder is actually at 240,000), or are you referring to the encoder being at 120,000?

This will be a good spot for me to begin troubleshooting.  Also, if you could post the other forum that you were referring to that would be greatly appreciated.

Regards,

[CreviceDweller]

Yes, the encoder is clocking the analog sampling. 

This problem was brought to our attention by a customer that typically runs 7200 RPM with a 4096 pulse encoder and 2 analog channels for a total throughput of (7200 / 60) * 4096 * 2 = 983040 which is close to the limit of the USB-6251.  Dividing the encoder by 2 results in a comfortable of total sample rate of 491520, but the division and performance is inconsistents and usually wrong or even just stops. 

I have tried to find a sample rate (RPM) that consistently fails without much success.  In general, if the total sample rate (analog channels * encoder freq / divider) is over 150k to 200k, results are inconsistent and usually result in the DAQ analog sampling stopping while the counters continue to work OK.  This now seems to apply to all divider values include divide by 1. 

The previous posts were in this forum by reddog.  Search on "Misunderstanding    timebase".  I had to use advanced search on one computer but found it with a normal search on another. 

[CreviceDweller · Accepted solution]

Finally solved this with a lot of help from Sara Lewandroski, (NI Applications Engineer)!

The problem occurs because the DAQmxCfgSampClkTiming() function doesn't always set the convert clock correctly, probably because it doesn't know the maximum frequency of the external sample clock. 

The solution is to explicitly set the convert clock to a rate that will convert the desired number of channels before the next sample clock occurs.

The function to set the convert clock is:

           DAQmxSetAIConvTimebaseDiv(acqTask1, 20);

  where 20 is divider from the 20 MHz clock.  With this divider set at 20, the convert clock rate is 1.0 MHz which is the maximum for the USB-6251 in multichannel scan mode.  With two active channels, this allows the sample clock to be as high as 500 kHz before data is lost.

This function does not have a function panel and does not shoiw up in the DAQmx function list from within CVI.  The only documentation i could find is the DAQmx C Reference Help.  Even there it doesn't appear in the contents but can be found by using the search function.