LabVIEW
labview lags while programming when finnaly totally freezes
Solved!
I had to remove the agilent stuff, becasue I don't have the drivers, but after that, the code complexity reads as 3.7.
Have you tried removing the stack of decorations on the last tab (two flat light grey rectangle decorations partially overlapping a big image, all over a "lowered rouded box")?
I would also use bundle by name (see image) to change a single cluster element. Much less code! Of course some of your cluster have a large collection of elements with identical name, so that can really lead to confusions. I would recommend unique names. In any case, you could probably combine most of the similar events into one.
Lynn: I wasn't sure of any greedy loops, because they have DAQ stuff that could provide some timing. Yes, the timeout in the upper loop is probably too short. None of this should have any bearing on the edit time performance, which was the original complaint.
I would also recommend to simplify the data structures. For example in one subVI, you unbundle by name, rebudle into a new cluster, the immediately convert ot to an array (left). Why not build the array directly (right)?
Try to disable debugging for your subVIs.
@altenbach wrote:
I had to remove the agilent stuff, becasue I don't have the drivers, but after that, the code complexity reads as 3.7.
Have you tried removing the stack of decorations on the last tab (two flat light grey rectangle decorations partially overlapping a big image, all over a "lowered rouded box")?
I would also use bundle by name (see image) to change a single cluster element. Much less code! Of course some of your cluster have a large collection of elements with identical name, so that can really lead to confusions. I would recommend unique names. In any case, you could probably combine most of the similar events into one.
Lynn: I wasn't sure of any greedy loops, because they have DAQ stuff that could provide some timing. Yes, the timeout in the upper loop is probably too short. None of this should have any bearing on the edit time performance, which was the original complaint.
- The lagging still occours when no decorations are present.
- That's true that I've quite a lot of identical names, that's the cause of copying the clusters instead of copying the controls, I've not changed them because of the lagging, even programming is hellish lets not talk about changing about 200 names....
And thanks for the suggestiong about working with the clusters!! that's really helpful!
But what i do notise is that you all look at the code itself. and I have a question about that because i can understand that decoration or loads of controls can make labview lag after a sertain point but I noticed labview lagging for the first time when I had the frontpage done for about 30% but I had to continue working so all the subVI's etc. have been added laiter, after the lagging started. maybe I've not been clear with explaining that before.
@altenbach wrote:
I would also recommend to simplify the data structures. For example in one subVI, you unbundle by name, rebudle into a new cluster, the immediately convert ot to an array (left). Why not build the array directly (right)?
Try to disable debugging for your subVIs.
Yes I know that could be done better, what i've done there is solving a order problem but i've already found the right way to do that. so that what you've posted will be corrected when my lagging problem is solved.
