05-21-2014 08:13 AM
Hi Community,
Since yesterday LabVIEW 2013 SP1 started behaving somewhat strange. While wiring the block diagram the cursor occasionally turns into the "busy" symbol for 0,5 to 1 second (same as you get from running "Set Busy.vi"). After this I can resume all the other actions.
Although this isn't a big issue it gets annoying quite fast.
In order to see what could be wrong I ran process explorer and got the following CPU graph.
*Note: The CPU spikes to only 25%, this is due to the fact that I have a quad-core cpu in my computer. Thus 25% means 100% on a single CPU.
As you can see every time I try to wire some elements a spike in the CPU usage appears at the same time as the "busy" indicator shows.
Do you have any suggestions what I can try to fix this?
Tonight I'll try a repair installation of LabVIEW but other suggestions are welcome.
05-21-2014 08:38 AM
How busy and big is your diagram? Do you have the navigation window open while doing this?
I find that with big diagrams, having the navigation window open means it takes much longer to scroll around. It is reasonable fast when the nav window is closed. I have not noticed CPU jumps. But it might explain it in your case.
05-22-2014 07:19 AM
My diagram is quite small and the naviagation window is closed.
At the moment it seems that a reboot fixed my problem for now, however suggestions what could be causing this are still welcome.
05-22-2014 08:14 AM
A recient thread also noted some unexpected CPU performance. If you have some large data structures you might try lowering the max undo steps setting (default is 99 you could probably reduce that without a lot of problems) the undo steps cost some memory as copies of stuff need to be around to "Undo" untill the vi leaves memory.
05-22-2014 08:20 AM
That one I'm gona try.
However it could be that the CPU probems are also related to the fact that I have a .net control on the front panel.
I recently produced some .net related LabVIEW crashes. (logs are transmitted to NI) and now the busy indicator is back.
05-22-2014 08:54 AM
Copies of that .NET control could cause some performance issues. Out of random curiosity, what is the .NET assembly?
05-22-2014 09:14 AM
Well I just changed the number of undo steps to 40 but I haven't done any wiring yet.
The assembly is System.Windows.Forms.DataGridView 4.0.0.0 (the only way I can create a table with comboboxes and checkboxes but that is a different discussion).