LabVIEW 2011 Block Diagram/Front Panel reacts slowly

[BMajor7]

It did not occur again!

=> =>

So, I guess saving the VI outside the project was indeed eliminating this problem.

I did this accidentally but Ben (the other) mentioned it. So, the hint for the solution was in his reply.

Thanks to all for your ideas and help.

Ben

[Ben]

Thanks for the feedback!

Ben (the other)

[apok]

lol....i get no respect? Rodney Dangerfield....

[Ben]

---

@apok wrote:

lol....i get no respect? Rodney Dangerfield....

---

I use the defer FP updates method in my applications as well and they do help with the performance of the graphic updates WHEN MY APPLICATION is running.

In the problem reported by Ben in this thread, the poor performance was at edit time.

Take care,

Ben

[BetterVIEW]

I have noticed a similar situation with a database "driver" VI that has over 70 individual states in the state machine.

Initially, I thought the problem was related to the predictable slow-down of an aging Windows PC. However, I just moved the file to a brand new PC running Win7 (64-bit), and I'm still seeing delays of 8 top 10 seconds(!) everytime I make an edit to the block diagram!  

The probelem seemed to get somewhat worse after I sorted the cases. (Specifically, I re-arranged order of the state machine cases using the "Rearrange Cases..." item accessed by right-clicking on the Case Selector bar. This was done so that the order of the state machine cases matched the order of the elements in an Enum used to select the next case in the execution queue.) I have sorted the cases 3 or 4 times, and the problem seemed to get worse each time -- although the size and complexity of the VI was also growing too, so this may also be a factor.

In any event, this is all quite frustrating, as our customer has made some substantial changes to the spec. I need to make hundreds of small edits to the various cases of this VI, so at 10 seconds per edit, this amounts to thousands of seconds! (Obviously, no customer is too keen on paying me to simply wait for the PC to update.)

Some other features of this VI:

- Several  (likely more than 100)  instances of many of the DB Connectivity toolkit library VIs spread between cases.

- 17 type defintions Clusters to define the various DB tables. (These are not large. The largest table cluster is less than 10 elements.)

- A single variant input (passed from the caller) is typecast to the appropriate table "type" in each case using these type def clusters.

Perhaps others with similar problems can find something in this list..

-- D.

[BMajor7]

Thought I had the solution but I am starting to have the problem again. Saving the VI outside of the project helped for some time. But it still happens. It happens on other machines, on Win 7 and XP on 64Bit and 32Bit. And it happens after reinstalling OS and LabVIEW (an "idea" from a NI application engineer).

Since the project is almost done, I do not care anymore. It is annoying but I got used to exit LabVIEW and restart it several times a day. The workaround I have found is not to use LabVIEW anymore.

Hey, and it really helped

[Ray.R]

Putnam & I have experienced the same thing using LabVIEW 2010 SP1.

Quite annoying.  The other symptom is that after it recovers, it switches to another open VI's front panel.  Although we were working on the block diagram.

[Jed394]

I'll throw in my 2 cents b/c i had a wierd bug where things started behaving slowly.  This was a gui intensive vi and all my front panels were behaving slowly even if i built and exe or moved it to a faster computer with a better GPU.  

 If you right click on the bottom right corner of a vi front panel, select properties and change the background from original to none.  This solved a strange UI issue i was having.  you might give it a shot, its probably not yoru problem but it helped me.  

[BetterVIEW]

Another Clue:

In the application I am building, I was bundling a few (about 15 or so) "Type Def" clusters into a single "super-cluster". This super-cluster was  loaded into a shift register in an Initialize case. That way, I could reference any one of the type def clusters from any state in the state machine without wiring 15 shift registers through my case structure. (If you are familiar with the JKI-State Machine approach to capturing a number of clusters in a shift register, then you know what I'm taking about. Although, I should clarify that I'm not using the JKI-SM framework for this VI.)

In any event, when the bundling was happening inside the Initialize case, I was experiencing the Development System slow downs reported in this thread. Something as simple as moving a wire was causing a the cursor to go to the hourglass for 12-15 seconds(!)

However, I was able to overcome the editing difficulties by simply moving the bundling operation outside of the SM (state machine) loop. In other words, I am now building the super-cluster (composed of 15 type def clusters) on the left side of the diagram, and wiring it into the shift register. The cluster is constructed prior to entering the SM loop, so it now it no longer gets bundled in the Inititialize case. 

It isn't clear what is happening under the hood, but it almost appears that the type def instances in each of the SM cases need to be mapped back to the original type defs in the initialization case. In any event, moving the type defs and the bundling operation outside the loop appears to have solved the problem. The response of the LabVIEW editor is now as expected.

-- D.