Question about timeSetEvent

[Bublina]

It is not really what I wanted 🙂

What does it mean "program will finish sample data from instrument". What is that instrument ? Is it NI HW ? What is its max. sampling rate ? Is it capable of some triggering ?

If you need precise timing for measuring data, it is not good idea to poll these measurements from computer, you will face another jitter caused by Windows <-> PC <-> instrument  communication.

[rolfk]

---

@fjczd wrote:

Bublina

      In our project ,the requirement of jitter is not larger than 1ms and the loop time is 50ms. That is, the range of ioop time is from 49ms to 51ms.During the loop time, the program will finish sample dada from instrument and calculate and data store.

    Other language, such VC/VB, which can meet the requirements with “timeSetEvent” (which in winmm.dll) in Windows XP. After previous discussion, we find LabVIEW can not use “timeSetEvent”,because it need callback.

    But I guess maybe LabVIEW will have other way to meet the requirement in Windows XP.I think other language can do ,LabVIEW can do also.

---

Even in VC you can NOT guarantee under normal Windows that a loop timing will be accurate to 1ms. Windows is a multithreading non-realtime operating system. Unless you install some realtime kernel extension and take extra precautions to run your particular code under the control of this extension, you can have delays of many ms, in which your entire user space can be suspended by driver interrupts and high priority kernel driver routines.

Even your timeSetEvent() call can NOT guarantee that your callback routine will be executed to 1ms precision. It is very likely that it will execute to that precision in 99.9% of the cases on modern high performance hardware but there is no way to guarantee that under normal Windows. The same applies to any other desktop OS, like Linux (standard version, not with realtime kernel extension) or MacOS X. And if you use some kind of realtime kernel extension you need to do quite a bit more than calling timeSetEvent() in your C code to make sure the routine in question is executed in a context that is under control of that kernel extension.

[fjczd]

    Bublina

    Thank you for your advice

    My instrument is PXI 8106,PXI 6602, Parameters such as sampling rate is not too important, the most important thing is that every a determined time (such as 50ms) to complete a collection, computing, storage.

[fjczd]

    rolfk

    It seems that timeSetEvent () is not a particularly good choice even for VC. If the time deterministic is higher, we need to use real-time systems.Is really?

    How about time deterministic with timeSetEvent () in VC, 10ms or higher?

[nathand]

---

@fjczd wrote:

    My instrument is PXI 8106,PXI 6602, Parameters such as sampling rate is not too important, the most important thing is that every a determined time (such as 50ms) to complete a collection, computing, storage.

---

Just wondering... why is it critical to complete the computation and storage in exactly 50ms?  Your hardware should be able to do hardware-timed acquisitions, meaning that you can read the same number of precisely timed samples even if the program that's reading them has some jitter.  You can possibly even use the DAQ card as a timing source for a timed loop, so that your code executes whenever a certain number of samples are available.

[fjczd]

---

@nathand wrote:

---

@fjczd wrote:

    My instrument is PXI 8106,PXI 6602, Parameters such as sampling rate is not too important, the most important thing is that every a determined time (such as 50ms) to complete a collection, computing, storage.

---

Just wondering... why is it critical to complete the computation and storage in exactly 50ms?  Your hardware should be able to do hardware-timed acquisitions, meaning that you can read the same number of precisely timed samples even if the program that's reading them has some jitter.  You can possibly even use the DAQ card as a timing source for a timed loop, so that your code executes whenever a certain number of samples are available.

---

    In fact, in addition to PXI 6602, there are three devices communicate via modbus.

    For PXI 6602,I tested individually before, each acquisition cycle time is about 20 ms, with only occasional jitter(about 30ms)

    For modbus,I also tested individually,each cycle time is about 150ms,with jitter of course. I feel that communication via modbus with modbus is a serious bottleneck.

    But even with the timed loop cycle in PXI6602, there is large jitter, such as mouse click or keyup event will cause jitter, it is very obvious, so I would like to use the timeSetEvent ().

    But by the preceding discussion, it seems that the real-time system is the only choice..

[rolfk]

---

@fjczd wrote:

    @rolfk

    It seems that timeSetEvent () is not a particularly good choice even for VC. If the time deterministic is higher, we need to use real-time systems.Is really?

    How about time deterministic with timeSetEvent () in VC, 10ms or higher?

---

Much higher, as long as you mean with deterministic the same thing as guaranteed! In fact under Windows you can absolutely not guarantee any specific timing responsiveness as long as you do not go into kernel mode. Only a kernel mode device driver gets enough control over Windows scheduling and other stuff to come close to any form of deterministic timing responsiveness. Although it is not very likely, your user space task can be easily suspended for seconds at a time. Just try to start some software and then go into Control Panel and uninstall some component there. Chances are that your other software will more or less get completely suspended for very long times, since Windows installer technology likes to use some rather deep going system locks in order to make sure, the consistency of the system can not be compromised by concurrent tasks trying to mess with the registry and other OS parts at that moment.

And the installer component is not the only one using such far reaching locks. During loading of shared libraries, similar things happen, since the internal global tables that Windows uses to manage the loaded libraries would get messed up if libraries would be loaded and unloaded concurrently from different places. Loading a library is usually quick but if the library programmer was lazy and has put some pretty long lasting operation into the library initialization routine (against the strong advise of Microsoft to not do such things) any other thread in the system that tries to load a library at the same time, will be totally blocked for that time.

