LabVIEW 2009 slow editing

Ever since I switch from 8.6 to 2009 sp1, the same project has been very slow to edit. Yes it is large, but the machine is large. I have timed the how long I get the hour glass and how often, and the average delay is 22.5 seconds every 321 seconds. This is driving me nuts to wait that long every 5 minutes.
I have a quad core PC, so that should not be an issue. I’m sure some of you could find some improvements in the code, but the code is not that bad. I have read that they made changes to the compiler, but that should not effected an edit should it?
Thanks,
Doug
Solved!
Go to Solution.

Deborah,
Thanks for your reply. Yes I did a mass compile when I upgraded from 2009 to 2010sp1. The wait time during auto save went down from 20+ seconds to about 3 with the upgrade, so that helps a lot. I noticed a slight improvement when editing the main.vi outside of the project, but not by much. Attached is the VI Metrics if that sheds any light on this subject. I have noticed a long time ago that if I make a lot of changes it will slow up until I do a save. This always happened even on older version of LabVIEW.
I’m just trying to better understand what computer resources LabVIEW needs for better editing performance. I don’t see the CPU or memory usage going up, so I am curious of what is causing the slowdown. Or more to the point if there is something I can do to speed things up (like a faster hard drive, or some kind of setting). At boot up I have 52 processes running in the background, so that is not too bad. We have our business Norton antivirus software loaded.
Thanks,
Doug
Dell M6500 – Intel i7 quad core processor
8 GB Ram
ATI FirePro Graphics card
320GB hard drive 7200RPM
Windows 7 64-bit
Attachments:
VI Metrics.txt ‏16 KB

Similar Messages

Labview 2009 August edition installation in win7 64bit OS

Dear All,
I need to know In win7 64 bit OS, NI labview 2009 august edition and add on modules like RT and Sound and vibration installation will work or not ?
Can any one help me?
Regards,
Vasu

Here is a start to your question. Basically, many of the toolkits (FPGA for instance) are not support under LabVIEW64, so LabVIEW 32bit must be installed on your 64 bit O/S
Putnam
Certified LabVIEW Developer
Senior Test Engineer
Currently using LV 6.1-LabVIEW 2012, RT8.5
LabVIEW Champion

Labview 2009 Student Edition Vista x64 installation fail, no error messages though

I am trying to install a copy of the LabView 2009 student edition and everytime the installation initializes, the modules fail to install for every single module. There is also no error message.
I got a message that LabView may not be working correctly due to Windows Firewall, which I have disabled. That message referred me to ni.com/info, code expm69.
Let me know, I'm a little confused as to what's going on. Would it be due to a patch or what not?
Thanks!
Solved!
Go to Solution.

Hi imagineerme,
Regarding your installation issues, a possible cause may be that you don't have permissions on the computer that you are installing. Are you set as the administrator on this computer? Is this a school computer or your own?
It's also possible that LabVIEW may be installed on your computer already. To check this, go to Program Files/National Instruments to see what you already have installed.
If neither of these are the cause, can you please provide me with more information about your installation? Does the installer crash or just go straight to the finish screen? Does anything install at all? Thanks and best of luck,
Julianne K
Julianne K
Systems Engineer, Embedded Systems
Certified LabVIEW Architect, Certified LabVIEW Embedded Systems Developer
National Instruments

MathScript RT Module - LabVIEW 2009 Mac

Hello everyone,
I recently bought LabVIEW 2009 Student Edition and I am using it on Mac OS X (Leopard). The checklist that came with the software says it comes with MathScript RT Module (for Mac), but that I should contact NI in order to get this module (free). I looked online at ni.com and I only found the Windows version. Can someone PLEASE post it or send me the link where to get it? I would REALLY appreciate it. Thanks!!!
LabVIEW 2009 MathScript RT Module for Mac OS X.

Hi Argon,
You will have to contact NI directly to determine how you will get the module. Thanks.
Flash
National Instruments
Applications Engineer

