Driver/LabVIEW version conflicts

I am tasked with deploying a major upgrade/rewrite of an inhouse developed LabVIEW .exe program to a test system that is located at our facility a long distance away (different country) and I won't be onsite to perform/debug the install. Currently it is running a version 8.2 "EXE" and LabVIEW RTE, NI-VISA 3.4.1, DAQmx 8.0.0f0 and MAX v4.0.0.3010. My new program is in LabVIEW v2011sp3, MAX 5.1, DAQmx 9.3.5, NI-CAN 2.7.3. My question is whether installing these updates will cause the existing test system not run, which not a desirable state as it is running production testing and I expect that the software/hardware integration will take longer as I will not be onsite and I haven't had the target hardware here to debug my code on. Any thoughts or experience in this regard will be helpful. In the last several years I haven't had a similar issue, most of my projects have been either new, or updates in the same version.
As always, thank you in advance.
Putnam
Certified LabVIEW Developer
Senior Test Engineer
Currently using LV 6.1-LabVIEW 2012, RT8.5
LabVIEW Champion

If they are running on a PC, and they are in a country that is reasonably easy to import stuff, then I would just ship them a spare PC with DAQ card and your version of the software already installed. Then they can swap back and forth between PCs. Bonus points if you ship a KVM switch to make the process easier on them. If you're on any other hardware it might be cost prohibative to replicate.
If you can accurately replicate their installation locally then you can try putting the two versions of software side-by-side and seeing what happens. It wouldn't be the first time things worked beyond the published NI charts.
If you can recreate your code in LabVIEW 2009 then you can run DAQ-mx 9.1.1 and both versions are supported. Once you work out any issues you can move to a more modern version of LabVIEW. Depending on how complex the code is this might be cost prohibative.
If there is another identical installation somewhere more accessable then you could use that location as a proving ground prior to deploying your code to the location we're discussing.
Just a few ideas to think through.

Similar Messages

Version conflicts between host labview and RT engine

there is problem that i cannt switch target to feild point. It said that "version conflicts between host labview and RT engine" . But my labview is version 7.0 and the real time module is version 7.0 too. Anyone can give me hand? Thanks

Depending on your version of MAX, you should be able to change the version on the FP (in remote systems). If you can't do it in 3.0, try upgrading to 3.1 (you will have to search for it on the site). If that doesn't work, you can try resetting to factory default and then see if you can do this.
Another tip, which for some reason seems to help, is updating the OS\Run-Time Engine when windows is in safe mode.
Try these and see if they help.
BTW, as a tip for next time, you're more likely to get a good answer for something like this if you post in the FieldPoint board.
Try to take over the world!

Sypris Teslameter Driver_too early to convert to 8.5 labview version

I am new to labview (8.5) programme and trying to use it to run my setup. I connected the Gaussmeter/Teslameter (FW Bell Sypris 6010) to the computer using serial port and RS-232 cable and used the driver (from the company) for this type of devices in order to allow labview to communicate with this device but there is always an error when I try to access the device through labview. This error says:
"VI version is too early to convert the current LabView version"
I would really appreciate any help in getting this solved.
Many thanks
Hadiq
Islam means peace
Solved!
Go to Solution.
Attachments:
FWB6010.zip ‏412 KB

Thanks for your suggestion. I did it and hope to get it sorted.
Many thanks,
hadiq
Islam means peace

Version conflict while targeting a vi to RT engine

When i am targeting a vi to Labview RT engine the message "Version Conflicts between Host Labview and RT engines" is coming.
I am using a CFP-2100 and want to run a vi on it. (No PC should be connected with it)
After targetting how will i execute it on CFP? is it automatically executable?
Please reply me
--Alok Trivedi
Pune
-AL☼K

