Convert VIs LabVIEW 2012 to LabVIEW 2009

Hi all,
Need help to convert VIs attached below (LabVIEW 2012) to LabVIEW 2009.
Thank you very much
Attachments:
EMG Analysis.vi ‏1670 KB

You didn't enclude the sub.vis and these issues are usually addressed on the version conversion board (see the floating link at the top on the board) but here is your vi. Broken since it is missing depanancies
Jeff
Attachments:
EMG Analysis.vi ‏842 KB

Similar Messages

Convert elements using DAQCard-6024E to USB-6221using LabVIEW 2009

I just received an old project, the VI was mainly designed using DAQCard-6024E. Since we'd upgrade the equipment, and the DAQCard-6024E is no long used. However, they want to keep the similar front panel. I am trying to convert the pull-down menu that I can use with USB-6221 with Windows 7, but I don't know how. Can anyone help?
Windows 7, NI USB-6221, LabVIEW 2009 sp1
Solved!
Go to Solution.
Attachments:
test_1.vi ‏45 KB

Hi smoothengine007,
You should be able to use this document's Digital Output section to see how to modify your VI:
Transition from Traditional NI-DAQ to NI-DAQmx in LabVIEW
It looks like the rest of your code can stay intact if you just replace your Traditional DAQ VIs with DAQmx VIs.
Regards,
Message Edited by Dustin D on 02-23-2010 11:59 AM
Dustin D

Error in ni visa control out for usb in labview 2009

Hi,
I am using labview 2009 in which i have made a vi which communicates with a pic controller through USB interface.
the vi is working fine in labview 8.6. I tried it in two PCs. but when i run that vi in a PC with labview 2009 then the VISA CONTROL OUT.vi gives error "0xBFFF003E : Could not perform operation because of i o error.". while the control in.vi works fine in both the labview versions and any other PC that i tried.
I have run the application in total of 4 PCs with same set of cards/interfaces. two of them having labview 8.6 are running fine and giving no error but other two with labview 2009 are giving error.
and it doesn't stop here.... i searched in the vi and did some experiment and found that when i give Request value input to control out.vi as "0x36 "(as required by my PIC program) then it is giving error but when i give other value such as " 0x35 or 34 or 55"(used for other purpose) then it is not giving error.
Can it be a PIC programming problem? (i dont think so as everything is fine in other PC with LV 8.6)
I have already explored the ni forum for this error solution but could not find helpful.
Can anyone solve my problem?

I installed labview 8.6 in that machine and made a small program with only 3 vis (visa open session, visa close session and visa usb control out.vi) which is working in LV 8.6 platform.
Sorry the above statement is not correct actually.
When i run the program in LV 8.6 it giving that same error but this time it is not displayed as pop up window. so i could not judge that error was still there.

Convert code from LabVIEW 2009 to LabVIEW 8.6

Hi Everyone,
Could a kind person with LabVIEW 2009 please save the attached code in LabVIEW 8.6.
The code is of the Creating an Office 2007-like Ribbon in LabVIEW community page.
It would be very helpful!
PS. Will reward kudos.
Kind Regards
James Hillman
Applications Engineer 2008 to 2009 National Instruments UK & Ireland
Loughborough University UK - 2006 to 2011
Remember Kudos those who help!
Solved!
Go to Solution.
Attachments:
LabVIEW Ribbon.zip ‏306 KB

Any problems let me know and I will look at again
David
www.controlsoftwaresolutions.com
Attachments:
New Folder (2).zip ‏108 KB

A source distribution created in 32-bit LabView 2009 says that VIs aren't executable when opened in 64-bit LabView 2009. How do I run the main VIs?

A source distribution was made for a VI using 32-bit LabView 2009. The distribution was verified to work on another machine that ran 32-bit LabView 2009. However, when opened on a 64-bit LabView 2009, the VI was broken as indicated by the attached error message. How do I make the VI executable?
Solved!
Go to Solution.
Attachments:
source dist error.JPG ‏70 KB

