I have a app which communicates with a weather monitor via a serial port. It has to send separate commands to retrieve each parameter. I do this periodically in a loop triggered by a 10 second timer. Each command is triggered in turn by the successful processing of the response from preceding one. Results are plotted on various graphs, and stored to various files, including a single-line file which is handy to see what is going on.
I initially developed this on an old machine, macOS 10.6 or 10.7 and it worked fine. The various machines I use it on have by and by been updated to macOS versions between 10.11, 10.13 and 10.14. They all show the same behaviour, as follows.
Everything is fine until the screen enters screen saver or sleep (the computer itself never sleeps). At this point the graph showing the first parameter in the 10 sec loop works fine, and the trace is fully complete if the screen is reactivated. The graphs for the subsequent parameters are straight lines, showing no update during that period.
The single-line file continues to be updated every 10 seconds. It includes a parameter “since”, which records the seconds since the last valid measurement, and that is defined with reference to a time set when the last of the parameters has been read. Once the screen saver kicks in, that reference time is not updated and the “since” parameter grows steadily.
This indicates that the overall app is functioning fine during the screen save (timer, file writing etc.). But the handling of the serial port slows down so that only the first parameter gets processed until the loop restarts 10 sec later.
As the name suggests, a screen saver was designed to prevent characters from burning into the phosphor in CRT monitors. Allegedly, if you left stuff on the screen for long enough without changing anything, you’d get ghost images of said stuff, which could be overcome only by buying a new monitor. A screen saver was supposed to prevent this by displaying something else, often a moving image, to prevent burn-in. Today’s flat screen monitors of whatever technology don’t suffer from burn-in. So unless you’re the last person on Earth still using a CRT monitor, why not just disable the screen saver?
Thanks for all replies. I bought the license for the MonkeyBread plugin and tried suppressing App Nap in the apps’s open event. Unfortunately it didn’t make any difference. In fact the app itself was not napping. It was always continuing to process its timer and trigger the regular activity. As I said before, the first parameter in the cascade of parameter requests via the serial port works, but the others do not. Another parameter, which I get over a TCP socket continues being collected, but with some evident dropouts too.
To Peter:
actually I have had burn-in on flat screen monitors I have at least systems monitoring apps in the observatory, on various displays, and with the app windows left where they are for months on end.
But there are other answers:
it also occurs with screen sleep, and that is always useful as an energy saving mechanism (one of my displays is an old Apple 30" Cinema display which also works as an effective room heater
this is an app on the Mac App Store. It’s not going to be popular to tell my users to disable screen savers and screen sleep.
I have at least systems monitoring apps in the observatory, on various displays, and with the app windows left where they are for months on end.