Thanx for replying me so soon.
I am still stucked with the problem.
I have Labview 7.0 installed on my computer and where i am making a vi which is to b loaded into CFP - 2100.
Here are other versions i am using.....
Field point VI manager 3.1.0
Field point Drivers 5.1.0
Data socket for Labview Real Time 4.2
Labview Real Time 7.1
NI-Irda RT 1.0.1
NI-Serial RT 2.5.4
NI-VISA 3.2
NI-Watchdog 2.1.2
When i switch the execution target to RT engine for remote device and enter the machine IP address it shows me "Version Conflict while targeting a VI to RT engine".
I talked to Rahul about this and he well told me how to repair version conflicts between Host machine and RT engine. I went to remote machine and by right clicking on "software" installed all the versions to remote machine according to the host machine.
the interesting thing is here it's not showing any version mismatch all the versions shown above are same as the host machine......but whenever i try to target the execution to RT engine it shows the version conflict.
now what all questionis running in my mind are :
1. Why the version conflict is occuring?
2. If I get succeed to targeting the execution of vi onto RT engine how would i install it to CFP, if i just copy and paste it via FTP how will it know what vi is to run? i think we'r missing some way to "install" the vi into CFP.
3 What is "RT Communication wizard for".......why it makes 3 other vi's....
4. what are the total ways to run a vi onto CFP
Waiting for your reply...
thanks again
-Alok Trivedi
Pune
-AL☼K

How do I correct version conflicts between host and RT engine?

I was running LabVIEW RT7.0 on a host PC (WinXP) and PXI-8145 system. I installed LV7.1 and LVRT7.1 on the host. However, the software versions in MAX still report as 7.0
I would like to upgrade to 7.1 on my 8145-RT. I cannot run 7.1 on the host and target the 7.0 RT engine (results in version conflict). Version 7.0 is installed on C:, but 7.1 is installed on D: due to space.
How can I get MAX to recognize my latest version (which should allow my to download it to the PXI)?
Thanks.
Laine

Thank you for the response.
C:\RT Images contains only a single folder for NI-PAL
However, I backed it up and copied the RT Images folder from D:, but still the same effect (MAX thinks 7.0 is the latest LabVIEW version).
D:\RT Images\LabVIEW\7.0 contains subfolders and install scripts (e.g., 7002.rts)
D:\RT Images\LabVIEW\7.1 contains subfolders but no install scripts. Also, there are many fewer files in these subfolders than in the 7.0 folder. I'm worried about trying to manually install from the 7.1 folder.
Any other suggestions? Thanks.
Laine

Target fieldpoint connection failed due to version conflicts

I have set up a small network of fieldpoint (fp-2015) and laptop with Ethernet. Then, I have succesfully configured this fp with MAX and downloaded the iak file to it. Now, I want to target the labview RT of this fp. However, the the connection failed with following message "Version Conflicts between host labview and RT Engine". I'm using Labview 7.1 released in August.

It sounds like the FP-2015 that you have has an older version of software on it (probably LabVIEW 7.0). To upgrade the software on the FP-2015, first launch Measurement & Automation Explorer. Locate the FP-2015 under Remote Systems. Right click on the software item and select Install Software. This will allow you to install the new software image and upgrade the controller to LabVIEW 7.1. Note: You will need FieldPoint Explorer 4.1 which shipped with LabVIEW 7.1. If you have an older version of FieldPoint Explorer, it will not have the 7.1 image for the FieldPoint controller.
Regards,
Aaron

Driver labview 7.0 34401a

Where could I find the labview 7.0 driver for the multimeter hp 34401a, GPIB? the driver on this website is for labview 8.0 and isn't working with version 7.0.
thank you

The driver is included with your version of LabVIEW but if you want the latest version, go here and select the Plug and Play LabVIEW version. Do not select the Plug and Play (project style) driver. Projects were introduced with LabVIEW 8.

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

