Jump to content

LabVIEW Startup Error


Recommended Posts

So here I am waiting for LabVIEW to load and figured I'd take the time to toss up a post about something that I see on a daily basis. Attached is a picture of an extremely common LabVIEW error that tends to pop just about everytime i attempt to load LabVIEW by opening a VI directly. This error is repeatable in the sense that it happens about 9 times out of 10 when i try it. I'm sure that others have seen this error before (or at least I'm hoping), and I was wondering if anyone knows why it happens and/or how to keep it from happening. My best guess so far is that it has something to do with the length of time it takes LabVIEW to load. Maybe something along the lines of windows issue'ing a timeout warning while trying to open your file because the application attempting to load it is taking too long? I guess I should also note that the file does load, and that you just click the OK button on the error box to make it go away.

This error comes up as a result of opening a VI, when LabVIEW is not loaded into memory yet.

I'm curious to hear if others have encountered this, and what they have done about it (if anything).

Thanks,

Dave

post-4149-1142862173.jpg?width=400

Link to comment

Hi Dave, you're not alone...

Occasionally I've noticed the same behaviour on my Win2K-PC running LV6.1,

especially when another process in the background was busy and causing a slower LV-startup,

or opening several vi's at the same time.

I'm also curious what others have to say about this...

Link to comment
Hi Dave, you're not alone...

Occasionally I've noticed the same behaviour on my Win2K-PC running LV6.1,

especially when another process in the background was busy and causing a slower LV-startup,

or opening several vi's at the same time.

I'm also curious what others have to say about this...

Hello,

I've seen many errors in Labview. But this one is new to me.

See you

Ulrich

Link to comment

I often saw this error with my old computer. Since I got a faster computer from my admin this error disappeared.

It seem that the loading procedure of the LV-environment takes too long, so the explorer don't get sort of a "I-got-the-file-you-gave-to-me"-event fast enough and reports a timeout error to the user.

It is just something annoying, never seen that it affects your vi's.

Didier

Link to comment
I often saw this error with my old computer. Since I got a faster computer from my admin this error disappeared.

Yep - it's not a LabVIEW error per se, it's that you've tried to load a file from explorer (double clicked on a VI, project, etc), and Windows has started to launch LabVIEW to handle the file (you'll notice that your explorer window is still locked). Windows waits for LabVIEW to load to amek sure everything happened smoothly, but after a while it gives up with a couldn't-do-it message (LabVIEW continues to load in the background). That's why a faster PC "fixes" the problem - it just means that LabVIEW's got a better chance to load before Windows gives up on it. Another way to avoid seeing this error is launch LabVIEW first and then open your VI from the File menu.

Of course, the other way to get around it is to make LabVIEW load faster, but that's another story ;)

Link to comment

That is a timeout with Windows Explorer issue. When you double click on a VI, Explorer attemps to send a DDE message to the application (LabVIEW). When the attemp fails (it does when the app is not running), it starts the application and retries the DDE message. The above message is issued when the second DDE message fails too. It happens when LabVIEW takes too long to load and enable its DDE server. That error has no consequence since eventually LabVIEW will finish loading and open the VI.

You could eventually avoid this error by telling Explorer not to use DDE and open VIs with command line only (Explorer>Tools>Folder Options>File type). Since LabVIEW re-register by default its files associations, you also have to set RegisterExtensions=False in the labview.ini file to avoid re-registering with DDE. That has to be done for all LabVIEW file types...

Link to comment

Thanks to all for your responses. I'm glad that I'm not the only one that has seen this message before. I see i was pretty close to the guessing what the issue was, thanks for the further explanation about the DDE and when the timeout occurs! I've seen this message on nearly all the PC's that we run around this department, so I'm a little curious as to what type of machine those of you are running that don't encounter this error. The system I booted up this morning (which is where the message came from) is a PXI-8187 embedded controller running at 2.5 GHz with 1GB of Ram. I also see the error on my Desktop computer which is running at 2.8 GHz wit 512 MB of Ram (time for a ram upgrade... LabVIEW8 isnt very appreciative of 512 MB).

Lets hear what some basic spec's are on the pc's your able to run that don't encounter this error!

Thanks again,

Dave Graybeal

Link to comment
Of course, the other way to get around it is to make LabVIEW load faster, but that's another story ;)

youpp :)

on the last roadshow, I attended, there was one of the core LV developers, showing us a lot of "yet undocumented features" (that was nice ...) unluckily the PXI crashed, and he had to reboot and to restart LabVIEW

after minutes, and a red face he smumbles: "it seems, that there is every toolkit we ever shipped installed on this machine" ;)

