This one has got me stumped: When selecting a custom menu item with data on the clipboard the GUI freezes. Freezes are longer for more data and longer for older versions of Labview. I wrote the test code, attached, but the example "Menu Selection Demo.vi" shows the same behavior.
Running Labview 2011 here are some freeze delays for my laptop (a bit slower machine) with various amounts of text data on the clipboard:
Clipboard size Delay
1.3MB 2.1 sec
2.6MB 4.9 sec
3.8MB 17.2 sec
14MB 253.3 sec
The delay appears to be non-linear. A doubling of the clipboard data size more than doubles the delay and a tripling of the clipboard data size produces a delay of almost 10X! Things are also much, much worse on my ancient version 8.2.1 (over a 40 second freeze for 1.3MB and it goes up from there).
Note that the freeze also occurs on programs with a custom menu when exiting. This would seem to suggest it might have something to do with the timeout, but why timeout should vary with clipboard size and not with the value wired to it makes this feel even more like a bug in the custom menu functionality.
This seems to be related to known issues in Labview 2011 #39604 49UBP4LE (http://www.ni.com/white-paper/13168/en#39604_by_Date) that was first reported in version 8.2.1. This known issue relates to Labview freezing when large amounts of data are copied from Labview to the clipboard. No fix has been implemented since this was originally reported in 2007.
This freeze also occurs when shortcuts to menu items (such as Ctrl + L) are used when large amounts of data are on the clip board.
Thus far this has been 100% repeatable and I have not been able to find a way around it. I also haven't found anything else similar on the forums or on the web. It appears to be a GUI freeze with Labview still running in the background, which is also odd.
My work-arounds at this point are either to not use the clipboard (bad), programatically clear the clipboard several times each second (worse) or remove all custom menu functionality and replace those functions with onscreen controls. So, for now, I'm removing custom menu items because my users need the clipboard and I can't have massive delays making my data acquisition code look crashed.
Any ideas would be helpful. This one has me scratching my head...
I've recreated this problem on 3 different computers now. All computers were running Win XP Pro SP3.
OK, this just keeps getting weirder. With lots of data on the clipboard there are lots of freezes. I just added a pop-up subVI and with data on the clipboard there is a freeze (depending on amount of data) just in opening up another window. So, this doesn't appear to be about menus, it looks to be a broader problem with Labview and lots of data on the clipboard. It's become too broad to work around since my users need the clipboard during their tests.
I'm sorry to say that you have come across one of the known issues in LabVIEW. Unfortunately there aren't currently any known work arounds for having data on the clipboard and preventing this freezing. I wish I could deliver better news, but using the clipboard in this fashion will cause you to keep running into these problems.
Thanks for getting back. This is a nasty bug. The freeze happens for any menu click (custom or otherwise), for calling a subVI pop-up window and for pressing Ctrl+ any key (even if that combination of keys is not mapped to anything). As soon as there's a Meg or so of data on the clipboard using Labview at all becomes very dangerous.
One of my users had a hardware buffer overflow crash as a result of this freeze. They were copying gathered data using the clipboard, hit Ctrl+L to run a test function, froze and then over ran the buffer. It's been a nightmare since then.
The only 2 "solutions" I have so far are:
1) tell users not to put large amounts of data (which interrupts the work flow of the test and still risks another crash)
2) the code programatically clears the clipboard a few times a second. No crash, but also no clipboard... and therefor no screenshots in the test reports.
I'm going with #2 above but I really need to find another way. Do you have any ideas? Perhaps using the command prompt to try to determine which application has focus and then only clearing the clipboard if Labview has focus? I haven't found any way to determine which application has focus from within Labview. Any ideas?
To help me understand your application a little better, why are you copying to the clipboard data that you acquired while the program is still running? Rather than copying and pasting data to a different file, you could programmatically write the data to a different file.
The data copied was not from our test. While the test was running the test operators were doing other things related to the test, such as cutting and pasting screen shots of the test progress into MS Word, pasting data from previous tests into Excel for analysis and generally using the computer. At one point when there was a few Megs of data on the clipboard one of the menu items needed to be accessed and that caused the freeze. Then the freeze was long enough that the hardware gather overran the buffer. That crashed the software. The data acquisition system left the control loops and outputs in a less-than-lucky state and by the time the test operators had the system back up we had destroyed $90,000 of customer test hardware. Needless to say this has gotten a ton of attention from everyone, up to management at multiple companies.
My current fix is to clear the clipboard every cycle, but that really interrupts the work flow and means our report logs won't have much in them anymore. I'm looking into using user32.dll to determine which application has focus and possibly clearing the clipboard only if Labview has focus.
I'm definitely open to more suggestions on a work around for this. Thanks,
When data integrity is this important, I must maintain that you mitigate use of the clipboard and running other tasks with the computer as much as possible. Any other workaround can only add risk to compromising your data and hardware. However, your solution would definitely be beneficial in ensuring that a user doesn't unknowingly copy large amounts of data into memory. Still, it is my recommendation that you avoid performing other memory intensive tasks while running a DAQ system.
Well, doing Microsoft Word, Excel and what else on a computer that is used to run an important production test, is a very bad idea. There is no way that you can guarantee, that one of these applications is not causing some interruption to the currently running time critical task. Word and Excel and just about any other computer application can crash, lock up the computer or eat your breakfast while you are doing seemingly harmless things.
The issue with the clipboard in LabVIEW is indeed a problem that exists for a long time and I hope they fix it sometime, but the fact remains, that you should NEVER use a computer for other tasks while you run a test or other manufacturing related application on it, when a failure of that application can cost you more than a few pennies.
I definitely agree that running other applications while gathering data is a risk, but sometimes a risk worth running. Well designed software can make allowances for the effects of other programs and the Windows OS too. These are good precautions.
However, it's important to keep in mind that the problems were caused by the clipboard freeze in Labview, not by some other event such as Windows looking for printers or MS Word autosaving. That freeze is very nasty and the delay times are huge. It presents like a crash. I've been working with Labview for a while time (since long before event structures were in the code, yikes) and this is the first time I've come across this "known issue."
It's nasty enough that I'm going to be using my work arounds in many of my projects going forward:
Thanks again guys. This one is ugly.