about time delay in labwindows

[PKIM]

Hi all,

  In labview, operations in the same frame will be executed at the same time.

Example was shown in the above image. The delay operation in the first frame will be started at the same time when hte channel being written. But in Labwindows, everything is running in sequence. So above operations in CVI might look like

    DAQmxWriteDigitalLines(taskHandle2, 1, 1, 10.0, DAQmx_Val_GroupByChannel, &value, NULL, NULL); 

    DAQmxWriteAnalogScalarF64(taskID,  1, 10.0, voltage,NULL);

    Sleep(1);

So the timing behavior changed a lot in labwindows, I have two questions

1) how long estimated will the DAQ output tasks take? I know it machine dependent butin modern computer, what's the average time does it take? will it done in millisecond?

2) In the labview code, I expect all operations done in 1ms. But in the labwindows code, it seems that it take more than 1ms. Is that any way in labwindows to have all those operations start at the same time?

[FoxSquirrel]

Hello PKIM,

So, you hit the nail on the head when you said it's going to vary.  It really depends on the computer as well as the DAQ device and what data you are writing or reading.  The best method to test this is to do some timing in CVI with a clock.  Some information about this can be found here: http://stackoverflow.com/questions/5248915/execution-time-of-c-program

With regards to your second question, LabVIEW automatically runs all 3 segments of code in parallel.  In CVI, to have a similar behavior, you need to do multithreading.  This will allow you to run multiple threads in parallel to perform each of your tasks on.  Information about multithreading can be found here: http://www.ni.com/white-paper/3663/en/

[PKIM]

---

@FoxSquirrel wrote:

Hello PKIM,

So, you hit the nail on the head when you said it's going to vary.  It really depends on the computer as well as the DAQ device and what data you are writing or reading.  The best method to test this is to do some timing in CVI with a clock.  Some information about this can be found here: http://stackoverflow.com/questions/5248915/execution-time-of-c-program

With regards to your second question, LabVIEW automatically runs all 3 segments of code in parallel.  In CVI, to have a similar behavior, you need to do multithreading.  This will allow you to run multiple threads in parallel to perform each of your tasks on.  Information about multithreading can be found here: http://www.ni.com/white-paper/3663/en/

---

Thanks for the reply. I am trying to use multithreading in the way mentioned in that page. I get it complied but there come to my question again. We use CmtScheduleThreadPoolFunction  to start one thread at a time, so it there are three tasks (like 3 analog ouputs) I should started 3 threads. But each thread is actually started in sequency so does it mean all the threads still runing in some order not really at the same time, right?

[RobertoBozzolo]

Before thinking to multithreading and sync between threads, you can sync DAQmx tasks as I suggested here. In this case you should be able to have both tasks run at the same time. The delay between timer start and daqmx start is negligible in nowadays system.

[RobertoBozzolo]

Being more specific, what are thinking of in discussing of so small time delays? If you are trying to achive some sort of deterministic behaviour you're on the wrong path: no Windows system can be used to obtain a reasonable constant timing, even the 1msec claimed by LabVIEW cannot be guaranteed in every condition.

Another solution to have those 3 tasks executed is to set analog and digital output to start at a counter start, and set the counter to expire in 1 sec and fire an event at counter end or sit in a loop waiting for this condition. But it's not guaranteed that next instruction will be executed at 1sec or 1.05 or 1.1...

[PKIM]

---

@RobertoBozzolo wrote:

Being more specific, what are thinking of in discussing of so small time delays? If you are trying to achive some sort of deterministic behaviour you're on the wrong path: no Windows system can be used to obtain a reasonable constant timing, even the 1msec claimed by LabVIEW cannot be guaranteed in every condition.

Another solution to have those 3 tasks executed is to set analog and digital output to start at a counter start, and set the counter to expire in 1 sec and fire an event at counter end or sit in a loop waiting for this condition. But it's not guaranteed that next instruction will be executed at 1sec or 1.05 or 1.1...

---

Thanks RobertoBozzolo. I understand that it is quick a tough task in windows to maintain such a small delay. The reason why I want that is I have some coding running in labview which use multithreading to start several anolog and digitial output to different channel, which are used to controll the shutter of external device. In the labview case, though all outputs do not start exactly the same time but they are pretty close. I am trying to reproduce the same thing in labwindows, but even with mutlithreading, it seems the multithreads do not seems to behave the same way as in labview. It seems that the threads in CVI start in more delay than the labview case.

[msaxon]

If you are using CVI 2013, you could consider using the OpenMP API for multithreading, which through use of some #pragmas and explicit functions is a much more lightweight (and possibly easier to program) mechanism for multithreading given what you are trying to achieve.

[PKIM]

---

@msaxon wrote:

If you are using CVI 2013, you could consider using the OpenMP API for multithreading, which through use of some #pragmas and explicit functions is a much more lightweight (and possibly easier to program) mechanism for multithreading given what you are trying to achieve.

---

Oh, I don't know that we could use OpenMP in CVI. I have one question, if I compile the CVI code with OpenMP supported in one computer. If I want to apply the compiled program to other computer, do I have to install OpenMP and/or CVI?

[RobertoBozzolo]

---

PKIM ha scritto:

Thanks RobertoBozzolo. I understand that it is quick a tough task in windows to maintain such a small delay. The reason why I want that is I have some coding running in labview which use multithreading to start several anolog and digitial output to different channel, which are used to controll the shutter of external device. In the labview case, though all outputs do not start exactly the same time but they are pretty close. I am trying to reproduce the same thing in labwindows, but even with mutlithreading, it seems the multithreads do not seems to behave the same way as in labview. It seems that the threads in CVI start in more delay than the labview case.

---

Highlighted sentence puzzles me a bit: you may have delays if you are starting threads in the exact moment in while you need them to run. It would be better to have threads started before this moment and simply make the execute some command when needed, e.g. issueing a PostDeferredCallToThread for a function that will start your tasks.

I have missed if you succeded in syncing your threads with a single start trigger.