Bad data with Frenquency counter on DAQ6215

[scavengekid]

I am using c programming in Visual Studio to collect engine data.  I am collecting pressure, temps, and rpm values in an infinite loop.  I read data every 10th of a second and store it in a data file.  Every third or fourth data point that it records has a bogus rpm value but all the other values are ok.  I don't know why it is doing this.  I am new to NI data loggers and need some help.  Here is some of my code:

//create turbo rpm task
    DAQmxErrChk    (DAQmxCreateTask("",&turboHandle));
    DAQmxErrChk    (DAQmxCreateCIFreqChan(turboHandle,"Dev1/ctr0","",2,3000,DAQmx_Val_Hz,DAQmx_Val_Rising,DAQmx_Val_LowFreq1Ctr,.01,5,NULL));

    //create engine rpm task
    DAQmxErrChk    (DAQmxCreateTask("",&engineHandle));
    DAQmxErrChk    (DAQmxCreateCIFreqChan(engineHandle,"Dev1/ctr1","",2,200,DAQmx_Val_Hz,DAQmx_Val_Rising,DAQmx_Val_LowFreq1Ctr,.01,5,NULL));

/*********************************************/
    // DAQmx Start Code
    /*********************************************/
    DAQmxErrChk (DAQmxStartTask(taskHandle));
    DAQmxErrChk (DAQmxStartTask(turboHandle));
    DAQmxErrChk (DAQmxStartTask(engineHandle));

    printf("Acquiring samples continuously. Press Ctrl+Break to interrupt\n");
    printf("Samples saved in EngineData.txt\n");
    file_setup();//places time, date and header at the start of the session
    LoadConfig();//loads data into structure
    while(errorc==0){//infinite loop as long as there is no errors
        endwait = clock () + .1 * CLOCKS_PER_SEC ;//takes a clock reading and adds 1/10 second to it
        gate=0;//this variable allows data to be logged once every tenth of a second
        k=0;
        while (clock() < endwait) {
            if (gate==0){
                FILE*fp;
                fp=fopen("EngineData.txt","a+");
                fprintf(fp,"%lf\t",v1);
                fprintf(fp,"%lf\t",v2);
                fprintf(fp,"%lf\t",v3);
                fprintf(fp,"%lf\t",v4);
                fprintf(fp,"%lf\t",v5);
                fprintf(fp,"%lf\t",v6);
                DAQmxErrChk (DAQmxReadCounterScalarF64(turboHandle,DAQmx_Val_WaitInfinitely,&turbo,0));
                DAQmxErrChk (DAQmxReadCounterScalarF64(engineHandle,DAQmx_Val_WaitInfinitely,&engine,0));
                turbo*=60;//converts from hz to rpm
                engine*=60;
                fprintf(fp,"%lf\t",turbo);
                //converts data from hz to rpm and multiplys by adjustment factor
                engine=engine/engineRpmAdjust;
                fprintf(fp,"%lf\t",engine);
                fprintf(fp,"%lf\t",temp1);
                fprintf(fp,"%lf\n",temp2);
                fclose(fp);
                gate++;//when gate is high or one, data has been logged and wil not be logged again for another tenth of a second
            }
        }

thanks in advance

Brandon

[tnek]

Hi Brandon,

From a glance at your portion of code, one thing you may want to change is the divisor setting. Here is the info for that terminal from the LabVIEW help file.

divisor is the value by which to divide the input signal when measurement method is Large Range with 2 Counters. Leave this input unwired if measurement method is not Large Range with 2 Counters. The larger the divisor, the more accurate the measurement. However, too large a value could cause the count register to roll over, which results in an incorrect measurement.

I was wondering if you could provide some additional info. Which rpm value is going bad; the turbo or the engine? Also how much is the error when the wrong value occurs? Another important piece of information is what version of DAQmx you have. One good thing to try would be to hook up either the engine or the turbo to both counters at the same time. Your program should be able to register the same values for both counters.

Regards,
Kent
Applications Engineer

[scavengekid]

Thanks for the suggestions Kent

To answer your questions, both rpm values are going bad.  An example of the problem is I can be getting a reading that is bouncing around 7990 and 8000 and then there is a reading of 3000.  The version of DAQmx that I am using is version 8.5. 

I have a question on the divisor value.  Since I am not using the large range and I wired it according to the table given in the help files, what is meant by leaving the input unwired.  It states that this divisor is for the large range, does that mean it is ignored or is there something special that I need to put in this divisor setting when using the low frequency setting?

Thanks again

Brandon

[tnek]

Hey Brandon,

Sorry about the confusion about the divisor. I would change the value to 4 since that is the default value although it should not really affect your measurement. One thing to try is setting the starting edge of your counter task to falling instead of rising. Let me know if that works for you.

Regards,
Kent
Applications Engineer

[scavengekid]

Kent,

Thanks again.  With some help, I have discovered my problem I think.  Unfortunately I do not have the data logger with me so there is a large delay in seeing if my new code will work.  What I have been shown is that I need to call a timing function.  Since I am continuously collecting data, I need to set the task to be continuous.  Using the DAQmxCfgImplicitTiming function for both rpm and engine task handles should solve the issue.  I will let you know when I find out the results.

Since I am using the low frequency counter, the divisor number is supposedly ignored.  That is what I was told when speaking with an NI engineer.

Thanks again for the response and help

Brandon

[tnek]

Hi Brandon,

Sounds good, one last thing. Since the USB-6215 is an isolated device, make sure that the counter is grounded so it has a point of reference. See the 621x User Manual located here for more info. This can simply be done by connecting the ground of the source to a D Gnd terminal as long as it is within the safe working voltage limits found in the specifications.

Regards,
Kent
Applications Engineer

[scavengekid]

I have discovered that the implicit timing function made things worse.  Through trial and error and speaking with NI, I cut the implicit timing function and increased the frequency.  I had it set at the freqency range that we would be operating at.  I opened this up to the full range of  10Mhz and my problems went away.  I do not understand why but it worked.

Brandon