LabVIEW

cancel
Showing results for 
Search instead for 
Did you mean: 

LabVIEW 2011 Block Diagram/Front Panel reacts slowly

Solved!
Go to solution

It did not occur again!

Smiley Indifferent => Smiley Happy => Smiley Very Happy

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

0 Kudos
Message 21 of 29
(1,333 Views)

Thanks for the feedback!

 

Ben (the other)

Retired Senior Automation Systems Architect with Data Science Automation LabVIEW Champion Knight of NI and Prepper LinkedIn Profile YouTube Channel
0 Kudos
Message 22 of 29
(1,328 Views)

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

0 Kudos
Message 23 of 29
(1,326 Views)

@apok wrote:

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


 

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

 

Retired Senior Automation Systems Architect with Data Science Automation LabVIEW Champion Knight of NI and Prepper LinkedIn Profile YouTube Channel
0 Kudos
Message 24 of 29
(1,324 Views)

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.

 

0 Kudos
Message 25 of 29
(1,266 Views)

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 helpedSmiley Very Happy

0 Kudos
Message 26 of 29
(1,252 Views)