LabVIEW

cancel
Showing results for 
Search instead for 
Did you mean: 

DAQ task necessary time for starting

I have a time delay problem about DAQ, and hope anyone can give some advice.

I am syncronizing my DAQ task to another device. The DAQ device runs its task once, and another device runs its task once as well.
Both need to be started together, and either of each finishes should waits until the other finishes, then both of them re-start again for another cycle.

For the DAQ part, I define the task(finite sample mode)/data/writing, and then I used reserve task to ensure its information is kept, and then the loop is start>wait tuntil> stop, then re-start again (syncronized with another device by a for loop).

 

The whole thing works well, but the problem is, everytime the DAQ needs to repeat its cycle, it take about 50 ms to "prepare", so my loops dont continue smoothly rather has 50 ms gap in between. (there is always a gap, but 50 ms is too much for me, and I am sure it comes from the DAQ delay.)
I have tried it on labview, and on the c++, both are the same. 


One possible solution is to use the continual mode, and then define the data well previously, so the DAQ will run smoothly after starting. But the problem is, aother device has no hint to syncronize with DAQ in this case.

So, I am wondering:
1. in the finite sample mode, is there any method to shorten the 50ms delay between each time DAQ start its task?
2. in the contimual mode, is it possible to ask the DAQ to send out some pulse/signal for others to syncronize?
3. Or should I use the global timing (or another pulse signal having the same frequency to the DAQ signal), and then sycronize my another device based on the global timing, providing the global timing is defined well and the same as the DAQ task?

 
Many thanks
Regards, Jhensi

0 Kudos
Message 1 of 18
(3,353 Views)

Hi js777,

 

Thanks for posting. I'm interested in the particular hardware that you have so that I can look in to their timing properties. I've not come across the issue of waiting 50ms to restart so I'm guessing this is something to do with timing in one of your loops? If so, and your hardware can handle it, it should be possible to reduce this 50ms delay. In terms of synchronising, it is definitely possible to synchronise tasks in continual mode so I recommend this. I also recommend taking a look at the following within the Example Finder:

Hardware Input and Output -> DAQmx -> Synchronisation -> Analog Input - Synchronistation

 

This example is an excellent demonstration on synchronising two separate tasks by utilising the features of their sample clocks.


ShalimarA | CLA
0 Kudos
Message 2 of 18
(3,308 Views)

Hi Shalimar:

Thank you for reply.

--

Attached picture 01 is the loop I am using. 
There is  ~50ms gap between each loop.
That is why I think DAQ_start may just needs so much time to execute. (at least in this device)
The device I am using is USB-6211

--

For the example you suggest, it is syncronizing a input s/n and a output s/n.

What I want to do is to syncroznie a finite output event to a continuous out put event.
Attached picture 02 shows the main idea.

This .vi is a failed one, the output cannot be the reference to the trigger command, but what I want is to actually refer to the continuous output.

My continual event is an sine wave, and I need the finite event to be trigged after a certain number, say N, of this sine wave.
(so it is not just a trigger, I need to count how many cycles of the sine to trigger.)
(this sine wave is used to drive another device, so I cannot just replace it by a timer. I need that sine anglog signal.)

What I was thinking is to create a virtual channel, which can feed in to the trigger.
This virtual channel carries a sine wave which has a fequecncy whichi is 1/N of the continual event frequency.
So what I need to do is to synchronize the virtual channel to the continual event. (But it is like one global timer for the finite event to run)

I am not sure how to actually implement it. (Or maybe it is not a good idea either)


Many thanks
Regards
Jhensi

Download All
0 Kudos
Message 3 of 18
(3,292 Views)

Hi,

 

Thanks for posting again. I've actually been looking through our resources and see that you had a previous service request open with my colleague. I see that it was solved and that he explained to you things like the USB 6211's limitations and advised you on your application in general, including developing code. 

 

I was wondering then what was the difference between this post and that service request? As it seems the issue was resolved then I'm uncertain as to how you wish to move forward.


ShalimarA | CLA
0 Kudos
Message 4 of 18
(3,268 Views)

Hi Shalimar:

Yes, there was a request through the technicial support.

They are basically similar (or say the same in many ways).