And yes a realtime system is the only viable choice if you really need absolutely deterministic timing behaviour. Please note that realtime does not necessarily mean fast, but deterministic. Most realtime systems are much more resource constrained that modern multicore, super duper hyperthreading desktop systems with GFlops of CPU and GPU power and therefore the average response time is likely quicker on a desktop system than on a realtime system. However on the realtime system you can actually make some prognosis about the absolute maximum response time while on a desktop OS you simply can't. You only can say that in 99.9% of the cases the responsiveness will be below a certain value, but never can eliminate the 0.001 or so % that will be higher than whatever number you come up with.

[Bublina]

fjczd,

sorry if I overlooked it, but what is the A/D device(s) you use ? If you use modbus aka ethernet with some switch, you can expect jitters in communication.

I think, that your best option is to use an extra cable for synchronization pulses to trigger data collections, once you recieve the data, you can process them with whatever hardware you want to.

If your A/Ds have no synchronization option,  you won´t help much yourself using the RT OS since you cannot shake off the modbus jitter.

Anyway, 99% of marketed A/Ds can work with some sampling rate, so the most simple option is to use the A/D crystal for timing and rely on it.

If you use multiple A/Ds, start them all in the same time and measure the time you recieve the data, use these timestamps to recunstruct the signal for the specific time.

You can use higher sampling rate and with PC timestamps to compute the incoming signaltosignal shifts.

I used this solution once and it worked nicely, got same results as taken from a crazy hardware only apparature.

The only thing, that affects this way is the long time clock drift of different A/Ds, but if you intend to do max. 1 hour measurements, then you will get your ms precision.

[fjczd]

---

@rolfk wrote:

---

@fjczd wrote:

    @rolfk

    It seems that timeSetEvent () is not a particularly good choice even for VC. If the time deterministic is higher, we need to use real-time systems.Is really?

    How about time deterministic with timeSetEvent () in VC, 10ms or higher?

---

Much higher, as long as you mean with deterministic the same thing as guaranteed! In fact under Windows you can absolutely not guarantee any specific timing responsiveness as long as you do not go into kernel mode. Only a kernel mode device driver gets enough control over Windows scheduling and other stuff to come close to any form of deterministic timing responsiveness. Although it is not very likely, your user space task can be easily suspended for seconds at a time. Just try to start some software and then go into Control Panel and uninstall some component there. Chances are that your other software will more or less get completely suspended for very long times, since Windows installer technology likes to use some rather deep going system locks in order to make sure, the consistency of the system can not be compromised by concurrent tasks trying to mess with the registry and other OS parts at that moment.

And the installer component is not the only one using such far reaching locks. During loading of shared libraries, similar things happen, since the internal global tables that Windows uses to manage the loaded libraries would get messed up if libraries would be loaded and unloaded concurrently from different places. Loading a library is usually quick but if the library programmer was lazy and has put some pretty long lasting operation into the library initialization routine (against the strong advise of Microsoft to not do such things) any other thread in the system that tries to load a library at the same time, will be totally blocked for that time.

And yes a realtime system is the only viable choice if you really need absolutely deterministic timing behaviour. Please note that realtime does not necessarily mean fast, but deterministic. Most realtime systems are much more resource constrained that modern multicore, super duper hyperthreading desktop systems with GFlops of CPU and GPU power and therefore the average response time is likely quicker on a desktop system than on a realtime system. However on the realtime system you can actually make some prognosis about the absolute maximum response time while on a desktop OS you simply can't. You only can say that in 99.9% of the cases the responsiveness will be below a certain value, but never can eliminate the 0.001 or so % that will be higher than whatever number you come up with.

---

Thank you for such a detailed explanation, I am very benefit, at the same time, people who see this post, will be enlightened.

[fjczd]

---

@Bublina wrote:

fjczd,

sorry if I overlooked it, but what is the A/D device(s) you use ? If you use modbus aka ethernet with some switch, you can expect jitters in communication.

I think, that your best option is to use an extra cable for synchronization pulses to trigger data collections, once you recieve the data, you can process them with whatever hardware you want to.

If your A/Ds have no synchronization option,  you won´t help much yourself using the RT OS since you cannot shake off the modbus jitter.

Anyway, 99% of marketed A/Ds can work with some sampling rate, so the most simple option is to use the A/D crystal for timing and rely on it.

If you use multiple A/Ds, start them all in the same time and measure the time you recieve the data, use these timestamps to recunstruct the signal for the specific time.

You can use higher sampling rate and with PC timestamps to compute the incoming signaltosignal shifts.

I used this solution once and it worked nicely, got same results as taken from a crazy hardware only apparature.

The only thing, that affects this way is the long time clock drift of different A/Ds, but if you intend to do max. 1 hour measurements, then you will get your ms precision.

---

    About modbus problem, it has been found in the beginning ,and my colleague,have begun to choose other equipment instead modbus,so in the post mainly discuss “timeSetEvent”, real-time systems.

    Because the entire system is a real-time closed-loop control, so the certainty of time is main problem, rather than the accuracy only