From Friday, April 19th (11:00 PM CDT) through Saturday, April 20th (2:00 PM CDT), 2024, ni.com will undergo system upgrades that may result in temporary service interruption.
We appreciate your patience as we improve our online experience.
LabVIEW
It's impossible, but it happens.
Solved!
LV2013, Win7
OK, I'm working on a project which has a container window ("MegaMonitor").
On the window is a single TAB control with 12 pages.
On each page are 6 SubPanels, nothing else.
There is a single VI called the "Block" VI.
I put one instance of that VI into each of those 72 SubPanels, and the whole thing should run.
There is a TCP data stream coming in at 10 Hz, that gets decimated into various history arrays. Each Subpanel chooses a way to view a certain set of channels from that datastream.
The problem is, sometimes the process works just fine and dandy, The window opens up and starts running in 3-4 seconds, it shuts down in less than 1 second.
Sometimes it's like walking thru sludge - it takes 20-30 seconds to open up and run, it takes 60 or more seconds to shut down and recover.
I don't know what will make it work fast or slow - a restart TENDS to make it work fast the first time after, but not always.
Here is the launching code, in the container window:
I've tried CALL and FORGET, and CALL and COLLECT methods, rather than the RUN VI method - no real difference in behavior.
I've tried AUTO DISPOSE REF bothe TRUE and FALSE - no difference.
I need to know when the process has shutdown. The BLOCK Vi, as the first thing it does, puts a value into a STOP queue, and as the last thing it does, it takes a value OUT.
So the CONTAINER window can look for an empty queue to determine that it's done.
Here is that Shutdown Code:
There is an EVENT which triggers shutdown of the window - each block sees that event and shuts down:
After the event is heard, we log a debug message:
We save a few things in a PREFS structure:
We log another debug message:
And, as the last thing we do, we de-queue an item from the STOP queue:
The "SAVE A FEW THINGS" part is pretty simple - just store a structure into an array:
The SEND DEBUG thing just formats a string and sends via UDP to a receiver elsewhere. The sludge behavior happens whether debugging is turned on or not.
Stay Tuned for the impossible part...
I would make absolutely sure that you're not either flushing or destroying that queue somewhere else in the shutdown sequence. Maybe put an error indicator on the error output from Queue Status.
Well, lo and behold, there IS an error there - Error 1.
But I never touch that queue, not even to destroy it, except in two places:
1... When the block starts, I put an element in, when it stops, I take an element out.
2... When I'm checking if eveyone's done.
There's nothing to kill it, as far as I can see. But yet, it complains of an error 1 (bad parameter). The only parameter is the RefNum, so somebody is killing the queue.
