Labview 7.1 to Labview 8.0 upgrade

Greetings all,
My company has recently aquired labview 8.0 licences and is intending to use it as its development platform instead of labview 7.1. the problem is that all of our customers are currently running executables generated in a labview 7.1 environment and any updated versions of our software that we will send them in the future will most likely be developed in labview 8.0. The question is , other than sending them the executables generated by LV8 along with LV8 RTE are there any problems. did any one see a problem with a conversion like this. i have done alot of reasearch about this and have been testing the converted code from 7.1 to 8 and the executalbes generated by 8.0 and i havent seen any major problems. any feedback on a related probelm would be greatly appreciated.
I am using
Serial communications
LPT ports
udp communications
PCI I/O boards
talking to remote and local data bases (Micorsoft and Oracle)
all on a Windows Xp pro operating system

Hi,
Only thing I've noticed so far is that LV8 uses the show scrollbar setting from it's contained vi and LV7 doesn't. Very minor...
We had some problems with old daqmx that wasn't working with LV8 vi's, and the new daqmx didn't support the hardware. We solved it by copying some LV7 vi's to LV8. I don't know all the details, my colleague worked on it.
I hear some stories about multi platform deployment problems (FPGA, RT..), but I don't know any details.
If all hardware is working, I wouldn't be concerned.
Regards,
Wiebe.
"malyounes" <[email protected]> wrote in message news:[email protected]..
Greetings all,
 
My company has recently aquired labview 8.0 licences and is intending to use it as its development platform instead of labview 7.1. the problem is that all of our customers are currently running executables generated in a labview 7.1 environment and any updated versions of our software that we will send them in the future will most likely be developed in labview 8.0. The question is , other than sending them the executables generated by LV8 along with LV8 RTE are there any problems. did any one see a problem with a conversion like this. i have done alot of reasearch about this and have been testing the converted code from 7.1 to 8 and the executalbes generated by 8.0 and i havent seen any major problems. any feedback on a related probelm would be greatly appreciated.
 
I am using
Serial communications
LPT ports
udp communications
PCI I/O boards
talking to remote and local data bases (Micorsoft and Oracle)
all on a Windows Xp pro operating system 

Similar Messages

Labview and GPIB upgrade horror

Hello community,
I have to upgrade and extend an old LabView system. The old system
runs with LabView 4.01 and Win3.11 and has been working for years
without problems. It uses the standard GPIB VIs in LabView to
commumicate with measuring devices, sensors, supplies, heaters, etc.
I really can't understand why I get a GPIB error 3 with *most* of the
devices under LabView 5.1/Win98 and *exactly* the same GPIB devices
and VIs. The GPIB VIs just initialize the GPIB, and write strings,
then close the GPIB. No more. I don't understand why something that
worked with an *older* version of LabView systematically fails with a
newer version (I could understand it vice versa).
I know that the standard answer is 'you can't use a LabView 4.01
driver in LabView 5.1', but these 'drivers' are no real drivers. They
just form the string to write to GPIB for the GPIB device,
respectively. No more. And the string to write didn't change because
the GPIB devices didn't change.
Also, it doesn't seem to be a problem of an odd GPIB device (exotic or
ancient), but a general problem. Could it be that I miss something in
the configuration of the GPIB card? In LabView 5.1 I can configure the
GPIB in the Measurement and Automation Explorer (GPIB Properties). I
would like to verify the configuration with that used in LabView
4.01/Win3.11. I do not have an Automation Explorer in LabView
4.01/Win3.11. How do I get the same information there?
It is probably not even a LabView 4.01 -> LabView 5.1 problem. The old
system is on a 486 PC and certainly uses an older PCI GPIB card. The
newer system runs on a Pentium II and uses a brand new PCI GPIB card
from NI. I tried to installate LabView 4.01 on the newer PC (yes,
after having removed LabView 5.1), but the GPIB VIs didn't work
either. Note, however, that it is LabView 4.01 for Windows 3.1
(16bit), (we only have the 16bit version) so, I am actually not
surprised that it doesn't work with Win98. Some person suggested to
use a rather old GPIB card in the new system, but this can't be true
IMHO.
Another person pointed out that maybe NI changed the interface of the
GPIB write VI. That is, even if the VI has exactly the same appearance
and connectors in both LabView versions, some connectors that were
optional in LV4 could have become mandatory in LV5. I read the
documentation of the GPIB write VI in both versions. It is exactly the
same. It would be more than strange, anyway.
When I tried to write a GPIB 'driver' and I have a working driver for
an older version than I analysed the string the old VI writes to the
GPIB and I write exactly the same string to GPIB in the new driver.
It's very strange for me that this doesn't work.
Maybe another person has some experience and give me a hint what
*could* work (maybe with GPIB II or VISA).
Thanks very much.
Best regards
Johannes