Seems you have a problem with the installation of the Advanced Analysis Library (AAL) or the Intel Math Kernel Library that is used by the AAL on that 64 bit machine. Can't say for sure if these are already supported on 64 bit LabVIEW. At least a repair installation of LabVIEW seems to be in place.
The other error is from the HSD component not working. Again I can't say if this should even work on 64 bit LabVIEW. If it should a repair installation should be most probably done.
Rolf Kalbermatter
CIT Engineering Netherlands
a division of Test & Measurement Solutions

Convert labview 5 vo to labview 2009

Hi,
I want to use a labview 5.0 vi file in labview 2009. Is there a way to do this? The file is attached.
Thanks.
Solved!
Go to Solution.
Attachments:
IV4155A.llb ‏1128 KB

I have posted a request on the appropriate thread.
Thanks,
Sushobhan

Need to convert to labview 11 from labview 12

hello
I need to convert the following Labview 12 VIs to Labview 11.
thank you in advance
Attachments:
QAM Demodulation.vi ‏30 KB
QAM Modulation.vi ‏30 KB
rx QAM.vi ‏57 KB

The conversion was done here: http://forums.ni.com/t5/Version-Conversion/need-to-convert-from-Labview-12-VI-to-Labview-11/m-p/3021...
There are only two ways to tell somebody thanks: Kudos and Marked Solutions
Unofficial Forum Rules and Guidelines

Potential Bug with LabVIEW 2009, Report Generation Toolkit, and MS Office 2003

We have discovered an issue with the above listed software. Specifically this pertains to Print Report.vi in the Report Gen palette. Basically, we have discovered that with Office 2003 installed the VI will error out. We've been using it in an executable, and the executable physically fails (and asks us to report an error to Microsoft). With Office 2007 we don't have a problem. We've tried building the examples into executables, and those work because they are printing HTML reports.
Also, we have converted back to LabVIEW 8.6 and rebuilt the executable and installed and it works perfectly. Its on the combination of LabVIEW 2009 and Office 2003 that seems to fail.

yeah, we had seen that, and been told about it by another user. we tried, to no avail. we still have ended up having to migrate back to 8.6.1 to get the executable to run properly.

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

How to create a standalone executable in LabVIEW 2009 Professional Development System?

How to create a standalone executable in LabVIEW 2009 Professional Development System?
Solved!
Go to Solution.

This should help you out http://zone.ni.com/devzone/cda/tut/p/id/3303
Also remember that quick search with Google in many cases will be quicker than asking in this forum. I always use Google before I ask for help in any forum. It is much quicker
Besides which, my opinion is that Express VIs Carthage must be destroyed deleted
(Sorry no Labview "brag list" so far)

UDP Error when upgrading from Labview 8.6 to Labview 2009

I recently updgraded from Labview 8.6 to Labview 2009. I am writing an application to stream data to disk from UDP. My VIs run just fine in Labview 8.6, but when I try to run them in Labview 2009 my UDP read times out despite being able to monitor UDP traffic and see that the data is being sent and nothing in the file is changed from 8.6 to 2009. Is there a known issue related to this?

How are you moniting the UDP traffic? Have you verified that the port you are trying to use is actually available? When you installed 2009 there may have been an additional service installed that may have used the port you're trying to use. If you're running on Windows you can use the command "netstat -n -o -a" to see all the ports that are currently in use, as well as the process ID that has that port open.

Labview 2009 SP1 Installer build help needed

Hello,
First time posting here. I have a rather large project that I recently converted from Labview 7.0 to 9.0. I am able to build an executable and it starts up Ok but I don't know for sure if it works. Since I couldn't build an installer, I copied the folder containing the .exe onto the targeted machine and installed Labview Run-time Engine 2009 SP1. The executable then complains that it needs the full development version to work. I am not too worry about this part at the moment, but if you have any pointers, please go ahead and post them.
Ok, I have gone through a lot of posts on building and installer but it seems the one post that has something similar to what I experienced didn't get an answer. Here's the Build Errors from the pop-up dialog:
CDK_Item_OnDoProperties.vi.ProxyCaller >> CDK_Item_OnDoProperties.vi >> CDK_InstallerConfiguration_Editor.vi >> CDK_Build_Invoke.vi >> CDK_Engine_Main.vi >> CDK_Engine_BuildDevPart.vi >> NI_MDF.lvlib:MDFBuildDevPart_SetOtherProperties.vi
Loading product deployment information
Loading product deployment information
Loading product deployment information
Loading product deployment information
Adding files to installer
*** Error: An internal tool or library returned an error. (Error code -21)
*** End Error Report
*** Error: Windows SDK function returned an error. (Error code -12)
*** End Error Report
The build log file has slightly more info:
    [LOG ON] Mon May 31 20:55:07 2010
