LabVIEW

cancel
Showing results for 
Search instead for 
Did you mean: 

Running VIs developed on a 32-bit LV PC on a PC with 64-bit LV

Are there likely to be any problems with the above scenario, especially with code that uses mostly VISA functions to control and monitor hardware that is connected through USB ports?

 

I'm developing code on a 32-bit LV system at home that is intended to run on a 64-bit LV laptop at work.  Both computers are running 64-bit Win 10.  The code seems to run fine at home but throws VISA errors at work.  The programs will eventually be compiled once they are proven out.

0 Kudos
Message 1 of 17
(1,399 Views)

LabVIEW is always compiled.

What are the VISA errors you get? Are all the correct drivers installed?

0 Kudos
Message 2 of 17
(1,391 Views)

Curious why you can't install LV 64-bit at home as well?  LV 32-bit can exist quite happily alongside LV 64-bit.  Just make sure you re-install all needed drivers so they can become aware of the new LV.

Bill
CLD
(Mid-Level minion.)
My support system ensures that I don't look totally incompetent.
Proud to say that I've progressed beyond knowing just enough to be dangerous. I now know enough to know that I have no clue about anything at all.
Humble author of the CLAD Nugget.
0 Kudos
Message 3 of 17
(1,363 Views)

I'd say the issue is more likely due to the two computers being configured differently than the LV bitness.  Unless you have dlls that are being called then it gets dicey if, for instance, the 32-bit dll and the 64-bit dll have different names, or you don't have one or the other.  Sometimes you don't know dlls are called if they are buried deep in a 3rd party LV instrument driver.

Bill
CLD
(Mid-Level minion.)
My support system ensures that I don't look totally incompetent.
Proud to say that I've progressed beyond knowing just enough to be dangerous. I now know enough to know that I have no clue about anything at all.
Humble author of the CLAD Nugget.
0 Kudos
Message 4 of 17
(1,362 Views)

@billko wrote:

Sometimes you don't know dlls are called if they are buried deep in a 3rd party LV instrument driver.


Then it would be not throwing VISA errors but simply load as broken code.

If they are really VISA errors it’s almost certainly not caused by bitness differences but by computer differences such as a different ASRL port used but it’s hardwired in the code. Without knowing what those ominous VISA errors are we can however keep guessing until the end of all times.

Rolf Kalbermatter
My Blog
Message 5 of 17
(1,354 Views)

@rolfk wrote:

@billko wrote:

Sometimes you don't know dlls are called if they are buried deep in a 3rd party LV instrument driver.


Then it would be not throwing VISA errors but simply load as broken code.

If they are really VISA errors it’s almost certainly not caused by bitness differences but by computer differences such as a different ASRL port used but it’s hardwired in the code. Without knowing what those ominous VISA errors are we can however keep guessing until the end of all times.


Dang I only have until 3:30 to make my guesses.

Bill
CLD
(Mid-Level minion.)
My support system ensures that I don't look totally incompetent.
Proud to say that I've progressed beyond knowing just enough to be dangerous. I now know enough to know that I have no clue about anything at all.
Humble author of the CLAD Nugget.
0 Kudos
Message 6 of 17
(1,302 Views)

@altenbach wrote:

LabVIEW is always compiled.

What are the VISA errors you get? Are all the correct drivers installed?


What I meant by not compiled is that I haven't run the code through the Build Application to create an EXE file yet and am just running the VIs and sub-VIs interactively with LabView 2019.

 

I am communicating with 3 devices - a cDAQ 4-slot chassis with an NI-9485 (SSR) module, an eDAQ conductivity probe (through USB) and a Rigol DP-832 power supply, also through USB.  Mainly, I'm getting Arg 1 errors in a VISA Scan from String function when I try to read the voltage or current values on the Rigol DCPS.  I've moved VIs and sub-VIs back and forth between the two computers as I fiddle with the code on other computer and that's why I wondered if bitness of the LV installation could be an issue.

 

There are no problems with the NI-9485 code.  Both the eDAQ and Rigol devices had sample code available but it was more complicated than I needed so I basically recreated the routines for each from scratch using the example code.

 

I'm attaching the basic DCPS code here in case wants to take a look.  I only use LV casually so please don't be too hard on me.  I'm very open to constructive criticism, though,

Download All
0 Kudos
Message 7 of 17
(1,275 Views)

@billko wrote:

Curious why you can't install LV 64-bit at home as well?  LV 32-bit can exist quite happily alongside LV 64-bit.  Just make sure you re-install all needed drivers so they can become aware of the new LV.


I can install whatever I like at home.  I have 32-bit LV 2019 there now as the LV documentation somewhere seemed to encourage 32-bit unless a lot of memory is needed and these applications are pretty undemanding.  Our "helpful" IT department installed 64-bit on the work laptop without bothering to ask anyone what was wanted. They've been a royal pain to deal with all along, especially with the pandemic as they work from home now. 

 

Are there any tricks to replacing 32-bit LV on my home system with 64-bit LV?  Any chance of losing some key feature in the swap?.

0 Kudos
Message 8 of 17
(1,274 Views)

@billko wrote:

I'd say the issue is more likely due to the two computers being configured differently than the LV bitness.  Unless you have dlls that are being called then it gets dicey if, for instance, the 32-bit dll and the 64-bit dll have different names, or you don't have one or the other.  Sometimes you don't know dlls are called if they are buried deep in a 3rd party LV instrument driver.


So far as I know, there are dlls from 3rd party LV instrument drivers in my programs.  They were all created from scratch using standard LV functions and were based on looking at sample code provided by the instrument manufacturer.  I uploaded example of some of the VIs in my reply to another responder in this thread.

 

FWIW, Rigol actually recommended *against* using the sample code they supply as a download and suggested that I use that code as a basis and roll my own.  The Rigol DCPS uses SCPI commands and the eDAQ conductivity probe uses simple text commands.

0 Kudos
Message 9 of 17
(1,270 Views)

@rolfk wrote:

@billko wrote:

Sometimes you don't know dlls are called if they are buried deep in a 3rd party LV instrument driver.


Then it would be not throwing VISA errors but simply load as broken code.

If they are really VISA errors it’s almost certainly not caused by bitness differences but by computer differences such as a different ASRL port used but it’s hardwired in the code. Without knowing what those ominous VISA errors are we can however keep guessing until the end of all times.


The VISA resource names are different on the two computers and I always check that all VIs are using the proper VISA resource name when running code on each computer.

0 Kudos
Message 10 of 17
(1,267 Views)