Hi Joe,
On Mon, 8 Dec 2003 07:32:37 -0600 (CST), JoeLabView
wrote:
>Wow... That's a lot of info..
>
>First of all, let me understand the scenario.
>
>1. Newer PC from 486 to P-II.
>2. From Win-3.11 to Win-98.
>3. Newer GPIB cards.
>4. Upgrade to LV-5.1
>5. vi's remained unchanged from LV4.01.
>6. Instruments are the same, same cables, etc.
>
>The problem is the inability to communicate with the instruments or
>inability to configure them.
Correct.
>
>
>Let's look at the additional info:
>
>"I really can't understand why I get a GPIB error 3 with *most* of the
>devices under LabView 5.1/Win98 and *exactly* the same GPIB devices
>and VIs."
>
>So you are able to communicate with some of the devices.
Yes, with two of them, because I could get *working* LabView 5.1
drivers for these devices. I didn't have to write them myself. I have
looked at the drivers for these devices. One is a Keithley 2000
driver. Internally it uses the standard GPIB write VI. The other is a
VISA driver for a Toellner power supply.
>
>My first question would be:
>Q: Did you use MAX (Measurement & Automation eXplorer) to detect your
>GPIB card and find the instruments? The GPIB interface should show up
>under "Devices & Interfaces". It probably does since you are able to
>communicate with some.
Yes, I can find all instruments when I scan in the MAX, even if one
instrument (a Heraeus-Voetsch HT4004 oven) doesn't return an
identification string. But that is no error because the oven is
connected via a GPIB to serial interface converter (from the same
company.) and I guess they just wanted to get conversion done without
cosmetics
>Otherwise, I would recommend looking into the
>device driver info within "System" in Control Panel of Win-98 to
>determine if there is a conflict with the board..
I can even query the HT4004 for *IDN? and I don't get an error. (I
just get a white space (?) because the HT4004 doesn't return an
identification string as I wrote above, but I don't get an error).
In fact, this HT4004 is the last GPIB instrument that doesn't work,
because I have found a substitute or a workaround for *all other*
instruments that didn't work. But I *have* to use this HT4004. And it
is no instrument specific error because in the beginning I got this
error with allmost all GPIB instruments.
>"the GPIB devices didn't change."
>
>Did you install a new GPIB card? Device... you mean instrument,
>right?
Yes. The new LabView 5.1 system is running on another PC with another
brand new GPIB card from NI, but the GPIB instruments (measuring
devices, HT4004) didn't change.
>
>
>"Could it be that I miss something in
>the configuration of the GPIB card? In LabView 5.1 I can configure the
>GPIB in the Measurement and Automation Explorer (GPIB Properties). "
>
>Maybe.. So try this..
>
>In MAX, go to Devices and Instruments, select the "troublesome"
>instrument and click on "Communicate with Instrument". Here, you can
>send your string and see "manually" the response from the instrument
>or observe the behaviour of the instrument based on the command or
>string that you send it. That will tell you a lot about the
>communication over GPIB..
I have tried this, but nothing happens. The HT4004 should turn on a
ventilator and begin to warm up. Tomorrow, I will try it again, I am
not in the Lab today. But you mean that I should do a *write*, not a
*query* with the string?
>"I would like to verify the configuration with that used in LabView
>4.01/Win3.11. I do not have an Automation Explorer in LabView
>4.01/Win3.11. How do I get the same information there?"
>
>Focus on the newer LV5.1. You're stepping up...Don't turn back. ;o)
Yes. I just want to check if the configuration is special in the
LabView 4.01 system (maybe a check on 'send EOI with EOS or another
timing).
I would actually turn back to a 4.01 system that works instead of a
7.0 system that doesn't. However, I would definitely not turn back to
Win16.
>That would indicate that the problem is not the newer version of LV,
>but more likely related to the GPIB card or setting. Did you get
>those newer GPIB cards to work?
Hmm, it works with the Keithley and Toellner instruments. Also, I have
tried the whole system on a *third* PC with Win98/LabView5.1/PCI GPIB
card. Same error.
>Or can you try the "older" ISA GPIB
>card in the newer PC?
I think it is a PCI card. I will try that too, as a last step, since I
hesitate to destroy a running system...
Johannes

