How to reduce delay caused by coding?

[HT156]

Hi,

I am fairly new to C++ programming and using DAQ boards. I've been browsing this board for awhile and let me first thank everyone who has contributed - most threads were very helpful.

However this problem I have right now didn't come up in any searches so hopefully someone could help me out.

I am using the NI-6115 PCI DAQ board and I am trying to write a simple C program that continuously counts the number of input pulses to a counter within a time period.  The program also has to continuously output the result onto the screen.

 So basically this is what my code looks like:

while( 1 ) {
        DAQmxErrChk (DAQmxReadCounterScalarU32(taskHandle,10.0,&data,NULL));
        count = data - data1;
        if ((long)count < 0)
            (uInt32)count = data + 16777216 - data1;
        data1 = data;
        printf("\rCount: %d.  Press Ctrl+C to interrupt.            ",count);
        fflush(stdout);
        DAQmxErrChk (DAQmxWaitForNextSampleClock(taskHandleCtr,10.0,0));
    }

 The sample clock uses another counter's output pulse train as the source.

The problem is, the desired execution time of each iteration is around 40 - 50 microseconds.  With the above coding, I could only achieve 800 microseconds per iteration.  If  I set the sample clock any faster, an error will occur telling me that two sample clock pulses have occured before the "DAQmxWaitForNextSampleClock" instruction is reached.

Would it be the computer that I am running the program on?  The speed of the DAQ board?  Or just poor programming technique on my part?

Thanks in advance

Howard

Message Edited by HT156 on 05-14-2009 06:17 PM

[David_Pratt]

Running the software on a beefier PC will typically enhance program performance.  From your description, it's highly unlikely that you're running into hardware limitations with your setup so I would recommend trying the software on a computer with a higher performance processor.  As for your code, you're logic doesn't appear to be causing much delay but remember, without a deterministic operating system, you will have a lot of difficulty achieving such precise timing for your code execution.

[HT156]

Thanks!  That definitely points me in the right direction.

What would you recommend as a good OS to run this software on?

[David_Pratt]

Hey Howard,

Any real-time operating system will work to obtain the determinism you need.  We have an operating system we provide called LabVIEW Real-Time but it will work for only certain computers or hardware so you'll need to do some research on what option will work best for you. I would suggest testing on a better performing machine before going into the search for a real time based computer to run the program on but that is completely up for your descretion.

Have a good weekend!

[HT156]

Thanks for you last reply David.

Since switching to a new OS is not an option for me, I have decided to reconsider my program logic in order to achieve an even faster time. 

I have decided to store the read counter values first then do the calculations later.  Also, I have omitted the part of continuously printing the results onto the screen.  Here's what remains of my code, which is incomplete.

while( 1 ) {
        DAQmxErrChk (DAQmxReadCounterScalarU32(taskHandle,10.0,&data,NULL));
        DAQmxErrChk (DAQmxWaitForNextSampleClock(taskHandleCtr,10.0,0));
    }

However even with those two lines of codes I am only able to get down to 350 microseconds per iteration before WaitForNextSampleClock returns an error.  I was wondering if there is a faster read function to read the counter value than  DAQmxReadCounterScalarU32?  And is there a way to bypass the CPU and store the counter values direct onto the DAQboard?

[David_Pratt · Accepted solution]

Hey HT156,

The function you're calling is only grabbing a single data value from the buffer on the DAQ card.  To achieve the speed you're wanting, you may want to try a different architecture like performing less reads by reading a large sample less often.  This would let the card use it's buffer to store data and then you can retrieve it less often but still get the same data.  This method will require more post-processing but shouldn't dwindle performance is you use a producer/consumer architecture.  Also, this method would eliminate the need for your second function of waitfornextsampleclock.

[HT156]

David,

Your solution is excellent, this pretty much solves my problem!  Thank you very much!

Really shows my lack of knowledge on the workings of the DAQ board haha.

Howard