LabVIEW Installer installs correctly on machines, but one machine is not executing the same as the others.

[malanskas]

I created a LabVIEW installer with LabVIEW 2017. I have installed the program on three machines (2 64 bit, 1 32 bit processor). The 64 bit machines run the program correctly, log all of the data, etc. The 32 bit machine seems to be running incorrectly and does not run the same as my dev station or the 64 bit machines. I have attached the VI if anyone can point me in the right direction. Thanks! I had to edit the setup.ini file to get it to install on the 32 bit machine, so I am wondering if that did anything?

[altenbach]

---

@malanskas wrote:

The 32 bit machine seems to be running incorrectly and does not run the same as my dev station or the 64 bit machines.

---

There are billions of ways to run "incorrectly" or "not the same", so you need to narrow it down for us. Can you describe what is happening? Any error messages?

[malanskas]

It initializes both devices (34401A DMM and SR630 Thermocouple Monitor) correctly over GPIB using the companies drivers. It starts the scan on the SR630 correctly as well. Once it enters the frame of running the for loop to read the measurements from the DMM, it does not run the For Loop in the 32 bit machine. The 64 bit machines will run that loop correctly to read the measurements and build the array of data. On the 64 bit machine, the for loop runs once (sometimes twice) and then stops for a while (a minute or so) and then continues. It will then not close either device correctly over the GPIB communication. The errors I am getting in my error out logs are from the device drivers. When I go to close the exe. on the 32 bit machine, I get this error message as well. access violation 0xc0000005 

[altenbach]

On a side note, you might want to cleanup your code. Is this really a mfg. written example (judging from the VI description) or did you modify it?  It has potential race conditions and blatant overuse of value property nodes and local variables for no reason. Why would you repeat the timeout case millions of times per second writing the same thing to the same indicator? Once <space> is pressed, it rattles down a long sequence structure while locking the front panel, then aborting the VI as last step. Crazy!

That entire thing could be done as a proper state machine fitting on a postcard!

[malanskas]

Currently just in development. Will be cleaned up.

[altenbach]

Are the drivers installed correctly on the 32bit machine? Same version?

What are the exact errors you get? (Quote: The errors I am getting in my error out logs are from the device drivers)

Let's look at the FOR loop:

• The pink shift register is just a glorified "last value" tunnel.
• The orange shift register just mimics autoindexing at the left boundary with way too much code.
• Calculating the wait should be done before the loop unless you expect these values to change during the loop. Same for the blinking and logging.
• All value property nodes should be local variables here (... in your mad architecture where you use hidden indicators are "variables").
• .... just the tip of the iceberg!

[malanskas]

I was thrown into LabVIEW with no experience really, so thank you for the pointers! Any help is indeed helpful. Was told to develop this in a day. All of the drivers are installed correctly on the machine

[Kyle97330]

• For the GPIB that you are using, what sort of GPIB connection do you have?
• Is it a PCI or PCIe card in the PC, or is it a USB to GPIB connection?
• Is it a GPIB device from NI, or from a 3rd party?
• If it's from NI, did you source it directly or from a reseller?
• Can you swap the GPIB hardware from the 32 bit PC to the 64 bit ones and back?
• Can you swap all the cabling or check that it's as secure as possible?
• What versions of GPIB drivers do you have installed (NI-488.2 or other, and what version numbers)?

The reason I ask all that is that is that given the code you are running, which does have all the problems Altenbach has highlighted, seems to all use standard VISA commands and not anything that ought to be bit-dependent in the code itself.  But with the access violation errors and other issues coming from GPIB nodes you mention, the GPIB system itself seems like more of a potential issue to me.

If you're using non-NI GPIB hardware, or GPIB hardware that looks like NI but might be counterfeit, that could be a potential root cause.  Non-NI hardware might have done a bad job making their 32 bit drivers, and if it's counterfeit it could also have driver issues on 32 bit but not 64.  GPIB hardware/cables do occasionally go bad too and it could be coincidence that it went bad on your 32 bit machine.

[malanskas]

It is a USB to GPIB connection from Keysight. 82357B model. 

[malanskas]

It is definately running into issues when I try and run the for Loop. Any idea how to maybe quick fix it?