Best practise for a Wait feature on MacOS?

[Mikael_Garcia]

Thanks for the heads up on the timed loop. Unfortunately it does not seem to exist in MacOS... It seems to be a Windows/Real-time feature only: https://zone.ni.com/reference/en-XX/help/371361R-01/glang/timed_loop/

In order to sort this out I also tried the high-precision timer as suggested. I created a simple test VI to evaluate things. In this example I use the frame-loop, a feature I normally never use but it came in handy in this quick test to avoid race conditions.

When you run this VI with a short time (e.g. 5 seconds) the time it overshoots is in the order of a few milliseconds which is expected and all good.

However, when I run this test VI on a Mac with a delay of 900 seconds (15 minutes), the Mac energy settings shown below, and with the VI priority set to the highest level (time critical) I get an overshoot of 12 seconds (see below)!

For comparisons, I ran the same VI in LabVIEW 2015 under Windows 10 (but with normal VI priority) and with the computer set to never sleep. This resulted in an overshoot for the 15 minute delay of 5 milliseconds... That is how it should be!

This all seems to indicate that this is a MacOS bug unfortunately. Perhaps it can't be fixed as it could be an OS limitation... If any Mac user reads this and has experience with long delays, please share your thoughts with us. Thanks!!

Test VI in LabVIEW 2021 with resultsEnergy settings

[JÞB · Accepted solution]

---

---

@Mikael_Garcia wrote:

Thanks for the heads up on the timed loop. Unfortunately it does not seem to exist in MacOS... It seems to be a Windows/Real-time feature only: https://zone.ni.com/reference/en-XX/help/371361R-01/glang/timed_loop/

In order to sort this out I also tried the high-precision timer as suggested. I created a simple test VI to evaluate things. In this example I use the frame-loop, a feature I normally never use but it came in handy in this quick test to avoid race conditions.

When you run this VI with a short time (e.g. 5 seconds) the time it overshoots is in the order of a few milliseconds which is expected and all good.

However, when I run this test VI on a Mac with a delay of 900 seconds (15 minutes), the Mac energy settings shown below, and with the VI priority set to the highest level (time critical) I get an overshoot of 12 seconds (see below)!

For comparisons, I ran the same VI in LabVIEW 2015 under Windows 10 (but with normal VI priority) and with the computer set to never sleep. This resulted in an overshoot for the 15 minute delay of 5 milliseconds... That is how it should be!

This all seems to indicate that this is a MacOS bug unfortunately. Perhaps it can't be fixed as it could be an OS limitation... If any Mac user reads this and has experience with long delays, please share your thoughts with us. Thanks!!

Test VI in LabVIEW 2021 with resultsEnergy settings

---

@Mikael_Garcia wrote:

Thanks for the heads up on the timed loop. Unfortunately it does not seem to exist in MacOS... It seems to be a Windows/Real-time feature only: https://zone.ni.com/reference/en-XX/help/371361R-01/glang/timed_loop/

In order to sort this out I also tried the high-precision timer as suggested. I created a simple test VI to evaluate things. In this example I use the frame-loop, a feature I normally never use but it came in handy in this quick test to avoid race conditions.

When you run this VI with a short time (e.g. 5 seconds) the time it overshoots is in the order of a few milliseconds which is expected and all good.

However, when I run this test VI on a Mac with a delay of 900 seconds (15 minutes), the Mac energy settings shown below, and with the VI priority set to the highest level (time critical) I get an overshoot of 12 seconds (see below)!

For comparisons, I ran the same VI in LabVIEW 2015 under Windows 10 (but with normal VI priority) and with the computer set to never sleep. This resulted in an overshoot for the 15 minute delay of 5 milliseconds... That is how it should be!

This all seems to indicate that this is a MacOS bug unfortunately. Perhaps it can't be fixed as it could be an OS limitation... If any Mac user reads this and has experience with long delays, please share your thoughts with us. Thanks!!

Test VI in LabVIEW 2021 with resultsEnergy settings

---

No, no, no!  Get away from Wait (mS)!  You want to isolate the mSec timer kernel driver.  Use only the high resolution timer either, as shown in lightning wait.vi attached to the Nugget or, use the wait hi-res available from the 2018 or later timing pallet.  That's about the only way to determine if MAC OS is shutting down ms timer updates.

EDIT: Where did the other 20 seconds go? 912.2xx + 1:36:35.7xx = 1:51:48+change your missing a whole chunk in the last frame

EDIT II: Enable Power Nap.  That appears to actually set a timer interrupt.

[Mikael_Garcia]

Good points again! I left the ms timer in there to be able to compare with Windows as that worked fine there.

While trying more combinations I stumbled upon the solution! In Windows you have to make sure that the computer never sleeps and all is good. No need to set the VI priority to top or anything else. On MacOS you have to make sure two things are done to make it work! First you have to set the slider in Turn Display Off After to "Never" in the energy settings as has been discussed here before. But, and this is what got me, you also need to set the Screen Saver to never come on! It is in a different settings menu in MacOS. The screen saver seems to initiate the low-power mode which slows the execution down. The VI setting of "highest priority" is not needed. The priority can be set to normal as long as the previous two things are taken care of! That is how it is in Windows too.

Good spotting of the missing 20 seconds. I did not comment on it but I see it as a symptom of the same problem - the execution slows down when the computer goes into this low power mode. In this case it took several seconds to go from frame 2 to frame 3... 

To sum it all up: If you are on MacOS and rely on timers during long measurements - please tell the user of your program that both the screen saver and the display off feature have to be set to Never.

[JÞB]

That makes a little sense. Calls to the mSec and Hi Res timers both call kernel drivers and require the UI Thread. I imagine the screen saver floods the UI Thread by definition. Sneaky and insidious.

[Mikael_Garcia]

WOW! JPB hit the nail on the head! Thank you!!!

Although I had found a solution, or rather workaround, by disabling both the screen saver and the display sleep in the MacOS settings, I was not fully satisfied so I decided to run one more experiment... Since JPB pointed out that I should remove the ms-wait in the loop I decided to try the following:

1. Remove the ms wait in the loop in the VI shown above.

2. Use my default OS settings (have screen saver come on after 5 minutes and display to go to sleep after 10 minutes). Thus - no modifications at all!

The results? It worked like a charm!!!

The results are shown below. Amazing! Thank you again JPB!!

Thus, the conclusion here is that on MacOS you should never rely on the ms-wait in a timing loop as the screen saver or any other low-energy mode might slow it down substantially!

[JÞB]

Nicely followed up!!!

You did not find a solution HOWEVER, you did isolate that your version of the MAC OS blows off the mSec timer updates in the kernel when certain power scenarios engage.  

I guess it really does only take one bad Apple to spoil a bushel.

And that's a Latin Capital Thorn þ! As in, Jay Thornby sounds like "JÞB".  alt+0222 on Windows or long press T for Android. Mac and iPhone may use a slightly different char map but you can usually work around those silly systems.:)