<<<MDFConfig_SetDeveloperLanguage>>> Language id: 9
<<<MDFConfig_SetDistributionLanguage>>> Language id: 9
<<<MDFConfig_SetBuildDir>>> Build directory: C:\HardwareTest\XXX\Release\Installers\Lab Test Suite 4.2.9 Installer - XXX
<<<MDFConfig_SetBuildMode>>> Build mode: 1
    [NMDK BEGIN] Mon May 31 20:55:07 2010
     Building developer part
> Adding files to installer
<<<MDFBuildDevPart_SetFileNames>>>
<<<MDFBuildDevPart_SetDefaultInstallDir>>>
<<<MDFBuildDevPart_SetUpgradeInfo>>>
<<<MDFBuildDevPart_SetOtherProperties>>>
>
> **************
> *** Error: An internal tool or library returned an error. (Error code -21)
Error in MDF API function: _MDFBuildDevPart_SetOtherProperties
nmdkSetInformationalProperties returned error code 26024
> *** End Error Report
> **************
>
Adding product dependencies to developer part
>
> **************
> *** Error: Windows SDK function returned an error. (Error code -12)
Closing dist kit
***** About to begin MAXImportConfig:oMAXPartModifications...
No MAX import files specified - nothing to do - returning.
Error in MDF API function: _MDFBuildDevPart_Close
Error in MDF::BuildDeveloperPart::Close.
ERROR: Caught MSI Exception:
<Unable to format error record.>
MSI error code: 6
> *** End Error Report
> **************
>
    [LOG OFF] Mon May 31 20:55:07 2010
    [MDF END] Mon May 31 20:55:07 2010
     Closing MDF.
I realize that I should post my project file but I can't do that until tomorrow. From those 2 errors, can you tell me what the installer builder is looking for? I have gone through all my dependencies and they look Ok at the moment.
Thanks for you time.

Hi Celeb,
I had to help out on another project and finally only getting back to looking at this issue yesterday. As you suggested, I went ahead and created a new project and created new build specifications (exe and installer). I was able to properly build both items but won't be able to check out the executable til later this week.
I noticed one thing about the project that Labview produced after converting the old *.bld file to a project file.  With the converted project, Labview adds unexpected installer destination folders into WindowsFolder in the Installer/Source Files/Destination View. I thought I deleted them before but they seem to make it back (kinda hazy about this at this point).  My actual installer folder should only go into the WindowsVolume folder. Anyway, on the new build spec, since I don't manually add the installer folder into the WindowsFolder, nothing get populated there and the installer is able to build properly. This might have been the cause of my inability to build an installer with the converted project/build specs.
I hope NI could add in more details into the build error messages. As it is, it's really difficult to know why a build failed because there's no details in those messages.
Thanks again,
T.

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;}

Labview 2009 I/O assistant issue

Hi,
I'm using labview 2009, and I can't get the I/O assistant to work-everytime I try to run it, it gives me the error message "Measurement & Automation Explorer or the Instrument I/O Assistant is not installed correctly. Please install these from LabVIEW Driver CD". I've tried uninstalling and re-installing the I/O assistant, but it's not helping-is there anything else that can cause this error I should be looking for?
Thanks

Hi ciwong,
This problem usually originates from installation order. You want to install the drivers after you install after you install LabVIEW.
Another things that jumps out is that you are listing NI VISA 488.2 as version 2.1. The current version of NI VISA is version 5 and the current version of NI 488.2 is version 2.73.
Please let us know if you have any questions
Joe Daily
National Instruments
Applications Engineer
may the G be with you ....

Convert VIs LabVIEW 2012 to LabVIEW 2009

Similar Messages

Maybe you are looking for