LV "Not responding"

[Cat]

Hi all,

I recently upgraded to LV 8.5.1, pretty much straight from 7.1. Especially right after startup it seemed to take longer to do things like access items on the menu bar, move a vi fp/bd, make a wire appear -- simple stuff. This often also happened when I opened up a new vi. It looks like LV hangs, I click on a window, and get a "Not responding" message in the title bar. This lasts 5 or 10 seconds, then everything is fine. For awhile.

A cow-orker recently brought some of his LV code to me to look at. When it was running, he commented on how much slower it seemed to run on my computer, especially right after we pulled up the vi. He ran the same code on his laptop, and sure enough, the code ran faster.

I started paying attention to what was going on when I started up LV and then subsequent vis. It looks like, in addition to a whole lot of disk thrashing, my network gets accessed every time I open up a new vi. So I pulled the network cable out of my computer, and sure enough, everything runs fine; no hang-ups.

I'm guessing LV is trying to do some sort of network access. My lab intranet is not connected to the Outside World, so this may be problematic. If this is the problem, is there some way to disable whatever network access LV is doing?

Cat

[Francois Normandin]

The simplest I see would be to instruct your firewall to block outbound access to LabVIEW.exe. (but that's rather harsh, considering you might need that connection sometime in the future)

There could be an LabVIEW.ini key or NI registry edit that would do it, but that I am not able to help .

[Neville D]

Are you sure you have activated your version of LabVIEW?

Have you mass compiled your application to update all your VI's to 8.5.1?

I have experienced no slowdowns in my applications which typically have about a 1000 VI's since LV 7.x onwards (I am at 8.5.1 currently)

Neville.

[Cat]

I'm harsh. :-) I've already disabled labview.exe access since my development laptop only runs in the lab (or under the Deep Blue Sea). It seems the problem is that LV is still trying to get out, anyway, so I'm guessing you're right; there is some ini setting or something I need to turn off.

QUOTE (Neville D @ Jul 14 2008, 05:57 PM)

Are you sure you have activated your version of LabVIEW?

Have you mass compiled your application to update all your VI's to 8.5.1?

I'm definitely activated. LV is one of the few software packages I'm anal-retentive about licensing and activating.

This slow-down happens on both old mass compiled code and brand new vis. And whether I've got a couple vis up or my 1800+ vi monster project loaded.

For the moment I'm just running with my network cable unplugged. But that's obviously not a long-term solution.

[LAVA 1.0 Content]

QUOTE (Cat @ Jul 15 2008, 07:27 AM)

I'm harsh. :-) I've already disabled labview.exe access since my development laptop only runs in the lab (or under the Deep Blue Sea). It seems the problem is that LV is still trying to get out, anyway, so I'm guessing you're right; there is some ini setting or something I need to turn off.

I'm definitely activated. LV is one of the few software packages I'm anal-retentive about licensing and activating.

This slow-down happens on both old mass compiled code and brand new vis. And whether I've got a couple vis up or my 1800+ vi monster project loaded.

For the moment I'm just running with my network cable unplugged. But that's obviously not a long-term solution.

Does this happen an plain vanilla VIs as well?

I seem to remeber reading about LV trying to actively refresh VISA and DAQmx controls with valid selections, so it goes out and tries to find all networked and hardware widgets.

I don't remeber if it was shutting down "automatically refresh" in MAX and/or an ini token.

Well that's all I can offer.

Ben

[TG]

QUOTE (Cat @ Jul 14 2008, 08:48 PM)

Hi all,

I recently upgraded to LV 8.5.1, pretty much straight from 7.1. Especially right after startup it seemed to take longer to do things like access items on the menu bar, move a vi fp/bd, make a wire appear -- simple stuff. This often also happened when I opened up a new vi. It looks like LV hangs, I click on a window, and get a "Not responding" message in the title bar. This lasts 5 or 10 seconds, then everything is fine. For awhile.

Cat

Same thing here. I hope you find the ultimate cause.

I been just living with it since I have no clue how to find something that would cause LV to report "Not responding"

It does seem to settle down after awhile. (my guess) . I always thought it was because of the relatively large number of VI's in the project but after reading some of the replies maybe not.

PS I am using 8.2.1 on this project.

[Cat]

Hopefully the cross-posting police don't get me. After not getting very far here, and still being plagued by this issue, I posted this Q to the NI forum. I got help, but all of it was a dead-end. THEN...

-----

I got a new laptop in yesterday and loaded LV on it (isn't that what everyone does as soon as they get a new computer?) Just for grins, before I loaded any of my source code on it I did some tests to see if LV would hang.

It worked just fine.

I've spent the morning incrementally adding my source code and various settings files I've tweaked over the years. It took awhile, but I finally found the culprit: buried in my 1200+ vi user.lib was a link to a vi that no longer existed. I took that one link out and LV no longer hangs after startup.

Why disconnecting from the network changes the behavior, I can't say -- maybe LV is trying to search the web for the missing vi (even tho it pointed to my c: drive). But whatever, it's all working fine, now.

-----

Since there were a few of you out there with this problem, too, I thought I'd post my solution here in hopes it would help.

Cat

[ooth]

Cat,

Cat,

Thank you for posting the solution you found. I've been having the same problem and now I know what to look for. I just have to go through all my VIs in user.lib and see which one is the problem one.

[Aristos Queue]

Do you have items in your palette that are located on a network drive? The palettes for LV get loaded in the background and palettes on a network drive yield exactly the behavior you're seeing.

You can change the load options for the palettes in Tools>>Options>>Palettes to remove this effect.