LabVIEW

cancel
Showing results for 
Search instead for 
Did you mean: 

Project links to dll, different behaviours on different PCs

I have a very large LVOOP project that uses some very simple ADLINK IO, which I will never use again as it's no end of hassle.  However, I'm stuck with it for now as it's designed in to manufacturing equipment.

I moved from LabVIEW 2013 LabVIEW 2018 32-bit and I'm now debugging the issues.   The NI part is all working fine.  When I open the Project on the Win10 PC at my desk, around 25% of the ADLINK IO tasks are broken, a double-click on the DAQPilot ADLINK node on the diagram fixes the problem and the VI will run again without errors.  When I take the same project to another PC running Win7, which has the same drivers installed, the same nodes are broken again.  I've been trying to spot the difference for around 8-hours, and the only thing I've noticed is that shown in the attached snips.

It appears the search order on the Win7 PC is slightly different and it thinks the .dll is at the different path.

If I create a new project, then add just the Digital IO and nothing else, the Project will open on both PCs without errors.

If I fix the links with a double-click on the Win7 PC, then move back to the Win10 PC, it's broken again in the same way.  I've also tried renaming the unwanted path to try and force the search for the dll to the correct path, but that did not work.

 

Fundamentally nothing is broken as the IO nodes do move between PCs when not in the large LVOOP Project.  I must have links inside the large LVOOP Project that are deficient in some way.

 

How do I fix the links?

 

0 Kudos
Message 1 of 9
(2,343 Views)

Are both systems really 32-bit Windows systems? Because if not, the DLLs (which seem to only support 32-bit according to the small email snippet you show in one of the pics definitely got installed in the wrong Program Files location. They should be in Program Files (x86) on a 64 bit system.

Rolf Kalbermatter
My Blog
0 Kudos
Message 2 of 9
(2,335 Views)

both PCs are 64-bit windows and both running 32-bit LabVIEW.

I did some copy-paste of the DAQPilot folder between Program Files and Program Files (x86) in an attempt to get it working.

I will try renaming the DAQPilot folder in the Program Files folder, leaving only the Program Files (x86) available for the Project to find.

To be continued on Monday...

0 Kudos
Message 3 of 9
(2,328 Views)

The Win10 PC is running 64-bit windows and has LabVIEW 2018 32-bit installed.

The Win7 PC is running 32-bit windows and has LabVIEW 2018 32-bit installed.

I can create a Project with only some digtial IO present, and that project will move between the 2 PCs without any issues.  I therefore think it must be badly formed links in the large Project.

I've noticed that only the Win10 PC has a folder called Program Files (x86).  The Win7 PC only has Program Files.

0 Kudos
Message 4 of 9
(2,285 Views)

I actually have 3 different build standards on various PCs, I need the LabVIEW project to correctly link to DAQPilotLVPNP.dll on all 3.

 

Windows7 32-bit, LabVIEW 2018 32-bit.

Windows7 64-bit, LabVIEW 2018 32-bit.

Windows10 64-bit, LabVIEW 2018 32-bit.

 

Can anyone explain why the two trees look different:

Win10versusWin7.JPG

0 Kudos
Message 5 of 9
(2,282 Views)

On a 64 bit system, 32 bit software belongs into the "Program Files (x86)" folder. That is how Microsoft decided things to be and you can try jumping high and low but won't be able to change that without lots of pain like this. Basically even if you pass the "Program Files" folder without the (x86) postfix from inside a 32-bit application to Windows file functions, Windows will "helpfully" redirect the access to the 32-bit path and trying to circumvent that is more pain than gain.

 

So if your libraries were installed under Program Files (x86) on the 64-bit systems as they should be, you could leave the LabVIEW project to use normal Program Files paths and LabVIEW would still see the correct path.

 

Read this for a more detailed explanation what happens here.

Rolf Kalbermatter
My Blog
Message 6 of 9
(2,275 Views)

Thanks Rolf, link is a handy reference.

I've manually checked the location of DAQPilotLVPNP.dll for all PCs, LabVIEW should find it in the same place, and indeed it does with my simple project.

The large Project however, cannot link to DAQPilotLVPNP.dll when I move between PCs.  I've looked at the .lvproj file using a text editor, I just can't find any clues.

0 Kudos
Message 7 of 9
(2,264 Views)

Sometimes comparing the lvproj files from each setup helps you understand what is going on.

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 8 of 9
(2,262 Views)

Hi Bill, I've read some posts before about people manually editing the .lvproj file to fix linking bugs.  The path in .lvproj stays the same, I'm not editing anything, just trying to run the same project source code on each PC.

<Item Name="DAQPilotLVPNP.dll" Type="Document" URL="DAQPilotLVPNP.dll">

appears at the root of the project in the .lvproj text.

The screen snip above shows the file being found at C:\Program Files\Common Files\ADLINK\DAQPilot on the Win10 PC, but when I move to the Win7 PC, the files view in the Project windows is suggesting the file is at C root, however, there is no copy of DAQPilotLVPNP.dll at C root.

When you create the exe, LabVIEW automatically copies the dll to the data folder that sits with the exe. (DAQPilotLVPNP.dll is not in the always included list in build properties).

The installer of DAQPilot appears to put the components at the expected place on each PC.

 

0 Kudos
Message 9 of 9
(2,257 Views)