but to apologize this. I don't think its originally a problem of LabVIEW. There is much code which has to be loaded. The new PC hardware is that quick, that it depens on the HDD to push all that data into the RAM. If you have once started it, closed it and started it again, LV is ready in seconds. So it's up to the HDD manufacturers to fix the gap between the theoretically availiable transfer-rate (150mB/s with SATA, I guess?) and the real transfer rate ...

OK, you can buy a ultra fast SCSI HDD for your workstation, but who wants a jet engine under his desktop? ;)

Link to comment
hmmm ... I use LV 7.1 / 8.0 on my laptop allmost every day (I have RT + PDA Module installed). Ok, it's not super fast, but it's ok ...

My personal laptop is a 3GHz P4 with 1Gb of RAM - unfortunately my wife uses that one for checking her mail, whereas my work-provided one is a 1.3Ghz M with 512Mb of RAM - there's a HUUUUUUUUGGGGGGEEEEEE difference between them :(

Link to comment
My personal laptop is a 3GHz P4 with 1Gb of RAM - unfortunately my wife uses that one for checking her mail, whereas my work-provided one is a 1.3Ghz M with 512Mb of RAM - there's a HUUUUUUUUGGGGGGEEEEEE difference between them :(

hmm, maybe you should try to get your wife under better control ;)

mine uses an old iBook G3 for Web/mail/etc ... :D

Link to comment
Lets hear what some basic spec's are on the pc's your able to run that don't encounter this error!

I have a 3GHz, 512MB computer at work. As i2dx stated, it mainly depends on your HD and on the "crap" that is on the HD. When my old computer (2GHz) was new (about 1,5 years ago) I could load the vi's by double-click on explorer without getting the error. After about 1 year it suddenly appeared. Also the load time of the computer was increasing continously.

At home I have a 1.2GHz Athlon and get this error seldom.

If you suddenly get this error, treat it as: clean up your computer and make a >format c:< :P

Link to comment
If you suddenly get this error, treat it as: clean up your computer and make a >format c:< :P

didierj,

YES!!! I've DONE this step on many a work computer from time to time, followed by the obligatory (at least in my case) "reinstall Windows Operating system". I want to do that at home, but I unfortunately bought a HP PC a couple years back without the original Windows software disk (just a recovery partition and disks), and with XP Home, and if I reinstal I'm afraid I'm going to have all the $#!+ that HP shipped with the thing. I've been looking for the justification to pay for the XP Pro upgrade so I could start fresh, but haven't decided to spend that money at home (yet).

As far as I can tell, a fresh format and reinstallation is the only way to gain back all the previous performance. Windows does not age well, I'm afraid.

-Pete Liiva

Link to comment

Unfortunately both the pc's that I typically work on are part of a larger corporate scheme. Even with a re-install of our corporate version of windows xp (and all the other software and such they toss in with it) I'm afraid I won't see much improvement. Both my pc's are a fairly new Windows XP install (around 2 or 3 months) so I think I'm pretty well stuck with the performance that I'm seeing ( which isn't really all that bad minus the annoyance of having to click ok on a warning box when i forget to open labview first).

Three Cheers for Corporate Control!!!

Link to comment
Thanks to all for your responses. I'm glad that I'm not the only one that has seen this message before. I see i was pretty close to the guessing what the issue was, thanks for the further explanation about the DDE and when the timeout occurs! I've seen this message on nearly all the PC's that we run around this department, so I'm a little curious as to what type of machine those of you are running that don't encounter this error. The system I booted up this morning (which is where the message came from) is a PXI-8187 embedded controller running at 2.5 GHz with 1GB of Ram. I also see the error on my Desktop computer which is running at 2.8 GHz wit 512 MB of Ram (time for a ram upgrade... LabVIEW8 isnt very appreciative of 512 MB).

Lets hear what some basic spec's are on the pc's your able to run that don't encounter this error!

Thanks again,

Dave Graybeal

As has been already mentioned in some ways, Toolkits installed (especially those that add a nice icon to the startup splash screen such as DSC, RT/FPGA, or IMAQ will cause LabVIEW to load additional VIs in the background that take up time too. So a clean LabVIEW is quite a bit faster in starting up than one that is loaded with every Toolkit there is.

And a dirty Windows system partition certainly makes a huge difference. LabVIEw depends directly or indirectly on a lot of system libraries and they all have to be loaded and mapped into the process space of LabVIEW before LabVIEW can start to even initialize itself. A clean Windows installation will always startup processes significantly faster than one that has been loaded with 100ds of small little shareware programs, games and other little gadgets. Not to mention of all those little programs that show up in the status bar in some form or the other.

A new installation of Windows is in general necessary about once a year unless you use your computer exclusively for one specific task and are not installing and uninstalling all kind of software frequently.

Rolf Kalbermatter

Link to comment

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.

Guest
Reply to this topic...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.

×
×
  • Create New...

Important Information

By using this site, you agree to our Terms of Use.