synchronize measurements on several usb 6008 or 6009

[alysko]

  Dear Sir/Madam,

I have several USB 6008 modules. I would like to trigger the start of voltage measurements for all of the devices in software only (programmically), i.e without using hardware (PF pins).

I do not need a perfect synch. In addition, the sampling parameters on all boards are the same, which should simplify the matter. Is there a way to set them to run at about the same time?  So far I have tried to decompose the NI example (one using Internal Clock) into several parts:

1) I run Create Channel and Timing VIs for each device

2) I run Start task for each device

3) I wait for all measurements to be complete

4) I read the data out

In between, I make sure the processes are synchronized. Nevertheless, the measurements are done in sequence.

A) Why?

B) How to make them in synch?

Thanks!

Regards

Albert

[alysko]

  Here is another (perhaps simpler) example of the problem. Run the file "Test..." attached. It runs two concurent DAQ processes, where one acquires data from a simulated channel and the other from a real physical device. Once the acquisition is completed, compare the start/stop time for the plots. One acquisition only starts once the other is completed. Why do not they run in parallel? The devices are different and should not interfere with one another.

Regards

Albert

[Chris_D]

Hey Albert,

You won't be able to truely synchronize the 6008's because you are not sharing clock signals and start triggers. To get the best results using only software, you need to start the tasks at the same time. The task will start as soon as we call the DAQmx Start Task VI and it sends the signal to the device. To ensure that the Start Tasks are called at the same time you can use a sequence structure. I have attached a picture below.

From your second post, the two tasks do not run in parallel because they both call the same sub VI. The sub VI is non-rentrant so only one instance can run at a time.

Message Edited by Chris_D on 09-22-2008 01:36 PM

[alysko]

Dear Chris,

Thank you for the picture. Unfortunately, neither of your suggestions was correct:

1) If you look at the picture attached to the first message, you will see that I do essentually the same as you have shown in your picture. Morover, from my picture you can also see the timing. The block starting the channels was done very quickly (within few tens milliseconds). However, in the plot, the waveforms from the second device start only after the first acquisition is completed.

2) The sub-VI is actually rentrant. Please feel free to download the copy I had attached to the respective message (file "Acq&Graph Voltage-Int Clk_.vi") and see for yourself.

I would like to make an additional note regarding (1). When the acquisition time is set small (e.g. 100ms), the scale of the figure shows that the 2nd acquisition (from one device) starts a little while BEFORE the end of the 1st acquisition (from the other device). This type of beghaviour further indicates that the problem has to be in the NI's binaries.

Please feel free to ask questions. I will be glad to answer, if it helps to either solve my problem or to assist debugging the NI's code. I would also be very glad to hear more from you or other NI technical support staff member.

Thank you beforehand. 

Best Regards

Albert

Message Edited by alysko on 09-23-2008 07:51 AM

[Chris_D]

Hey Albert,

I apologize! You were right and the sub VI is reentrant. However, they are actually running in parallel, but the data is not correlated because we do not start the tasks at the same time.

I believe I misunderstood your first post and now understand what is going on. Actually, my picture and your VI are quite different in regards to starting the task. In your VI each iteration of the loop it  starts a tasks and gets the current timestamp. Every VI in the loop takes processing time and every VI in the loop must execute before moving onto the next iteration. Using the sequence structure, will allow us to start the tasks closer together since we don't have other processing going on in the structure and we can control the start of the execution will be as close as possible.

The loop iteration additionally applies to the t0 or initial time in the waveform timestamp. The t0 is actually determined by taking the computer system time when the DAQmx Read is first called. Since the read will not return until all the samples have been taken, then loop will not iterate until it is finished and  thus the next read will not occur until the first one is complete. I reality, the tasks are starting at near the same time, however the timestamps make it display differently. You can see more details about the timestamp in the KB below. I suggest that rather than using loops you put all the tasks configuration in parallel below each other like I have done in my picture previously attached.

Why Is the Waveform Timing Information Returned by NI-DAQmx Incorrect?
http://digital.ni.com/public.nsf/websearch/5D42CCB17A70A06686256DBA007C5EEA?OpenDocument

[alysko]

 Dear Chris,

Thank you for the explanation and for the useful link. I have asked some questions regarding timestamps previously, and I am aware of certain limitations. Unfortunatey, I am still dissatisfied with your explanation 🙂 Here are my reasons:

1) If you look carefully at the timing in the picture attached to the first message, you will see that the time difference between the loop iterations is small, on the order of ten ms. The distance between the waveforms is on the other hand about 1000 ms.

2) Moreover, if I increase the acquisition time to 10 s, the distance becomes 10 s.

