Bytes at Port halts on Window maximization

[Mads]

LabVIEW 2012SP1f4 for Windows 32 bit

The short story:  All use of VISA's Bytes at port will halt for about 260 milliseconds whenever any window in the same application is maximized or minimized.

Background:
I'm working on an application that requires a serial link to transfer aquired data with a very low tolerance for discontinuities due to lack of time stamping and small buffers. The serial IO runs in a dedicated VI set to run in the DAQ execution system, with time critical priority, but whenever any of the GUI-windows of the application are maximized/minimized this causes a very large disturbance in the serial IO, and the continuity of the data aquisition gets broken.

Example:

Here's an example where I've stripped the problem down to a minimum, and measdure the time delay as it happens (the spikes on the chart). In this case you might argue that the GUI has too much coupling with the measurement, but that's not the case in the real code, and there is no difference in the effect then:

 

The funny thing is that I can stress the GUI in a number of ways (rescaling heavy GUIs manually during runs e.g.), but no such effect is visible then. Only with Maximization/Minimization (the former is worst).

I've tried to find info on this here at ni.com, as it's something I would expect others to have seen before, but did not find any.

Is this expected behaviour? "Property nodes run in the GUI"-type of thing, but VISA-properties? There are no alternatives if you need to get the byte count, is there...? I could try the non-VISA alternatives that are out there, but that would be a rather big rewrite at this time, with possibly other weaknesses...

[TroyK]

I can confirm it is the same for LabVIEW 2011 SP1.

I doubt this should be expected behavior. VISA serial functions seem to have a few problems. You should try VISA wait on event.

I replicated your VI and tried scaling the graph with the pane while resizing- barely any noticeable delay.

Tried deferring panel updates and writing to a graph afterwards, same result.

I'm sorry I have no explanation or answer, I can only confirm your results. ~260ms delay when minimizing/maximizing.

It's troubling.

[rolfk · Accepted solution]

For Minimizing/Maximaizing, Windows does a lot of things under the hood, among others also doing a so called memory size trimming. This means that Windows will page out any memory pages that haven't been used for a while, which will appear in the task manager as a massive drop in used memory. For this to work properly, Windows has to basically freeze most of the process so it can shuffle with memory under its feet, without the application running into a deadlock of some sorts. It's likely that not only Bytes at Serial Port is affected but also other VISA functions, but it's at least a try. Maybe NI did manage to keep most of the VISA driver unblocked here, but Bytes at Serial port has to call into the Windows COMM driver to do its work properly and that might be one place were Windows will block the process while trimming its memory.

So my first test would be to try with simple VISA functions, without the use of Bytes at Serial Port. Bytes at Serial Port is anyhow in 99% of the cases the wrong function to use. VISA has much more powerful functions with the termination mode on Read and/or timeout operation. Properly used they make Bytes at Serial Port not only unneccessary in almost all cases, but also beat it hands down in performance. The only case where Bytes at Serial Port really should be neccessary is when you try to implement a Serial Port Terminal type application.

If you find that the culprit is indeed only Bytes at Serial Port rewriting your code to simple use VISA Read with proper timeout/termination character operation will solve it. If the other VISA functions also get blocked (which I highly suspect) the only solution is to seperate your communication task into its own executable to seperate it from the UI, (or disable the option to minimize the front panel!).

[Mads]

The protocols in question do not have termination characters, but I can change the timeout to a more reasonable value and use that. I've tested it now, and it is not affected by window maximization/minimization.

[Mads]

PS.

I noted this as an accepted solution, but I still think NI should work on getting rid of the problem with Bytes at port...(or at least make it obvious that it has this weakness).

In cases where you do not know the length of the incoming message or want the serial IO to be protocol-aware, and/or have multiple devices on the link with individual timing characteristics the bytes at port-function is easy to grab for...