3D graphs cause LabVIEW 2010 to hang

I've been using LabVIEW 2010 for several weeks without any problems, but today I noticed that it doesn't work at all with anything related to the 3D picture control. Today was the first time that I tried doing anything with the 3D picture tool since installing LV 2010. Dropping any of the 3D Graphs on the front panel of a new VI causes LV2010 to hang. (By hang, I mean the VI window remains open but most UI things no longer work. Right-clicking on the window does not show a context menu. The main menu doesn't work. The X button does not close the VI front panel window nor the diagram window. Control-Q does not cause LabVIEW to quit. I have to kill the process in Task Manager.) It is the same story with just a plaing 3D picture indicator. Also, the solarsystem.vi example does not work either. The problems start as soon as I open the solarsystem.vi. After killing LV with Task Manager and relaunching LV10, I do not get the LV message about a previous crash.
The problem I am talking about is for LabVIEW 2010 with the f2 patch running in Win7. I am actually running it using VMware Fusion 3.1.3 on a 2009 Mac Pro running Lion. The Mac drivers are all updated. Since it is VMware Fusion machine, the video driver on the Windows side is part of the VMware Tools installation, which is up to date.
After searching the forums, I've tried all the other potential solutions I could find: 1) repaired LV2010 using add/remove programs and 2) tried using the compatibilty mode settings to turn off Aero.
Interestingly, 3D graphs work fine on the Mac side for LV2010 for Mac.
Even more insterestingly, 3D graphs work fine on Win7 for LV 8.5, which I still have installed. The fact that it works fine for LV 8.5 would seem to indicate that Lion did not introduce the problem and that the video driver is working fine.
Solved!
Go to Solution.

Yep, it's the same virtual machine. I set it up almost 2 years ago and it has been extremely stable. Both LabVIEW 8.5 and 2010 have been perfectly happy on it. It's a great way to do LabVIEW on Win7. I didn't notice any changes at all to the VM when I upgraded from Snow Leopard to Lion. I installed LabVIEW 2010 before upgrading to Lion, but I didn't have occasion to work with 3D controls before the upgrade to Lion so I don't know if it would have worked on Snow Leopard. The Mac versions of both LabVIEW 8.5 and LabVIEW 2010 also work great on the both Snow Leopard and Lion.
I happen to have an XP virtual machine too, but I haven't installed LabVIEW there. Let me know if that would be a worthwhile test.
You might check with Marc Page--unless he has already upgraded again I think he has a similar machine to mine.
The video card is the original stock:
NVIDIA GeForce GT 120:
Chipset Model: NVIDIA GeForce GT 120
Type: GPU
Bus: PCIe
Slot: Slot-1
PCIe Lane Width: x16
VRAM (Total): 512 MB
Vendor: NVIDIA (0x10de)
Device ID: 0x0640
Revision ID: 0x00a1
ROM Revision: 3386
Displays:
Cinema HD Display:
Resolution: 2560 x 1600
Pixel Depth: 32-Bit Color (ARGB8888)
Main Display: Yes
Mirror: Off
Online: Yes
Rotation: Supported
Display Connector:
Status: No Display Connected

Does change to Windows XP involve problems with application runnig with Labview 6.1?

Thank you

A little more information maybe helpful. Are you saying you have upgraded from a OS to Windows XP and it caused problems with your application, or are you asking if there will be any problems if you upgrade? What OS were you upgrading from? LabVIEW 6.1 is the first issue of LabVIEW that was supported under Windows XP, so there should not be any issues there. In my experience, doing upgrades from one Windows version to another is never a smooth transition. If you are using any hardware I would advise that you uninstall the drivers and remove the hardware before the upgrade. I might go as far as removing existing National Instruments (such as LabVIEW) before you upgrade and then reinstall the software and hardware after you have upgraded. This will be the be
st way of ensureing you have as little problems as possible after you upgrade.

How do I convert an earlier numeric array in LabVIEW 5.x or earlier to a Waveform Data Type in LabVIEW 6i?

I am trying to convert old data arrays in LabVIEW 4.x & 5.x to the new Waveform Data Type in LabVIEW 6i. Please Ref. Doc. LabVIEW 6.0 Upgrades Notes page 7-8 as a source.
Has anyone ever tried it?

try to use Buil Waveform VI after loading old data from files ...
LabView Help : "Build Waveform
Builds a waveform or modifies an existing waveform. If you do not wire an input to waveform, Build Waveform creates a new waveform based on the components you enter. If you do wire an input in waveform, the waveform is modified based on the components you specify. This function is expandable."

How do I convert a earlier numeric array in LabVIEW 5.x or eralier to a Waveform Data Type in LabVIEW 6i?

I am trying to convert old arrays in LabVIEW 4.x and 5.x to the new Waveform Data Type in LabVIEW 6i. Please ref. Doc. LabVIEW 6.0 Upgrades Notes page 7-8 at a source of reference. Has anyone ever tried it?

Hi Andy,
I do this all of the time. On the block diagram palette is the Waveform subpalette. The second icon is the build waveform vi. This has three elements, to, dt, and y. The to is the initial time (typically zero), the dt is the delta time in your waveform and the y is where you wire up you old array data to. The output is a waveform datatype.
Regards,
Marc

Anybody have an old copy of labview for 68K Macs they don't need?

I have a few NI NUBUS cards I wanted to use with a 68K version of Labview
just to mess around. Anybody have an old 68K compatible version of Labview
in the US they dont want (I think 4.x is the last version made).

Hi Lastmile,
I cannot provide you with an old version of LabVIEW, but hopefully I can help you find some useful documentation. Take a look at the Manuals search on our website to try to locate specific manuals. When looking for older versions, I suggest searching by the year of release.
LabVIEW for Macintosh Upgrade Notes (version 4.1)
LabVIEW Release Notes for Macintosh (version 4.1)
LabVIEW Function and VI Reference Manual (version 4.1)
LabVIEW User Manual (version 5: should be very similar)
Regards,
Lauren
Applications Engineering
National Instruments

Since upgrading to LabVIEW 2013, every VI compiles every time I open it (including quick-drop).

Hi all. Since upgrading to LabVIEW 2013, every VI compiles every time I open it (including quick-drop). This really slows things down! Perhaps related, my system tells me I don't have permission/access to modify my LabVIEW ini. Has anyone seen similar, and/or any hints towards a solution?

Jeff-P wrote:
As a side note, LabVIEW.ini is a file that gets generated by LabVIEW when it is launched if the file does not exist. So if you are missing the 32-bit ini file, launch 32-bit LabVIEW and that file should be created.
I thought that the message: "Perhaps related, my system tells me I don't have permission/access to modify my LabVIEW ini" might indicate that the labview.ini file cannot even be created... strange...
LabVIEW Champion . Do more with less code and in less time .

Labview 6.0 cannot call ActiveX functions after upgrading to Teststand 2

I'm running on Win2K on my development system. I have been running fine with Teststand ver 1.0.3 and Labview 6.0 with several VI's using ActiveX to work with the TestStand engine. I tried installing TestStand 2.0 (dated Aug 2001) next to 1.03 (not on top of it) to start upgrading and all those ActiveX VI's no longer functioned.
NI's documentation says Teststand 2 installs the LV RTE 6.02 on the system and to run a "REPAIR" on the LV RT Server 6.02 if installing LV 6.0 after Teststand (not my case). I ran the "repair" anyway to no avail.
I tried running NI's ActiveX example "Write Table to XL.vi" and it also does not run (Error -2147024891, "Access is denied.
in Open Excel and Make Visible.vi->Wr
ite Table to XL.vi"). I have run this before just fine.
I've even tried re-installing LV 6.0 and re-running the repair to no avail, also mass compiling everything in site. Always the same error!
Please help, anyone. My system is DOWN!.....

We have not seen this exact problem before with TestStand 1.0.3, 2.0, and LabVIEW 6.0. If your system is still down, please give us a call and we can talk through getting everything working. You can make a phone support request online by going to Request Support and choosing "Phone NI" from the Communication Method Pull Down menu.
Regards,
Shannon Rariden
Applications Engineer
National Instruments

NI-DAQmx 8.8 does not work properly after upgrade to LabVIEW 8.6

Hi,
I just upgraded to LabView 8.6 from version 7.1 and found out that the NI-DAQmx 8.8 drivers do not install correctly, since there is not Measurement I/O tab in the Functions palette (see attached document). The curious thing is that I can see all my NI-DAQmx devices in the MAX, and they all test correctly, i.e., they are working correctly. The sales representative for my area recommended me to uninstall , and reinstall LV8.6 and then reinstall the NI-DAQmx 8.8 drivers, but it did not work. I still do not see the Measurement I/O functions and my application says that it "cannot compile" the NI-DAQmx vi's. Thanks in advance for your help.
Peter
PS. Someone reported a similar problem back in 2003, but the final solution was not posted. Thanks again.
Attachments:
LV8.6.doc ‏116 KB

Dear Mallori,
Thanks for your help. You are right, I uninstalled and reinstalled LabVIEW 8.6 (update from LabVIEW 7.1) and reinstalled DAQmx 8.8. I still continue to have some problem that seem (to me) beyond compatibility issues. Here are the answers to your questions:
1. Before you reinstalled DAQmx 8.8, did you
uninstall it? If not, then I believe that the installer would see the
driver already present and not actually make any changes.
REPLY: No, I did not uninstall DAQmx 8.8. What do you recommend? Should I uninstall BOTH LabVIEW 8.6 and DAQmx 8.8 and then reinstall everything again?
2. When you say that the VIs are not responsive,
could you describe this a bit better? Perhaps post one of the error
messages about compiling that you mentioned in your first post?
REPLY: I am having a lots of "This SubVI is not executable" error messages in many of the library VI's not even mine. See the attached file.
3. If you open the NI Example Finder (Help»Find
Examples) and the expand Hardware Input and Output»DAQmx»Analog
Measurements»Voltage, are you able to run one of the example programs
and see the correct values that you see in the Measurement and
Automation Explorer Test Panels?
REPLY: I tried to runa couple of the examples for continuous voltage acquisition (internal clock) and both open with errors (see attachement).
Thanks again for your help. I am looking forward to your recommendation.
Regards,
Peter
Attachments:
LV8.6-3.doc ‏43 KB

What are developers' opinions on how best to handle upgrading large code libraries with multiple apps to new a labview version?

I have a large set of code that I've painstakingly migrated from one labview version to another over the years. I have lots of deployed applications that I need to continue to support. From experience and interaction with other developers, I don't think I can continue to migrate every application to a new labview version when I upgrade going forward. Every application seems to break in one way or another, the builds don't work right and need to be re-done, and its too much time to get all my applications working and tested again. That opinion is solidified by NI's policies that make it impossible to install old toolkit versions on new labview versions, for example. Compatibility is often being sacrificed so NI can develop labview in the direction they choose. So I have to take the position that whatever version I write an application in will probably need to be maintained in that labview version throughout it's life.
In light of this, how are other developers managing older applicatiosn written in older versions of labview. Right now I have a virtual PC on my system with 7.1, 8.0, 8.2, and 8.5 all running on different virtual PC's so I can keep each installation separate. I strongly recommend this approach. But keeping my large libraries of code separate is tough. They are many GB, they all link to each other, and I always get worried even when I separate them in different directories that somehow labview will search in the wrong place and find the wrong version of a sub-vi. Are other people also trying to maintain separate copies of all their code in different labview versions? How are other people managing this problem?
-Devin
I got 99 problems but 8.6 ain't one.
Solved!
Go to Solution.

Hi,
The following directory hierarchy, coupled with a "hierarchical" VI naming strategy, have been effective (for me) at preventing "cross-linking" across projects and LV versions. The storage hierarchy was designed for use within an SCC environment, but works fine independently. Hierarchical-naming insures unique names for application-specific files. Use of Project Libraries (in LabVIEW 8.x) addresses the problem of having different VIs with the same name, still, it gives me warm-fuzzies to have app-specific files named uniquely, and I can't imagine not using Hierarchical-naming anymore - it's described at-length in section 2.1 of attached .doc..
Note: It's been my experience that companies identify resources as supporting specific "Programs", where a Program is related to a product or "family" of products, so, under <Programs> (below) each "Program" subdirectory encapsulates product-specific (or product-family-specific) applications. Also, assuming no SCC tool is being employed the <Production> directory (below) exists as a repository for distributables. All distributables required to reproduce a test-station should be located under <Production>.
<Software_Root>
<Development>
| <Common>
| | <LabVIEW_61>
| | | <Drivers>
| | | | <DMM>
| | | | <OS>
| | | | <PS>
| | | <Utilities>
| | | <File>
| | | <Error>
| | | <String>
| | <LabVIEW_711>
| | <LabVIEW_82>
| | <LabVIEW_851>
<Programs>
* Program-specific applications that (probably) have distributables
| <Program_#1>
| | <Application_#1>
| | <Docs>
| | <Source>
*       Individual, application-specific, VIs go here
| | <Application_#2>
| | <Application_#3>
| <Program_2>
| | <Program_3>
| <Tools>
* Tools are NOT "program"-specific, and, may have distributables
| <SomeTool>
| <SomeOtherTool>
<Production>
| <COTS&Freeware>
| <Programs>
| | <Program_1>
| | | <Application_#1>
| | | | <Application_#1_Rev#1>
| | | | Application_#1.bld>
| | | | <EXE>
| | | | <Installer>
| | | | <Source>
| | | |    Application_#1.llb>
*           Distributable is created from LLB "snapshot", not directly from development tree
| | | <Application_#2>
| | | | <Application_#2_Rev#1>
| | | | Application_#2.lvproj>
| | | | <EXE>
| | | | <Installer>
| | | | <Source>
| | | |    Application_#2.llb>
| <Tools>
"Inside every large program is a small program struggling to get out." (attributed to Tony Hoare)
Attachments:
StyleGuide.doc ‏941 KB

Upgrading from Labview 8.0 to Labview 8.6

Software installed in my system (Window 2000):
Testand 3.5
Labview 8.0
Cvi 8.0
Device drivers
NI-488.2 VERSION 2.46
NI-VISA VERSION 3.6
NI-DAQMX VERSION 8.1.0F1
I want to install LABVIEW 8.6 instead of LABVIEW 8.0
1.Do I have to upgrade Testand,Cvi, or one of the device drivers?
2.Do I have to uninstall labview 8.0 before installing labview 8.6
(right now Labview 8.0 is installed at directory: "c:\Program Files\National Instruments\LabVIEW"
& I want to install LABVIEW 8.6 at the same path.
Thanks Ofer

Hi ofer_o,
you have to install the device drivers for LabVIEW 8.6. You don't need to install TestStand or CVI again. You don't have to uninstall LabVIEW 8.0 to run 8.6. You can use both side by side, technically, i'm not sure about your license.
Mike

Can not access serial port while upgrading from LabVIEW 6.1 to 7.0

Hi,
I built an application under LabVIEW 6.0.2. few years ago. This application uses LabVIEW serial features. When I upgraded to LabVIEW 6.1, my application was still working correctly.
Today, I upgraded to LabVIEW 7.0, mass compile all VIs and now my application can not communicate with my peripheral !!!
The program is sending the command to the peripheral. The peripheral answers but LabVIEW serial driver does not see any datas on buffer even if datas are available ... "Bytes At serial port.vi" always returns 0. I am sure that datas are available, using a COM port psy.
Does anyone has an idea?
I saw a lot of solutions in the forum, but I would like to know the best solution with minimum work, te
st, and so on ... on my program.
Regards,
Pascal.

Hi Pascal,
Which is your version of NI-VISA?
Please see the link bellow :
http://digital.ni.com/manuals.nsf/websearch/E8D86CD680B0753D86256D2C005D8EA0
The first test to be made is to test the communication with your serial port using MAX (Measurement and Automation Explorer) :
Open MAX, Go to "Devices and Interfaces", then "Ports", select COM1 (or ASRL1::INSTR). Right clic on it and select "Open VISA Session" the go the "Basic I/O" then Write data, execute, Read data, execute.
Be sure that the communication is OK. Be sure that you use the same Alias existing in MAX in your LabVIEW program.
Now, if all is OK, try to use Serial communication examples existing in LabVIEW Help>>Examples Finder. These examples use NI-VISA VIs.
If all above is OK and you
still have the same problem, try to follow these instructions :
"In order to use the old Serial Compatibility VIs in LabVIEW 7.x, you must copy the following files from a previous version of LabVIEW to the LabVIEW 7.x directory:
Replace the serial.llb in LabVIEW 7.x with the serial.llb from a previous version of LabVIEW. This file is found in C:\Program Files\National Instruments\LabVIEW\vi.lib\instr.
Replace the _sersup.llb file in LabVIEW 7.x with the _sersup.llb from a previous version of LabVIEW. In LabVIEW 6i and 6.1 this file is located in C:\Program Files\National Instruments\LabVIEW\vi.lib\platform. In LabVIEW 7.x (and 5.x) this file is found in C:\Program Files\National Instruments\LabVIEW\vi.lib\instr.
Copy the file serpdrv to the C:\Program Files\National Instruments\LabVIEW 7.x directory. This file is not installed with LabVIEW 7.x, so it only needs to be copied from a previous version of LabVIEW, not replaced."
I hope that my answer will help you.
Sa
naa T
National Instruments

Has anyone encountered a Microsoft Visual C++ Runtime error in Windows 2000 when upgrading from Labview 6.0i to 6.0.2?

When I try to upgrade Labview 6.0i to 6.0.2 by running the setup.exe file I downloaded from the NI site, I immediately get a dialog box with the header "Microsoft Visual C++ Runtime Library" and it says "Runtime Error! Program: C:\setup.exe abnormal program termination."
I'm running Windows 2000, but I've successfully installed it on another computer with the same setup. I'm guess some of the DLL files in system32 has been corrupted or mismatched versions. But I don't know which one...
Anyone know what this means?

Hello,
You can probably solve this problem by going to Start >> Run and typing the following:
Regsvr32 \msi.dll
Where is the folder where the msi.dll file resides on your computer (you can use Start >> Find to find the exact location). Once you do this, the installation of the 6.0.2 update should work properly.
Please let me know if you continue to have any problems. Thanks for your patience on this issue, and have a pleasant day.
Sincerely,
Darren Nattinger
Applications Engineer
National Instruments
Darren Nattinger, CLA
LabVIEW Artisan and Nugget Penman

Can you upgrade an ActiveX without breaking an existing LabVIEW application?

Suppose you have a LabVIEW application that uses an ActiveX version 1.0.
At some later time you get an upgrade of the ActiveX or simply install another application that uses and distribute a newer version of the same ActiveX ( version 2.0 which support the same basic interface ) From what I experieced so far, upgrading the ActiveX will prevent the LabVIEW application from running unless the developper of the application goes in its LabVIEW project, upgrade the control within project/panels, recompile and distribute another copy of the application.
Is LabVIEW using manifest ? What is actually preventing the existing LabVIEW from running? Are there some type of MANIFEST embedded?

Hi Rastikan,
LabVIEW does use Manifest while registering ActiveX applications. Access to the Manifest file can let you alter access privileges for ActiveX assembly. You can find more information on using and editing the Manifest file in this post. Also have a look at this knowledgebase article--although it talks about LabVIEW 8.2, it contains information on Manifest files. Hope this helps.
Ipshita C.
National Instruments
Applications Engineer

Labview 7.1 to Labview 8.0 upgrade

Similar Messages

Maybe you are looking for