LabVIEW

cancel
Showing results for 
Search instead for 
Did you mean: 

Same VI in Window 7 and Window 10

Solved!
Go to solution
 

Why ?

For Windows 7 OS 64bit, Time=100ms (deviation is small).
For Window 10 OS 64bit, Time varies, ranging  from 160 ms to 220ms.

Capture.JPG

0 Kudos
Message 1 of 11
(1,465 Views)

Hi AdMan,

 


@Reed001 wrote:

Why ?


Because of the different OS!?

 

What's the point in waiting for the next 1ms multiple a hundred times? This will result in a lot of jitter!

Why don't you wait for multiples of 100ms?

Best regards,
GerdW


using LV2016/2019/2021 on Win10/11+cRIO, TestStand2016/2019
0 Kudos
Message 2 of 11
(1,429 Views)

Windows is not a realtime OS and your experiment hints that the OS is to blame, not LabVIEW.

 

(See also)

 

Of course your message is a bit sparse because we don't know what else has changed. (computer hardware, CPU, LabVIEW version, etc. etc.). Unless all you did was change windows version while keeping everything else constant, all bets are off anyway.

 

(Also, can you explain why you need that sequence structure? In fact, the wait function outputs the ms value, so the following code would be equivalent:)

 

altenbach_0-1608106413828.png

 

Personally, I would use "high resolution relative seconds" for the ticker. Still does not change the fact that windows cannot guarantee milliseconds.)

 

0 Kudos
Message 3 of 11
(1,422 Views)

Same PC hardware ,same LabVIEW version and different Windows OS.

The original design aims to simulate CAN node to transmit CAN messages cyclically with different periods. Setting waiting-time equal to 1ms is used as time quantum.When the elapse time is integer times of period of certain message, the message needs to be transmit. The period ,purely up to the user's definition, is changeable.

Capture.JPG

 

0 Kudos
Message 4 of 11
(1,381 Views)

Thanks for your response. The 1ms is used as time quantum. The details is on the fourth floor.

0 Kudos
Message 5 of 11
(1,376 Views)
Solution
Accepted by topic author Reed001

Hi Reed,

 


@Reed001 wrote:

Same PC hardware ,same LabVIEW version and different Windows OS.

The original design aims to simulate CAN node to transmit CAN messages cyclically with different periods. Setting waiting-time equal to 1ms is used as time quantum.When the elapse time is integer times of period of certain message, the message needs to be transmit. The period ,purely up to the user's definition, is changeable.


Simple solution: Switch back to Win7 when it was working more stable for your requirement!

You cannot rely on OS timing for plain Windows in the millisecond range. Point. Even on Win7 you might get such problems like you face now…

 

Suggestions:

  • You might try the timed while loop, it might improve timing behaviour a little bit (but it still runs on your plain Win10 OS with its limitations).
  • You might try to split your different messages into some kind of actors, each one running on its own loop speed handling only one ArbID/message…
  • You might change to a realtime target, like a cRIO, when you need realtime behaviour.
  • You might employ hardware abilities. Your CAN device might be able to send CAN messages with afixed delay on its own…
Best regards,
GerdW


using LV2016/2019/2021 on Win10/11+cRIO, TestStand2016/2019
0 Kudos
Message 6 of 11
(1,368 Views)

1ms wait is asking for trouble if you rely on it being accurate.

Try 5 or 10 and it'll work well on both systems.

G# - Award winning reference based OOP for LV, for free! - Qestit VIPM GitHub

Qestit Systems
Certified-LabVIEW-Developer
0 Kudos
Message 7 of 11
(1,359 Views)
Solution
Accepted by topic author Reed001

@Yamaeda wrote:

1ms wait is asking for trouble if you rely on it being accurate.

Try 5 or 10 and it'll work well on both systems.


Actually no! This is Windows and I would not say it "will work well" but instead "it will usually work well".

 

There is no guarantee under any standard desktop operating system that it won't simply decide to take a guru meditation nap for multiple 10th or 100ds of milliseconds, and even seconds. Under Linux you can better control what else is going on if you really care and understand how the system is configured, but the modern desktop OSes like Windows and Mac OS simply have to much going on in the background for user convenience that such guarantees could be even remotely made.

 

Under a realtime system there is some guarantee especially if you use the timed loop, but that usually won't be below 1 ms. A few ms is doable but 1ms or lower is stretching the capabilities of a system if you are not really careful about what else is running on that system.

 

The difference between Windows 7 and Windows 10 as reported here is simply an indication. Windows 10 is more complex and has many more services running in the background by default that can snoop time away from the user processes, but it is not necessarily a representative figure. It depends a lot on what other services, drivers and what else are installed on the given hardware. Some drivers can be buggy and a simple bug in the network or video card driver can cause huge differences on granularity and interval consistency of user process timing. Such drivers run in the privileged kernel and can in fact lock out hardware including the CPU almost completely from other use. A driver is supposed to only do that for the briefest possible amount of time, but bugs do happen.

Rolf Kalbermatter
My Blog
Message 8 of 11
(1,352 Views)

Thanks for you good suggestions.It's time to  consider some new solutions.

0 Kudos
Message 9 of 11
(1,322 Views)

Thanks for your response. It's time to consider some new solutions.

0 Kudos
Message 10 of 11
(1,321 Views)