Hardware clock

[evangel55]

Hi,

    I would like to use the PXI-6289 hardware clock to timestamp my computed data using Labwindows. Currently, I am using internal clock (clock()) to do this. However, this clock() function is unstable as it depends on the system processor. Therefore, I decided to use an external clock that is independant of the system processing speed. My idea is to create a seperate thread to monitor this "external clock"; maybe by counter. And whenever I would like to get the time-elapsed, i will just call the function monitoring the external clock.

Real time Iteration (using sync wait)

{

    /*compute data.*/

   /*Output data to analog/digitial output. */

   /*Time-stamp the computed data with time-elapsed(real-time) since iteration starts*/

   /*Log to file.*/

   /*loop back*/

}

Please advice! Thanks!!

[stilly32]

Hi,

generally the best way to acquire accurate time data is to acquire with respect to a known event, such as a digital edge or a voltage level. If you just start your acquisition in software and rely on the OS time clock to timestamp your data, then the start time will rely on the OS. This means that the start time will be in doubt but the samples will be known with respect to previous samples (assuming you are doing HW timed acquisitions). If you had an outside signal that had timing information and would give you a reliable signal to measure with respect to, you could trigger off that signal and have an accurate time. This is how most of our acquisitions are done. You trigger your acquisition/ generation and rely on the HW timing of the board itself.    

For example, lets say you want to generate a specific signal for 100ms, once every second. The best way to do this would be to generate a pulse train (externally of internally) that pulses high once a second on the second of a known timing source. You would trigger a counter off of this timing signal to generate a finite pulse train for 100ms, which would be used as a sample clock for your AO/DO. Your timestamp would be known because you control when the trigger is sent. This is a general KB on retriggerable acquisition and it contains good links to LabWindows/CVI code that can be modified for a similar situation.

Hope this helps, please post back if I didn't answer your question.

Cheers,

Andrew S

National Instruments

[evangel55]

Hi,

    I followed your suggestion and create a pulse-train generation function. At the same time, I also created a counter function that reads the number of high edges from the pulse-train.  I used a frequency of 1000Hz for pulse generation. After which, I compared the real-time between the one generated by clock() and this HW counter. In general, the difference is not too significant, though the HW counter is slightly better. However, by introducing this HW counter, I am actually increasing the load on the system which makes me wonder if this is worth the effort.

    So I thought of using the pulse-train generation function to generate at a known frequency(which has the same value as my iteration loop) and have a digital channel to read these values. This way, I can accurately compare the time generated by clock() and the digital inputs. Is this advisable? Thanks!!

YB

[stilly32]

If I understand you correctly, you want to generate pulse train at a known rate and read in continuously on a dig line and maybe some AI. You could then correlate the digital signal (which would read the 1 hz counter output) with the AI? This would work, and give you a good indication of where you are in your signal. Really though, if you can start the timed I/O on a trigger at a known point in time, you don't have to worry about the rest because you know when you started, the time between each sample (1/sample rate) and the number of samples from the begining of your acquistion. Based on this index you can calculate the time of any of your samples.

Cheers,

Andrew S