DAQ data synchronization with file read

[dib1205]

---

@Bob_Schor wrote:

I think I see the problem -- you are reading one A/D value at a time and are trying to update a Waveform Graph in real time with every point.

What is your Sampling Rate?  If it is something like 1KHz, then your eye can't "see" changes that fast.  If you sampled at, say, 1KHz, and took 20 samples at a time, you'd get 20 points every 20 msec, could average (or select a point) and display 50 times a second (which is plenty fast for most things).  You definitely want the Display code out of the Producer loop -- it should only have the A/D stuff in it.  Everything else (including reading/plotting the data from file) should be in the Consumer.

Bob Schor

---

I think what you are saying is making sense. I would try that. As I am new in LabVIEW it would take some good effort. 20 points every 20 msec, could average (or select a point) and display 50 times a second (which is plenty fast for most things). Here what do you mean by select point? Would it be able to read one point at a time? instead of averages?

[dib1205]

---

@Bob_Schor wrote:

I think I see the problem -- you are reading one A/D value at a time and are trying to update a Waveform Graph in real time with every point.

What is your Sampling Rate?  If it is something like 1KHz, then your eye can't "see" changes that fast.  If you sampled at, say, 1KHz, and took 20 samples at a time, you'd get 20 points every 20 msec, could average (or select a point) and display 50 times a second (which is plenty fast for most things).  You definitely want the Display code out of the Producer loop -- it should only have the A/D stuff in it.  Everything else (including reading/plotting the data from file) should be in the Consumer.

Bob Schor

---

I have implemented my code into producer-consumer data VI. But the result is something like the plot I have attached. In the plot the two signals are off by phase but the phase difference is not constant.

[majoris · Accepted solution]

They are actually not off by phase per se; they are off by frequency. Hard to know why without code. If the current code is anything like your old code, it could be because you are using a software timing (the wait) and not hardware timing.

[dib1205]

---

@majoris wrote:

They are actually not off by phase per se; they are off by frequency. Hard to know why without code. If the current code is anything like your old code, it could be because you are using a software timing (the wait) and not hardware timing.

---

Yay!!! It worked. Thank you so much for finding out the problem. Now it is working super fine.