Trying some things. Figuring some things out.
Since I noticed that the bug always occurs when the connection to the front panel is broken I can at least put my computer to sleep with the front panel open to induce the connection being lost. Can't find a good way to programmatically achieve this, but this works too.
I thought that perhaps the XY plots themselves are at fault since they likely demand more resources than a plain old numeric indicator or whatnot.
I first disabled the XY plot writing loop with a case structure and a false constant going to the case selector. Induced a front panel disconnect, looked at the saved data, and there was still 60 saves all happening in a fraction of a second. Problem not solved.
One thing both the consumer loops and XY plot writing loop have in common is they interact with items on the front panel. There's an invoke node in the Acquire state which reinitializes a boolean control (to make it latch until it's processed). Same thing in the XY plot writing loop, just a different boolean control.
So then I disabled the reinitialize to default invoke node in the Acquire state. I induced another front panel disconnect, looked at the save data, and guess what! No more 60 saves within a fraction of a second!
Then I double checked my work to see if disabling the reinitialize invoke nodes in the XY plot writing loop would also solve the blip that would show up in the XY plots, and it sure did!
It seems that the issue is that when the front panel becomes disconnected any invoke/property nodes that act on a front panel object get hung up briefly while the cRIO sorts itself out. Which explains why the other loops like the save timer (which have no invoke or property nodes) continue to run unhindered. This would also explain why the XY plots showed a brief span where there's a larger gap between data points since the invoke node in that loop would stall the loop. Still not clear why it was always exactly a minute, but that's more of a curiosity than a need-to-know now that I have solved the issue.
I am going to add a queue that sends a message to an external loop to handle the invoke nodes that were causing this issue. If the front panel is disconnected that means the user has left it unattended which means the reinitialization invoke nodes just tell a control in the false state to go to the false state. For my own knowledge, is there a simpler solution involving priorities of the front panel vs. the rest of the code?
Also, since this went from thinking it had to do with save file size to XY plots with too much data to reentrancy and finally to front panel disconnect - is there any way to change the title of my post so that other LabVIEW users who have this problem in the future can find my post easier?