(macbook pro 2.4 ghz intel core 2 duo 2010 13" aluminum with 8gb of memory and a 250gb hard drive running version 10.6.8 with safari 5.1.4) Safari will open up intermittently on its own.

I have a macbook pro 2.4 ghz intel core 2 duo 2010 13" aluminum with 8gb of memory and a 250gb hard drive running version 10.6.8 with safari 5.1.4. Safari will open up intermittently on its own. System preferences and the dock isn't set up to start safari. Can't figure out why this is happening. Had reloaded system from scratch and noticed this happening lately.

Remove iAntiVirus, then reboot, see if it's better.

Labview version 6.1 failure:"linker.cpp", line 2302

I have the labview version 6.1 failure:"linker.cpp", line 2302 fault.
Does any one can help me please ?
Solved!
Go to Solution.

Actually HeapPeak existed as far back as LabVIEW 4 or maybe even 3. However it is not usually helpful for linker errors as that is something in the LabVIEW compiler itself. HeapPeak can be sort of useful for Insane errors to locate the element that the compiler considers insane (and consequently delete and/or rewire it).
If this is a recent error on a VI that used to work before, it is most likely related to a corruption to the VI and the best course of action is to replace the VI from a backup (source code revision control would be a great advantage here). If it is something where no previous (working) state is known about, then it is going to be a tough cookie. This version is 14 years old and eventhough I still have some installation of that version somewhere it is several years ago that I started that up for more than some accidential reasons. I'm pretty sure NI would need to do some archeological work nowadays to come up with a system they could use to replicate such an error and the OP would need to be a pretty high profile customer that they would go through that sort of effort.
Maybe it is related to this error. It is the closest available in the publically accessible list of errors. A complete recompile of the entire source code tree is definitely one of the first actions to try. It may fix the problem or run into even more errors that could maybe point into a more specific location. Upgrading to a more recent LabVIEW version is another possibility although hampererd by the fact that the currently shipping version isn't officially supporting XP anymore and that the Vision software is one piece of software that underwent serious changes in the course of time and an update from 6.1 to the most recent version is most likely not a seamless operation.
Rolf Kalbermatter
CIT Engineering Netherlands
a division of Test & Measurement Solutions

Possible version conflict, sending purchase order to SUS in MM-SUS scenario

We are currently trying to get the MM-SUS scenario working. In this
scenario, we create a purchase order in the ERP/MM system. The
purchase order is then transferred into SUS via XI/PI.
After creating a purchase order in the MM system, the purchase order
reaches the SUS system, but then errors-out in the SUS system upon
posting. The specific error is paraphrased as follows:
No interface action for sender or receiver found (from Trace)
PARSE_APPLICATION_DATA
CX_ST_MATCH_ELEMENT
System expected the element http://sap.com/xi/SAPGlobal20/Global;
PurchaseOrderRequest
We suspect a version conflict. The SUS version is 7.01. The XI/PI
system is version 7.11.
Can you confirm or rule-out a version conflict?
The Integration Builder scenario we are using is Plan
Driven Procurement with Supplier Enablement.
We have tryed many variations in Integration Builder, but all
produce errors in SUS. The test tool in Integration Builder also shows errors
for certain message types. The message type ORDERS.ORDERS02
needed to be added manually, and did not come along with the scenario.
Edited by: Bill Guderian on Mar 19, 2010 4:53 PM

Any clue from here.
Note 936003 - ERS Invoice causes conversion error within SRM
When the SRM system attempts to process an ERS Invoice sent from the MM backend, a PARSE_APPLICATION_DATA CX_ST_DESERIALIZATION_ERROR fault is thrown.
Other terms
CX_ST_DESERIALIZATION_ERROR PARSE_APPLICATION_DATA SUS SRM EBP ERS Invoice XI Exchange Infrastructure Mapping
Reason and Prerequisites
This error will occur when the IDOC does not have a VPREI value; it is the result of an error within the divide logic of the XI mapping operation. This operation is performed within the XI system. A calculation of NETWR/MENGE is performed; however, the result is not properly formatted. As such, 72.30/10 produces a result of 7.2300002. This value is too long for the inbound SRM proxy and hence the error is thrown.
Solution
The solution to this problem is to add a FORMATNUM function within the XI mapping operation. This restricts the result to 2 decimal places, which adheres to the definition of the inbound proxy.
Step by step directions on how one implements the FORMATNUM function are as follows:
1. Log into the XI system with SAPGUI
2. Start the Integration Builder:Design tool (for steps on how to do this, review the steps below):
    a. Run transaction sxmb_ifr
    b. This will cause a browser to come up. Select the Integration Repository link
3. In the left pane, select the Objects tab
4. Navigate to the SAP SRM SERVER ' SAP SRM SERVER 5.0 ' http://sap.com/xi/SRM/SupplierEnablement/Global --> Mapping Objects --> Message Mappings folder
5. Double-click on MM2SUSInvoice
6. The right pane will display the mapping object
7. Select Edit mode
8. In the box that contains the output (Message Type: InvoiceRequest), navigate to InvoiceRequest ' Invoice ' Item ' Price ' NetUnitPrice
9. Double-click on the Amount element and you should see the mapping, represented graphically in the bottom pane
10. In the status line of the graphical editor, select Arithmetic from the list box:
11. To the right of the listbox, scroll until you see the FormatNum function
12. Click on FormatNum, which will cause the function to be added to the graphical editor. You may drag the box as desired
13. Select the connection that binds the if/then/else to the Amount box by grabbing the arrow within the input of the Amount
14. Release the drag of the connection while over the input to the FormatNum box. This will reassign the output of the if/then/else to the input of FormatNum
15. Create a connection between the output of the FormatNum box and the input of the Amount box. You accomplish this by clicking within the output and releasing within the input (respectively).
16. Save the modified mapping object
17. Activate the changes
    a. In the left pane, select the Change Lists tab
    b. Navigate to the Standard Change List entry
    c. Right-click the Standard Change List entry and select Activate
    d. Select only MM2SUSInvoice if more than one item is available, and press the Activate button
18. This will complete the required modification.

Version conflict in PI QA system

Hi All,
We are facing version conflict issue in QA system.
We transported a Mapping object from Dev to QA and after transporting it is giving Version conflict at QA.
This thing happen because some user has edited mapping program at QA level and activated .
We thought of transporting a deleted object first then the latest active version. But my doubt is that when we transport the same mapping program with same name PI will bring back object along with its history.
Can anyone having any idea about how to resolve this conflict.
Regards,
Navneet

Hi Ninu,
Thanks.
We activated the conflicting version from conflict tab and then transported the dummy changes from DEV to QA to verify it wont give version conflict any more.
it worked fine and conflicting version which we activated at QA considered as latest version for transport.
Regards,
Navneet

File Transport: Version conflict.

Hi,
I have a doubt on a particular scenario while transporting object from QA to PRD using File transport.
I have exported a tpz file say 1.tpz from QA with say the following objects
Obj_1(ver 1.0)
Obj_2(ver 1.0)
Obj_3(ver 1.0)
Now before this 1.tpz is imported in PRD few more changes happend to Obj_3 and I exported again a file say 2.tpz
Now this 2.tpz has only Obj_3(ver 2.0)
Now the basis has by mistake Imported this 2.tpz file before importing the 1.tpz file. SO in my PRD the object Obj_3 is existing with a advance version i.e 2.0
Now my doubt is can we Import 1.tpz now in PRD and then again import 2.tpz ?
I am having a feeling that we will definately get in version conflict. Even if I ignore the warning during transport and go ahead with this procedure of importing 1.tpz and then 2.tpz again, will it impact my scenarios.
I am lookign for a quick suggestions.
Regards,
Rahul.

Hi Rahul,
If you import V1 file first & later V2, it will not impact on your scenarion & you wil be able to see latest object in PRD.
But V2 is already imported so import of V1 may not be successful.
You may generate a new export if possible & transport this. It should include all object with their lastest version.
Regards
Sushil

How to upgrade labview version 7 to version 8

Hi,
1. I wish to know how to upgrade labview version 7 to version 8?
2. If I save my VI under labview 7, how can I run in labview 8 and back to labview 7. What are the steps needed?
Ridwan

Yes, the option that Mike is speaking of is called File » Save for Previous Version ....
LabVIEW 7 files will automatically open with LabVIEW 8, you don't need to do anything special.
Kameralina
Ask NI (ni.com/ask)
Search The KnowledgeBase
NI Developer Zone
Measure It. Fix It. ni.com/greenengineering/
NI Vision ni.com/vision/

XI 3.0 Version Conflict after SP 10 import

My XI 3.0 integration builder shows a version conflict for IDOC adapter meta data after we have implemented support package 10.
What needs to be done ?

Hi Peter,
We have this issue as well. not sure it is too much of an issue though.
Cheers
Colin

Driver/LabVIEW version conflicts

Similar Messages

Maybe you are looking for