06-28-2012 08:07 AM
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
06-28-2012 08:21 AM
Thanks for the feedback!
Ben (the other)
06-28-2012 08:24 AM
lol....i get no respect? Rodney Dangerfield....
06-28-2012 08:31 AM
@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
09-18-2012 01:41 PM
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.
09-19-2012 06:44 AM
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