The thing is, even by the final .vi code from the support by then, it still has 50 ms delay in each loop. 
The reply I got was "it is about the hardware limitation".

At the very beginning, I was thinking to do it continually (rather than by using finite mode).
However, both of us realized it is not easy to reach what I want (at least on USB 6211), so we both went to the finite mode, a
nd then tried to get to the low levels DAQ, and reduce the delay.

If there is any recorded file in the tracking system, you can take a look.
oh, btw, at the end, I used "reserve mission" (as I shown in the picture) to simplize the .vi file. Although they both have 50 ms delay.


Now, I am thinking maybe I should still stick to continual mode to get rid fo the delay. 
But I need to handle the same problem, which we (me and the support by then) didnt solve.

Many thanks
Regards, Jhensi


0 Kudos
Message 5 of 18
(3,262 Views)

In terms of the actual 50ms delay, my colleague was correct in saying that this was a hardware limitation. USB has high latency and the issue would be with the rate at which the DAQ device communicates with your PC. If you need something smaller than 50ms you may need to consider a different form factor of DAQ device. 

 

I've seen in another of your posts that someone from the community has asked if you should be using RT/FPGA as they would be able to handle the timing delays that you're asking for. 


ShalimarA | CLA
0 Kudos
Message 6 of 18
(3,252 Views)

Hi 
Thank you for the reply. Yes, I am aware fo that.

So, I was thinking another situtation, and how about this (not sure if it is possible):

I have two signals, 1st one can be driven in continual mode, and 2nd one is driven in finite mode.
The 2nd one is to wait for the trigger and then run once before the next trigger.
The trigger is according to the 1st signal.

Since the 1st signal is running in continual mode, there is no delay or gap for it.
For the 2nd s/n, it needs to be started everytime through the USB, which cause ~50 ms, but I can bear that one for the 2nd s/n.

In this case, what I need to do is to have the trigger for 2nd s/n based on 1st s/n, and here is my question: how to retrieve the s/n from a continual A/O(1st s/n)?
(what I am thinking is to parallel link it to one of my A/I from the hardware after the A/O is sent out, and then use it as a trigger, but it seems not clever, probably more delay caused from USB again, so I was wondering how to retrieve it from the API inside)

Many thanks
Regards, Jhensi

0 Kudos
Message 7 of 18
(3,245 Views)

(repeat post, seems I cannot delete the reply itself, so I just delete the content.)

0 Kudos
Message 8 of 18
(3,244 Views)

Hi Jhen-Si,

 

You're right in saying that you can read the signal back from an analog input, but that would cause a delay as well so it would be up to you to determine whether the delay is acceptable, perhaps by testing it and seeing what effect it has on your system.

 

You could also try implementing the selection in software but I wouldn't recommend this approach as you may start the trigger at the incorrect time, for example, as the software will have a delay and give inaccurate results.

 

Overall, I'd recommend the hardware approach as, even though there will be a delay, the information you get will be more accurate. 


ShalimarA | CLA
0 Kudos
Message 9 of 18
(3,224 Views)

Hi:

I just tried what I was thinking. But seems I met some new problems.

I take the A/output back to one of my A/input ports, I only took one value at one time, and then processed it.
I used the Math node to determine if this value is a trigger or not.
This part works well, and it is pretty accurate.
Even with some delay, I can syncronize the A/input to the A/output.
When the correct value came in, and I sent an variable out from the Math node (0 or 1 value, depends on if it is a trigger) to control an event structure (which is the thing I want to trigger).

But in the end, I still failed in syncronizing.

I can bear the delay, only if the delay is stable. (I can bear the delay only if its flunctuation is less than 50 us.)
In the case I tried, I got the delay with  flunctuation of time about +/- 1 ms. It is too rough.

I am thinking probably the time delay from math node or event structure is not a constant. But not sure about it.
I have measure the syncronization between A/input and A/output by their sampling number, and they are fine.
Seems there is no timer with accurary of micro second in the labview , in that case I might beed to make one by the windows .dll file.
Before doing that, I am wondering does anyone have any idea? or probably there are other issues prossibly cause unstable delay?

Many thanks
Regards, Jhensi

0 Kudos
Message 10 of 18
(3,207 Views)