03-13-2013 12:44 PM - edited 03-13-2013 12:51 PM
[EDIT: Excuse the sanitation]
Now that is Odd...
The only thing I can think of is that yesterday I opened a vi from windows explorer after launching LabVIEW from my taskbar shortcut but before the welcome screen appeared.
One other oddity: I left the example "MT DQPSK (pi over 4) Transceiver.vi" running overnight and had one of my 8 cores 100% in use by LabVIEW when I came in this morning. Pressing "Stop" it took about a minute to stop the example but the core usage dropped from 100% to 0 as soon as the vi did stop.
Exiting both instances and restarting LabVIEW did not produce a warning. AND my Example finder "most recient" folder is empty!!! How can THAT happen? I did open MT DQPSK (pi over 4) Transceiver.vi from the "most recient" folder yesterday- its a nice convienience feature
03-13-2013 12:57 PM
I get two welcome screens all the time due to my impatience (try to open a VI while LabVIEW is loading). I'm not going to comment on the rest of your problems.
03-13-2013 01:34 PM
@crossrulz wrote:
... I'm not going to comment on the rest of your problems.
Much appreciated This thread is probably not the best place to bring up hair loss, typing skill gaps, or phychological disorders!
03-13-2013 02:00 PM
Though, thinking about this a little more all of your problems except for the example using 100% of a core (haven't looked at it yet) could easily stem from having multiple executions of LabVIEW going. Who knows, that other problem could also stem from having two executions trying to use the same TCP address or something weird like that. Again, I haven't looked at the example to see what it is trying to do.
Anyways, the moral of the story is patience is a virtue.
03-13-2013 02:08 PM
You should probably make sure you don't have the AllowMultipleInstances=true key in your INI file.
03-13-2013 04:30 PM
@tst wrote:
You should probably make sure you don't have the AllowMultipleInstances=true key in your INI file.
Thanks I hadn't checked that- but no, no AllowMultipleInstances key exists.
03-14-2013 12:25 AM
The 100% CPU behavior is unfortunately a known issue with LabVIEW 2012. If you leave LabVIEW idle for a long period of time (overnight for example), it will sometimes start using 100% of one core. I believe it is CAR 356586 which is fixed in LabVIEW 2012 SP1.
Jeff Peacock
Product Support Engineer | LabVIEW R&D | National Instruments
03-14-2013 04:00 AM
Jeff-P I'm glad to hear the core-burner bug has been found! I know that finding the exact way to reproduce that nasty beast had to be a challenge - I still haven't found a way to force it to happen but I can now stop trying
Tim appears to have seen the multiple welcome screens too, and under the same conditions I described. That unexpected behavior could probably be added to the "fair game" list for the next bug hunting season.
I still can't figure out how my example finder "Most Recient" folder could loose its contents. But, I doubt anyone familliar enough with LabVIEW to know the example finder has a most recient folder depends on that feature. Still, that might be a side effect of some other shutdown feature issues that affect more important persistant settings
03-14-2013 08:50 AM
Jeff·Þ·Bohrer wrote:I still can't figure out how my example finder "Most Recient" folder could loose its contents. But, I doubt anyone familliar enough with LabVIEW to know the example finder has a most recient folder depends on that feature. Still, that might be a side effect of some other shutdown feature issues that affect more important persistant settings
My guess here is that the last session of LabVIEW you opened is not the one that you opened the example in and it therefore overwrote the ini token.
03-14-2013 05:54 PM - edited 03-14-2013 05:57 PM
@crossrulz wrote:
Jeff·Þ·Bohrer wrote:I still can't figure out how my example finder "Most Recient" folder could loose its contents. But, I doubt anyone familliar enough with LabVIEW to know the example finder has a most recient folder depends on that feature. Still, that might be a side effect of some other shutdown feature issues that affect more important persistant settingsMy guess here is that the last session of LabVIEW you opened is not the one that you opened the example in and it therefore overwrote the ini token.
More likely the last LabVIEW app instance I closed wasn't privvy to the persistant setting. Methinks patience is less of a virtue and more like a "workaround for a feature" in this case.