Does USB-6008 student kit come with a LabVIEW 2009 textbook?

Hello.
I'm taking a LabVIEW class that requires the "LabVIEW 2009 Student Edition" textbook and software on DVD. I want to also get the USB-6008 Module, too.
Browsing the NI Academic Starter Kits, I came across the USB-6008 Student Kit, which says comes with the USB-6008 Module, LabVIEW Student Edition software, and SignalExpress LE. This Kit seems like the best package for me to purchase, but the website is not clear as to whether the textbook is included. Does anyone know if the book is included with the USB-6008 Student Kit?
Thanks,

Hi YTrunner,
Thank you for contacting National Instruments. I can confirmthat the 6008 starter kit does not come with the textbook. You would need to purchase these products separately.
Many thanks,
Andrew McLennan
Applications Engineer
National Instruments

Differences between LabVIEW Education Edition and LabVIEW 2009 + NXT Module

Recently saw the announcement regarding LabVIEW Education Edition.
From the information available at this time it's hard to tell the difference between this product and just adding the NXT module to standard LabVIEW 2009 if your only interest in LabVIEW is for NXT programming. Anymore details about this new product would be appreciated as well as info on how it's different from the alternative. Are there some unique VIs not present in the standard NXT module? Obviously the pricing is very different, but for a student the academic version of LabVIEW is actually lower cost than this new Education Edition.

Inh-
LabVIEW Education Edition (LVEE) includes the NXT Module and the API to interface with Vernier products. LVEE is geared towards middle school and high school classrooms to get students interested in math and science. It includes curriculum for teachers that may not be familiar with programming and LabVIEW in general to use the NXT bricks and the LabVIEW environment.
LabVIEW with the NXT module only has the NXT API and not the Vernier API. It will not include the course work and as extensive example programming useful for teaching.
For additional information on LVEE, please take a look at the Getting Started with LabVIEW Education Edition or go to ni.com and search for “labview education edition”.
Regards,
Mike S
NI AE

LabVIEW 2009 crashes at startup with the presence of a certain CRT version on the system

When installing our LabVIEW integration package on a system running
LabVIEW 2009 LabVIEW will crash at startup afterwards. Using 'dependency
walker' reveals, that 'nicont.dll' causes this crash because of a
side-by-side configuration problem. After some debugging I found out
that on this particular system installing a certain version of the
Microsoft CRT will stop LabVIEW from functioning. My fix now is to
recompile our code with a newer version of VS. I now ship a VS9 version
of the runtime and everything is working as expected.
However
I guess the real problem lies within the LabVIEW installer. I guess a
needed version of the CRT is not installed by LabVIEW. It still works
because due to some policy files on the machine it gots defaulted to a
compatible version at startup. However when I install the following 2
merge modules on the target system LabVIEW does no longer work:
Microsoft_VC80_CRT_x86.msm (file version inside: 8.0.50727.762)
policy_8_0_Microsoft_VC80_CRT_x86.msm (file version inside: 8.0.50727.4053)
Renaming
the *.policy file in the SxS dir on the target system gets LabVIEW back
to run, but of course other SW needing this file does not run then
I was using XP, 32 bit SP 3
I can provide additional information if needed. Is this a known problem? Is there a fixed version of LabVIEW already?
Message Edited by anotherStefan on 02-05-2010 05:44 AM

