Why does it take so long for LV to respond after dropping a VI?

[Grampa_of_Oliva_n_Eden]

I hve to update my previous staements about LV 2010 seems OK.

Friday, I was on-site edittting someone elses code. While dropping ms tick counts in the 30 or so frames of a flat sequence I was experiencing crashes regularly. It took about 7 crashes to get teh changes made.

After seeing it for myself, I called the inside sales rep and got the process rolling so the customer can use LV 2009 since he does not need anything new from LV 2010 and he has to get his code finsihed.

So with large diagrams, LV 2010 is a real pain.

Ben

[george seifert]

Yes, that's exactly what I'm seeing. For me though it happens regardless of VI complexity, though they always reside in a very complex project. It's becoming very frustrating.

That's what I'm seeing too except the delay can be more like 5 to 10 seconds.

I don't see it all the time - even in the same VI / Project. I don't know what' s different when it works. It doesn't seem to be related to how loaded down the system is. It may have something to do with how long I've been editing in a given project, but I can't be sure yet.

George

[Ton Plomp]

I don't know what all you guys are talking about. All of this feels like superstition. Don't walk under a ladder or else you get bad luck. Gimme a break.

Regarding the SCC delay, it is there, LabVIEW is requesting the status of each VI individually, and then sending a burst with all the VIs at once, if you have a slow/bad design of SCC interactions this is noticeable.

Ton