Tim Erickson

I received a very good set of instructions from an NI engineer. I followed them will great success and now have LabVIEW 6.1, 7.1, and 8.0 installed on my computer. LabVIEW 6.1 uses NI-DAQ 7.4. LabVIEW 7.1 and 8.0 use DAQmx 8.0. Here are the instructions: ------------------------------------------------------------------------------------------------------------------------- Thank you for contacting National Instruments. Unfortunately, NI-DAQmx 8.0 cannot exist on the same machine as Traditional (Legacy) DAQ 6.9.3. Actually, this is true all the way back to DAQmx 7.0. Significant changes were necessary in Traditional DAQ to make it co-exist with DAQmx. In your situation, I would first uninstall Traditional DAQ 6.9.3. Then, install NI-DAQ 7.4. This will bring you up to Traditional DAQ 7.4 and DAQmx 7.4. Don't worry, your card is compatible with Traditional DAQ 7.4 (http://www.ni.com/support/daq/versions_pci_pxi.htm). The Traditional DAQ installation will install VIs for LabVIEW 6.1, while DAQmx 7.4 will not install any VIs. I would next install LabVIEW 8.0. Then, you can install DAQmx 8.0, which will install VIs for LabVIEW 8.0. Following these steps, you should be able to program for your 16E-4 in LabVIEW 6.1 with Traditional DAQ 7.4 or in LabVIEW 8.0 with DAQmx 8.0. Finally, if you wish to bring your 6.1 code into LabVIEW 8.0 and modify it, you will need to install Traditional DAQ 7.4.1 (stand alone). For more information on DAQ driver versions and supported versions of LabVIEW, please refer to this KnowledgeBase article: http://digital.ni.com/public.nsf/websearch...48?OpenDocument Finally, if you have any questions about this process, please do not hesitate to let me know. Have a great weekend! Regards, Ryan Verret Applications Engineer National Instruments http://www.ni.com/support

I been developing most of our applications in LabVIEW 6.1 and one in LabVIEW 7.1. with the DAQ 6.9.3 driver on the same computer. They are built into stand alone applications with the Application Builder. When deployed, we use InstallShield to deploy the application as well as install DAQ 6.9.3 and the appropriate LabVIEW RTE. I want to start a controlled upgrade to DAQmx 8.0 and LabVIEW 8.0. If I install the DAQmx 8.0 driver for LabVIEW 7.1 and LabVIEW 8.0, will it wipe out my DAQ 6.9.3 support for LabVIEW 6.1? Anyone tried this before? I need to maintain my LabVIEW 6.1 development setup in order to support legacy versions of our products. I hope I do not have to maintain a second computer.

Thanks for the reply, those are some great suggestions. I will implementing this early next year and now have some information.

Thanks for the reply. I do not think that I need to write a DDE server as our application will only be reading tags, i.e. client only. There will be no communication back to WonderWare. I will try the Excel example over the network and see if I can get it to work.

We have a customer that uses WonderWare and Net DDE. We need to read a few WonderWare tags from a LabVIEW application running on a separate computer. I am sure this has been done before but I cannot find a good example that demonstrates the format to use for computer name, service, topic, item name when talking to WonderWare. I could only find an Access and Excel example. All we need to do is connect to and monitor a few existing tags in WonderWare from another computer on the LAN running a LabVIEW application. I would prefer to use OPC but they have been using Net DDE for years and do not want to change. We cannot use LabVIEW DSC.

You can also anchor items horizontally and vertically by grouping them with a decoration in the different quandrants.

Update: I used the application builder to create exe's for each of the LLB's. There are VI's in the LLB's that call the "lvanlys.dll" and "lvdaq.dll" dll's. I specified in the application builder to put these dll's in the same destination directory as the exe's. Now the "search dialog" is not displayed when the main application is started. The only difference between the LLB's and the exe's is that I used the application builder and not "save with options". So it appears the "search dialog" was being displayed as a result of the dll's not being where LabVIEW thought they were. Building an application must save the appropriate link to any dll's that are used. Comments? Thanks!

I have built an application with the following architecture: 1. Two llb's saved for distribution. These were saved using the "save with options" method so there are a few VI.lib VI's that are in both llb's. 2. One EXE that loads VI's from each llb using the VI server. The intent is to implement a "plug in" type of architecture. The llb's can be individually updated. When the EXE is run, the VI search message box pops up until all VI's have been found. I would prefer that this message box is not displayed. I suspect that this is due to there being multiple copies of VI.lib VI's. Is there an INI file setting to accomplish this? Using LabVIEW 6.1. Thanks!

Thanks Michael! Great idea! This approach opens up lots of possibilities. :thumbup:

Thanks, I will give it a try. Currently I am using an blank database as a template and copying it programmatically to where it needs to be.

Hello, I am looking for the most efficient way to backup records deleted from a MS Access database to another location. This is what I have come up with so far: 1. Copy an empty database to a new location with a new name. This is the database the data will be backed up to. 2. Execute a SELECT INTO SQL statement via the ADO connection object to transfer the data from the old database to the back up database. 3. Delete the transfered data from the old database with a DELETE SQL statement via the ADO connection object. Is there a way to programatically create a blank MS Access database so I do not have to maintain a blank database somewhere? Does anyone have any improvements or another way to do this? Thanks!

It used to be in LabVIEW 6.1 you could format the x-axis to be relative time. The user could then enter in a time in seconds on the x-axis and have it automatically format to hh:mm:ss. For example, an entry of 100 would be displayed as 1:40. In LabVIEW 7.1, an entry of 100 is displayed as 100:00:00. Is there a way to make 7.1 behave like 6.1 when entering a time in seconds on a graph axis?

Do you use InstallShield? This is more of an InstallShield question now but may be of interest to other LabVIEW developers. How do you determine what component code to assign to each individual DLL? These DLL's are shared by all LabVIEW applications and therefore the removal of one application cannot remove the DLL until its refcount in the registry is 0. Do you let InstallShield assign the component code when you build the first installer and then use that component code for each additional LabVIEW application that you deploy? Should the same component code be used that NI used? One more question, does the LabVIEW Runtime Installer put anything in the windows directory or system32 directory? Thanks!

Sounds a good idea. Have you done a similar thing with NI-DAQ?

I just upgraded from LabVIEW 6.1 to 7.1. In the past we built an application with the Application Builder and then built an installer using InstallShield. The installer looks to see if LVRTE is installed using its product code and then installs it if need be. However, after upgrading, the installer cannot determine if LVRTE 7.1 is installed using the product code of LVRTE 7.1. In addition, if I try and run the installer for LVRTE 7.1 manually I get an error telling me that a higher version of the product is already installed. Also, the LVRTE no longer appears individually in "Add/Remove Programs" but under a generic "NI Software" heading. Using the LVRTE merge module will not work for us because we will have multiple applications installed on one pc and we cannot risk crippling them all if one is removed due to the LVRTE being removed. Does anyone know what changed between the LabVIEW 6.1 and LabVIEW 7.1 RTE msi files? Thanks!

Are there any merge modules for NI-DAQ?