Sure! I tried to attach the installer causing the problem to this message.
However I failed miserably(BAD GATEWAY from the upstream server). Where can I upload the installer to or what do I need to do?
It will install some other stuff as well (A bunch of VIs, a DLL and an
OCX(this needs the CRT I have trouble with)and the CRT and MFC runtimes I
mentioned. An updated version of the installer can be obtain here(however it does no longer show the issue):
http://www.matrix-vision.com/functions/count.php?url=products/hardware/family/SC/mvBlueFOX/LabVIEW_a...
The only difference between the two packages is, that the OCX in the
attached file has been build using VS2005SP1 and in the package the link
points to I did use VS2008. Apart from that I changed the 2 merge
modules from Microsoft (CRT and MFC)

Migrating large project from DSC 7.1 to LabView 2009 Shared Variables ... What's the next step after recreating my variables?

I am in the process of migrating a large distributed (multi-workstation) automation system from the LabVIEW 7.11 DSCEngine on Windows XP to the LabVIEW 2009 Shared Variable Engine on Windows 7.
I have about 600 tags which represent data or IO states in a series of Opto22 instruments, accessible via their OptoOPCServer. There are another 150 memory tags which are used so the multiple workstations can trade requests and status information to coordinate motion and process sequencing. Only one workstation may be allowed to run the Opto22 server, because otherwise the Opto22 instruments are overwhelmed by the multiple communications requests; for simplicity, I'll refer to that workstation as the Opto22 gateway.
The LabVIEW 2009 migration tool was unable to properly migrate the Opto22 tags, but with some help from NI support (thank you, Jared!) and many days of pointing and clicking, I have successfully created a bound shared-variable library connecting to all the necessary data and IO. I've also created shared variables corresponding to the memory tags. All the variables have been deployed.
So far, so good. After much fighting with Windows 7 network location settings, I can open the Distributed System Manager on a second W7/LV2009 machine (I'll refer to it as the "remote" machine henceforth) and see the processes and all those variables on the Opto22 gateway workstation. I've also created a few variables on the remote workstation and confirmed that I can see them from the gateway workstation.
Now I need to be able to use (both read and write) the variables in VIs running on the remote workstation machine. (And by extension, on more remote workstations as I do the upgrade/migration).
I have succeeded in reading and writing them by creating a tag reader pointed at the URL for the process on the Opto22 gateway. I can see a way I could replace the old DSC tag reads and writes in my applications using this technique, but is this the right way to do this? Is this actually using the Shared Variable Engine, or is it actually using the DataSocket? I know for a fact that attempting to manipulate ~800 items via Datasocket will bog down the systems.
I had the impression that I should be able to create shared variables in my project on the remote workstation that link to those on the Opto22 gateway workstation. When, however, I try to browse to find the processes on that workstation, I get an error saying that isn't possible.
Am I on the right track with the tag reader? If not, is there some basic step I'm missing in trying to access the shared variables I created on the gateway workstation?
Any advice will be greatly appreciated.
Kevin
Kevin Roche
Advisory Engineer/Scientist
Spintronics and Magnetoelectronics group
IBM Research Almaden

I have found the answer to part of my question -- an relatively easy way to create a "remote" library of shared variables that connect to the master library on my gateway workstation.
Export the variables from the master library as a csv file and copy that to the remote machine.
Open the file on the remote machine (in excel or the spreadsheet app of your choice) and (for safety's sake) immediately save it with a name marking it as the remote version.
Find the network path column (it was "U" in my file).
replace the path for each variable (which will be either a long file path or a blank, depending on the kind of variable) with \\machine\'process name'\variable name
where machine is the name or ip address of the master (gateway) workstation (I used the ip address to make sure it uses my dedicated automation ethernet network rather than our building-wide network)
and process name is the name of the process with the deployed variables visible in the Distributed System Manager on the gateway machine.
NOTE the single quotes around the process name; they are required.
The variable name is in the first ("A") column, so in Excel, I could do this for line 2 with the formula =CONCATENATE("\\machine\'process name'\",A2)
Once the formula worked on line 2, I could copy it into all the other lines.
Save the CSV file.
Import the CSV into the remote library to create the variables.
Note: at this point, if you attempt to deploy the variables, it will fail. The aliases are not quite set properly yet.
Open the properties for the first imported variable.
There is probably an error message at the bottom saying the alias is invalid.
In the alias section, you'll see it is set to "Project Variable" with the network path from step 4.
Change the setting to "PSP URL" with the same path and the error message should disappear.
Close the properties box, save the library, and then export the variables to a new CSV file.
Open the new CSV file in Excel, and scroll sideways to the NetworkrojectBound field.
You'll notice it is False for the first variable, and true for the rest. Set the field FALSE for all lines in the spreadsheet.
Scroll sideways... you'll notice there are two new columns between NetworkrojectPath and Network:UseBinding
The first one is NetworkingleWriter; it should already be FALSE for all lines.
The second one is Network:URL. That needs to be set equal to the value for each line of NetworkrojectPath.
You can accomplish this with a formula like in step 4. In Excel it was =U2 for line 2, and then cut and paste into all lines below it.
There is a third new field, Path, which should already be set to the location of the variable library. You don't need to do anything with it.
Save the edited CSV file.
Go back to the remote library, and import variables from the just-edited remote library CSV file.
Once you have imported them and the Multiple Variable Editor opens, click on done.
You should now be able to deploy the remote variable library without error. (Make sure to open the Distributed System Manager and start the local variable engine. It took me a few failures before I realized I had to do that before attempting a deployment).
Voila! You now have a "remote" library of shared variables that references all the shared variables on the master machine, and which should be deployable on other machines with very little difficulty.
It actually took longer to write out the process here than to perform these steps once I figured it out.
Kevin Roche
Advisory Engineer/Scientist
Spintronics and Magnetoelectronics group
IBM Research Almaden

Labview 2009 32 bit not running on xp 64 bit

Hi all,
I tried to upgrade to LabVIEW 2009 from LabVIEW 8.6 on 64-bit windows XP machine. Following about a 2 hour removal of 8.6 and subsequent installation of LV 2009 it turns out that the device drivers are not compatible with a 64-bit machine. On launching LabVIEW 2009 (32-bit) an error box appears stating that it is corrupt or missing files and to correct this using control panel etc. I have tried this and still the same error occurs and LV refuses to start.
All the license files are correct and the compnents are activated.
Anyone know how to fix this? Or should I go back to 8.6 and cancel my upgrade subscription?
Secondly, I am using a firewire camera and was informed that Ni-IMAQ legacy are no longer supported and to go to ni.com/ifo and enter legacy1394 to see how to download drivers etc for this. I end up on a page that says "not authorized".
Any help gratefully appreciated.
Solved!
Go to Solution.

Leeser wrote:
I agree that XP64 and LV 2009 are not compatible as I installed LV 2009 on another 32-bit machine with no problems. I was just surprised as there were no problems or issues that I came across for 8. on XP64. Ah well, a uninstallation and reinstallation lies in wait for me on Monday morning!!
As an aside why call it LV 2009 instead of LV 8.7 or even LV9.0...sounds reminiscent of an operating system!!
Regards,
Leeser
LabVIEW 2009 is according to the internal version scheme actually equivalent to LabVIEW 9.0. Why they changed the naming? I guess marketing told them to do so. Why then? Well marketing has some funny ideas sometimes. I guess since THE software provider in this world has started to do this since about Windows 2000 someone must have thought it to be the best idea since sliced bread and decided to do it for LabVIEW too.
Another guess is that in about 2010 there would have been something like 9.1, and 10.0 would then come out in 2011 and that sounded somehow to someone like a bad scheme so they decided to change it now. But maybe it will be forgotten and everybody returns to the old versioning at the begin of next year when 9.0.1 will come out, which would then otherwise be LV 2009.1??? Or maybe LV2009 SP1?
It has already happened with LabVIEW 6i (iMacs, iPhones, iAnything), LabVIEW 7 Express and LabVIEW 8.20 (following 8.0.1 and marking the 20th anniversary of LabVIEW, and being internally LabVIEW 8.2). All some marketing fun or hysteria.
Rolf Kalbermatter
Message Edited by rolfk on 08-17-2009 11:08 AM
Rolf Kalbermatter
CIT Engineering Netherlands
a division of Test & Measurement Solutions

Enum in a Typedef Reverts to Default (LabVIEW 2009)

When I add additional items to a typedef'd enum, constants of that enum on some BD's revert back to the default zero index enum value. In the past (8.6.1 and previous), adding items to an enum in no way would ever change constants that were already dropped on a BD. Now, in LabVIEW 2009, when I add items, about 60-70% of the constants dropped on different block diagrams will be changed to default value.
This happens in a "large" enum (~400 elements) that spans about 3 dozen VI's between RT and HMI block diagrams (a total of about 300 instances). This is a mature project that has never had this problem with 8.2, 8.5, 8.6, or 8.6.1...
I cannot post an example, because in the process of stripping down the VI, the problem goes away. It is extremely repeatable in the context of the project, but I cannot repeat it on an individual VI basis.
The current workaround is to edit the typedef'd enum while all referencing VI's are in memory. If the VI's that use the typedef are in memory, they will always properly recompile and maintain the correct constant value. However, if the VI is not in memory, and the typedef is changed, the next time the VI is opened, when it recompiles it will change the constants back to the zero index default value of the enum in only about 60-70% of VI's. Unfortunately, we cannot yet find a common thread in the VI's that recompile wrong, and the ones that recompile correctly.
Has anyone ever seen this problem? Suggestions?
Best regards,
Jack
a.lia-user-name-link[href="/t5/user/viewprofilepage/user-id/88938"] {color: black;} a.lia-user-name-link[href="/t5/user/viewprofilepage/user-id/88938"]:after {content: '';} .jrd-sig {height: 80px; overflow: visible;} .jrd-sig-deploy {float:left; opacity:0.2;} .jrd-sig-img {float:right; opacity:0.2;} .jrd-sig-img:hover {opacity:0.8;} .jrd-sig-deploy:hover {opacity:0.8;}

We just realized a flaw in our "workaround", as partially pointed out by Ben (he was probably typing his response as we were confirming it here). If the constant is inside of a cluster on the BD, even if it is in memory, it will null out the enum inside of the constant. Therefore, the "workaround" is to rewrite the clustered enum constants from scratch (in other words, there's no workaround). Two of us spent a decent portion of the morning finally nailing this as the source of what we thought was an unrelated bug... and that's after spending a long day yesterday trying to find a fix. Yes, we feel Ben's angst of reverting back to previous SCC editions and manually editing dozens of VIs.
The severity of this bug is a showstopper for us. We cannot risk adding elements to an enum and consequently have referencing VIs changing their constants.
Force compiling a VI one at a time is not an option for us. I know this bug manifests itself even after a mass compile. So, is there a way to "mass force re-compile" that we could test?
a.lia-user-name-link[href="/t5/user/viewprofilepage/user-id/88938"] {color: black;} a.lia-user-name-link[href="/t5/user/viewprofilepage/user-id/88938"]:after {content: '';} .jrd-sig {height: 80px; overflow: visible;} .jrd-sig-deploy {float:left; opacity:0.2;} .jrd-sig-img {float:right; opacity:0.2;} .jrd-sig-img:hover {opacity:0.8;} .jrd-sig-deploy:hover {opacity:0.8;}

Cannot find older CAN-2.0 .vi's in labview 2009

Hi,
I'm trying to use a (rather old) Series 1 PCMCIA-CAN/2 card in Labview 2009.
I've installed latest NI-CAN driver that supports this old card (NI-CAN 2.0, I think), but I don't see any of the can.llb vi's in the functions palette. The CAN-2.0 documentation says it supports Labview versions "6.1 and later".
Will Labview 2009 support this driver? How do I get CAN-2.0 vi's to show up in the function palette?
Thanks,
Phil (labview newbie)
Message Edited by phil___ on 01-30-2010 03:09 PM
Message Edited by phil___ on 01-30-2010 03:10 PM
Solved!
Go to Solution.

I found the relevant .vi's in the "Labview 6.1/vi.lib" folder of the "National Instruments" directory.
The vi's I was looking for now show up in the addons section of the function pallette.
Thanks,
Phil

Issues about labview 2009 application builder

first of all, sorry for my poor English ~~~i am not quite sure about whether i could make myself clear for you guys.here it is:
SFX-ZIP archive is choosed as the file format for built-exe in labview 2009.when building any project into exe in labview 2009, you can always turn the suffix of the application file into zip. then use any compress-decompress software to open that file.shocked? right? yes, all the vis that used in your project are there. of course, you can decompress all the vis from the archive.although the block digram is removed during the building process, they still can be dragged into any vi and work perfectly.
this is so insecure both for the application and the source code.how about you?
Message Edited by hunt978 on 05-10-2010 04:16 AM

Double post

Font size on Windows 7 with LabVIEW 2009

Hello,
after installing labview 2009 on windows7, I have a problem with the font size of my old application written in 8.6.
the Application Font has seemed to default to another style under windows7 so I searched the forum for the default font under XP when I used lv 8.6. Tahoma 13pt seemed to the correct choice, however when i changed all default fonts to Tahoma 13pt it helped and they look very similar, but the Tahoma under windows7 is slightly longer that the original and it looks like there is some sort of font smoothing going on... perhaps windows is doing its "cleartype" thing by default and influencing its length (thou i thought this shouldnt be the case).
This small difference is causing havoc in my GUI as objects are being resized in a bad way.
Please see the screenshot for an example of my concerns
Another question on the side... is there a Font I can use that will keep the appearance and size over all OSs?
Any help would be appreciated...
Best Regards
Alex.
:. LV2010 SP1 ... W7 .:
Attachments:
Font Difference.png ‏3 KB

Actually this problem affect LabVIEW itself even while editing!
Many of NI's screens suffer from the same problem. Configuring events is one of the most obvious cases. Since teh edit events screen does not allow for resizing, there are some events that you can only guess what they are.
I tried reporting this but the AE wanted me to spoon feed screen shots and ....
I think what really irks me over this problem is that I purchased a laptop with the biggest screen available just to let me do LV and in the end LV can't handle the laptop.
Double -
Ben
Message Edited by Ben on 05-06-2010 10:13 AM
Ben Rayner
I am currently active on.. MainStream Preppers
Rayner's Ridge is under construction

LabVIEW 2009 Crash when save for previous

I'm having a problem when trying to save a VI in LabVIEW 2009 to a previous version of LabVIEW, in this case 8.2, but itseems to crash no matter what version I choose. I've narrowed the problem down to this:
If the vi contains an event structure I get the following error: Fatal Internal Error: "MemoryManager.cpp", line 547
If I remove the event structure it saves fine. I'll even get the error if I create a blank vi, and drop an empty event structure on the diagram. No controls, no other code.
Is this a known problem? Is this a problem with my copy of LV? Is there a workaround? Removing the event structure in this application is not an option.
Thanks
Rob
Message Edited by rgough on 09-30-2009 03:58 PM
Solved!
Go to Solution.

Hi sk_LabVIEW,
Currently there is no workaround, but fixes are being worked on. Sorry.
Flash
National Instruments
Applications Engineer

Why does LabVIEW 2009 revert to the old icon editor?

Hi,
I have noticed that sometimes when I am trying to edit the icon in LabVIEW 2009, I get the old style icon editor from LabVIEW 8.5 days instead of the more advanced new one with layers, gliphys, etc. Once the old style editor shows up, there doesn't seem to be a way to go back to the advanced editor. Has anyone seen this behaviour? I have version 8.5 of LabVIEW still installed, should I remove it? Do I need to restart my computer?
Thanks.
Bob

Here are some of the errors I see ...
Attachments:
ScreenShot057.png ‏18 KB
ScreenShot058.png ‏112 KB
ScreenShot059.png ‏125 KB

LabVIEW 2009 slow editing

Similar Messages

Maybe you are looking for