3) Any way, No jitter in program execusion timing or miscalculation of timestamp for a waveform can explain it, unless there is an inconsistency in the DAQmx (which I suspect) or something is REALLY WRONG with calculaitons of timing (as you stipulate, looking at the magnitude of the error). 

4) In addition, as far as I could check, all the VI-s involved are reentrant. It might be that this bug is in 7.1.1 only.

Could you please confirm these statements with the development team and come back to me?

I have to say that I would like to implement your model but I would not be able to place VIs to run in parallel in a simple manner as you did because I do not know beforehand how many VIs are to execute (a user-defined set-up). It is already that I had to aggregate channels per device before attempting to do DAQ, and then to disassemble the data and re-distribute in accordance to the setup (all because the drivers cannot handle adding new channels to an existing measurement process). Once I accomplished that, I found that there is another trouble (the one we are discussion now). On the constructive side, I could start the DAQ processes as separate re-entrant VI-s (like it is done in one of the TCP server/client examples) and try to synch them through the Timed Loop  timing mechanism but I would expect that I could not get a better timing than what I get now. It would not be much different to your example either, because an iteration of a loop does not add a sufficient overhead to account for 1 second.

I am looking forward to hear from you soon.

Kind regards

Albert

[Chris_D]

Hey Albert,

Since the t0 value is determined by the first time the DAQmx Read is called, this can causing some major problems for the waveform timing considering your architecture. It does seem strange that each of the waveforms are exactly the distance apart as the acquisition time. I am thinking that this has something to do with the way you are implementing the Wait Until Done VI. This VI is not generally used in acquisition tasks. From the looks of it, the waveform may get the t0 value from the system time when this VI is called rather than the Read. From the graph it looks like the first 2 waveforms are separated by the entire acquisition time and the 2nd and 3rd waveform only by a smaller amount. This would make sense since the first iteration of the loop cannot finish executing until the Wait Until Done VI returns, which only returns after the task is complete. In the second iteration of the loop it will call the Wait Until Done VI, grab the second waveform's t0, but this time not have to wait for the task to complete since it should already be completed. Next, the third iteration executes and it the Wait Until Done VI again does not have to wait for the task to complete so returns instantly. This is why the second and third waveforms are closer together.

I hope my explanation is clear and is there anyway you can post the VI shown in the picture? This will help me confirm my idea about the problem. Thanks.

[alysko]

  Dear Chris,

There is another reason for the difference between the 1st and other waveforms. The first one was acquired from a physical device (Dev4, if i am not mistaken). The other two waveforms were acquired from a simulated device (Dev1?). Since I have groupped the channels per device before starting the acquisition, there is a difference between the Devices... I believe that the small time shift between the channels of the simulated device is due to NI's drivers (to help the end user 🙂

I will be happy to send you the VI. However, is there a way to mail it to you or some other private uploading option?

Thanks!

Regards

Albert

[alysko]

  Dear Chris,

There is another reason for the difference between the 1st and other waveforms. The first one was acquired from a physical device (Dev3, if i am not mistaken). The other two waveforms were acquired from a simulated device (Dev1?). Since I have groupped the channels per device before starting the acquisition, there is a difference between the Devices... I believe that the small time shift between the channels of the simulated device is due to NI's drivers (to help the end user 🙂

I must add that I have not used the "Wait Until Done" VI as you assume. I have used "DAQmx Is Task Done" VI. The respective loop waits until all Devices are finished with acquisition and then gives control to the "DAQmx Read" to simply take the data from the buffers.

I will be happy to send you the VI. Is there a way to email it to you or some other private uploading option?

Please note that the same effect may be observed from the VIs I have attached to the 2nd message. There is also a difference in the behaviour of the simulated and physical devices:

• Two different simulated devices run in parallel with no trouble. Moreover, it does not take them any time to produce "Done"!
• A scenario with a physical and a simulated device shows a different behaviour (I used simulated "Dev1/ai0:3" for the upper branch, and physical "Dev3/ai0:1" for the lower branch). Physical device takes its time (as much as needed to acquired the waveform) and then the simulated device produces the results instantly.

Did you hear anything from the development team as yet?

Regards

Albert

[Mark_E]

Hi Alfred,

It seems you're seeing a difference in the timestamp returned when using simulated mixed with real hardware. I found a good tutorial on simulated devices that mentions the timing differences. There are bound to be problems when using simulated hardware with real hardware when it comes to comparing their timestamps. Do you have at least two USB-600x devices that you could try with your code? I suspect things will work better using two identical devices (i.e. both real).

NI-DAQmx Simulated Devices