Synchronization 35 Hz and 2 kHz with Producer/Concumer method

[christianhm]

Greetings

I am still new to LabVIEW, but I have gotten a basic understanding of it.

I am working on a project where I have 3 signal, each of these is being sampled with 35 Hz, 35 Hz and a 2 kHz.

The 2 kHz signal is from a NI6024 and the samples to read have been set to 256. The two 35 Hz have no timestamp on them, so I have used a Build waveform and used the timestamp from the NI6024 to give them a timestamp.

I am supposed to analyses, display them on graph and log the data to a file. For this reason, I have used the Producer/Consumer approach inspired by the following https://decibel.ni.com/content/docs/DOC-26558.  Where I have 1 producer loop, where the three of my data acquisitions unit is placed. Then three consumer loops, one for analyses another for display the data and the third is data logging in TDMS-format.

The three signals have to be synchronized and this is where I am stuck.

The queue that the producer/consumer method use, works after the principle FIFO and so I thought the data would be synchronized. But this doesn’t seems to be true, when I look at the graph, their seems to be a 10 sec. delay between the fast and the slow sampling rate. But in the TDMS file, it seems synchronized at least when I look at the timestamp.

Is there anyone who might help me?

Regards Christian

[Blokk]

It would be easier to give advice if you show us your code.

So you have all the 3 DAQmx acquisition in one while loop? I wonder how you do it, since they run at a different rate. A Queue does not sync just by its own, a Queue is just a Queue, you feed the data into it (even at multiple places) and you can dequeue the data. I think you have a kind of race condition due to the wrong framework usage...

I feel the following structure would be easier to handle:

• 3 separate loops for the DAQ tasks + you create a typedefinied cluster consists of a double (or array if you acquire N samples) which is your data, a time stamp, and an enum type which has three elements: DAQ1, DAQ2, DAQ3
• When you produce the data at the 3 loops, you Enqueu the data using the above cluster type, giving the aprropriate enum flag (DAQ1-2-3)
• At your single consumer loop you can exactly identify where the data was coming from: DAQ1, 2 or 3 producer loop?
• From this point it is up to you how you handle the plotting (single XY Graph, or multiplot...)
• Saving the data to TDMS is also very easy: you create 3 channels for your TDMS file for the 3 DAQ loops, and your enum type in the data cluster will tell you which channel to use (use a CASE structure, etc...)

edit: I just had a look at the link you mentioned with the example, and it does pretty much the same what I describe above. I did not look into the DAQ producer part however. Anyway, the above procedure should work...How you handle you data which is produced at different rates, it is really up to you! Depends on how you define data "to be synchronised"... Since they have different rates, they will not have equidistant points in time...there are different things you can do, for example you just plot them on a XY graph together...

[Bob_Schor]

You describe the device generating the 2KHz sample (I presume you use its on-board clock), but not the device generating the 35Hz sample -- does it also have an on-board clock so that you only have to start the two devices "in synch" and they (should) remain in synch because their clocks are accurate (or, even better, the same)?

I suppose you realize that 35 does not divide evenly into 2000.  If you start them together, 35 and 2000 (respectively) samples later they'll be together again.  Is that OK?

When you are dealing with devices having different rates of acquisition, and you want to save the data, you have a choice -- either save everything at the higher data rate (which means you'll "save" roughly 6 copies of the 35Hz signal at 2KHz) or have separate data streams, one at 35 Hz, one at 2KHz.  "You Pays Your Money, and You Makes Your Choice".

Please provide additional information so we can be more helpful.  As noted, posting code is an excellent way to do this.  You need to provide code in a form that we can open it in LabVIEW -- this means a VI or ZIP attachment, or a Snippet attachment or Image (Snippets creation is an option on the Edit window of the Block Diagram).

Bob Schor

[johnsold]

Since 2000 Hz is not an integer multiple of 35 Hz, you need to be clear about what you mean by synchronization. Even if all the acquisitions start at the same time the different timebases will eventually drift apart. 

Do you mean a common trigger for all channels? 

Lynn

[christianhm]

Sorry for the late response!

There is no documentation for the device generating the 35 Hz sample, the only thing I know, is that it is sampling with 35 Hz.  For the NI6024E I use the on-board clock.
What I know now, if I run the program, the program will sample with the speed of the DAQ. So now that I have put the sampling sampling rate up to 4500 and the samples to read to 128, witch yields 35,  that might work.
I can’t test my measurement, because of the weather, so I can’t tell if this synchronized the data.

I have another question, sorry for that. If I set the sampling rate to 4500 and samples to read to 128, that gives me a cycle of 35 Hz. Now I get the correct number of samples from the device generating the 35 Hz. But should the NI6024E not give me 128 every 28 ms (1/35 = 28 ms) at the moment I get the same number of samples as my 35 Hz – device, namely 35 sample pr. Sec.

Sorry for the extra question!

The code attached should show what I have been doing.

Thanks in advance

regards Christian

[Bob_Schor · Accepted solution]

Thank you for posting code, which gives a better idea of what you are trying to do.

I see that you are bundling samples from three devices (DAU 4011, DAU 4021, and NI 6024E) together in a single cluster in your Producer.  I don't know what the DAU devices are, but I'm going to assume that they can accurately output data at 35 Hz.

You already know that 35 Hz and 2KHz are not even multiples of each other, but since you are bundling samples, you can consider doing something like the following:

1. Set your Acquisition loop to acquire, in parallel, 2000 samples from the 6024E, 35 samples from the DAU 4011, and 35 samples from the DAU 4021.  This should take precisely 1 second for each device.
2. Bundle these three arrays or waveforms (use whatever format is more convenient) into your cluster and send to the Consumer loop.
3. You should not need to include a separate Timestamp in the cluster since all of the sampling is synchronous (assuming that the three instruments have accurate timing, with each acquisition taking precisely 1 second).
4. I see no need to use an external Time server (except, perhaps, to reset your PC's clock before you run your LabVIEW code).  You should be able to use the PC's clock to get the Starting Time for the acquisition, and should rely on the hardware clocks in your acquisition devices (which are timing your acquisition and had better be accurate!) once sampling starts.

Bob Schor

[christianhm]

Thanks for the advice; I will look into it tomorrow. It sounds like something that will work for me 

Regards Christian

[christianhm]

Okay, it's working now! 

Thanks for the help!

I just have one last question. What is the deal with the sampling rate being even with a number?
I know that 35 Hz and 2KHz are not even multiples of each other, but what if I had a sampling rate that was even. For example a sampling rate at 4500 Hz and 35 Hz. That would give 128, would that be even and why?

regards Christian

[johnsold]

With sampling rates which are integer multiples you can derive both sample clocks from the same timing source. This will assure that they remain synchronized. With your external devices that may not be a possibility if they do not allow an external clock or do not export their internal timing source signals.

Lynn

[Bob_Schor]

---

@christianhm wrote:

For example a sampling rate at 4500 Hz and 35 Hz. That would give 128, would that be even and why?

regards Christian

---

Dear Christian,

     I don't even have to do any division to see that 4500 and 35 aren't multiples of each other, hence 35 won't divide evenly into 4500.  The easy way to see this is to see that 35 is divisible by 7, but 4500 is not (it can easily be factored into 5 * 9 * 100, none of which can be divided by 7).

BS