LabVIEW

cancel
Showing results for 
Search instead for 
Did you mean: 

DLL call problem

Solved!
Go to solution

Hello! I'm looking for help.

Following situation: We have a product with an USB chip from FTDI (ftdichip.com) with VCP/D2XX driver and years ago we made LabView VIs for the customers. These VI call DLL functions from a DLL file which in the same folder as the VIs, because you have to specify a rigid path in the LabView DLL call VI. This was easier to distribute. Back then, it worked on Windows XP and 7, also in the older LabView versions. Even without the DLL being registered to the system.

 

When doing the same today, on Windows 10 and let's say Labview 2015 or 2017, it doesn't work anymore. It means, the call does not return anything where it should. But the call also doesn't show an error, so I can only guess. The DLL is available as 32 bit and 64 bit, both are installed. The USB driver itself seems to be installed as 64 bit. So it may be necessary to use the 64 bit DLL on a 64 bit system. But on Windows 7 the system was also 64 bit, using the 64 bit driver and the 32 bit DLL function call and it worked.

 

What's your guess?

How to solve that for the future? Rather import the DLL as VI?

Would the imported DLL work on both, 32 and 64 bit OS, or would we have to make two VI versions?

Would the "DLL VI" work on older versions of LabView and if so, down to what version?

 

0 Kudos
Message 1 of 9
(5,641 Views)

I'd say everything works as designed (but the design might not be optimal).

 

+ The dll loads. If there is a problem with bit-ness of the dll (or dependencies) it would fail to load and you'll get a broken VI.

 

+ The .dll executes, and it returns no error (and doesn't crash). So there seems to be no problem. You could increase exception handling level so it returns less important errors as well. That might help but only if an error is returned. If not, it just confirms that everything is working as planned.

 

+ The .dll executes, and it returns no values. If the return value is 0, that could mean there is an error. If it's called "Success", it is expected to return 0 if the call fails.

 

So I don't think the anything needs to be changed in LabVIEW.

 

What should change is that the .dll needs a mechanism to give feedback about why it fails. If that's not possible, you might need to debug the .dll to watch what's happening.

0 Kudos
Message 2 of 9
(5,635 Views)
Solution
Accepted by MaSta

 

Thanks. The part with the DLL calls is solved. It's not the DLL call itself, but another problem in our VI which occurs when running it now on an newer OS and newer LabView, compared to back when it was made. I think we can solve this as well.

 

0 Kudos
Message 3 of 9
(5,620 Views)

HI,  Did you find a solution for this?

 

We are having the same issue. Code created years ago it was working fine until upgraded to LabVIEW 17. Also using the FTDI dll

I have run the same code in the same machine with LV16 and LV17 and using 16 works, using 17 doesn't. See below :LV16_vs_LV17.png

In LV16 I can successfully retrieve the COM port number but in LV17 it gives an error (Invalid Handle).

 

Is somehow different the way to call DLL on LV17?

 

Thanks a lot,

0 Kudos
Message 4 of 9
(5,521 Views)

 

The post has been solved, apparently it was not related to the FTDI dll at all. 

 


@Dominigomes
wrote:

HI,  Did you find a solution for this?

 

We are having the same issue. Code created years ago it was working fine until upgraded to LabVIEW 17. Also using the FTDI dll

I have run the same code in the same machine with LV16 and LV17 and using 16 works, using 17 doesn't. See below :LV16_vs_LV17.png

In LV16 I can successfully retrieve the COM port number but in LV17 it gives an error (Invalid Handle).

 

Is somehow different the way to call DLL on LV17?

 

Thanks a lot,


Are both LabVIEW versions the same bitness (32 or 64 bit)? There should not be much difference in the way 16 and 17 call dll functions.

 

Maybe 16 is started with administrator privileges and 17 is not? Or did you start 17 while 16 was still running? (Just guessing here). 

 

Do the CLFN return an error? That would give more information...

0 Kudos
Message 5 of 9
(5,500 Views)

wiebe@CARYA wrote:

 

The post has been solved, apparently it was not related to the FTDI dll at all. 



Apologies for that. i was not sure if I should open a new post. I can open it if it is a better practice

 


wiebe@CARYA wrote:

 

Are both LabVIEW versions the same bitness (32 or 64 bit)? There should not be much difference in the way 16 and 17 call dll functions.

 

Maybe 16 is started with administrator privileges and 17 is not? Or did you start 17 while 16 was still running? (Just guessing here). 

 

Do the CLFN return an error? That would give more information...


Both versions are 64 bit and both running with Admin privileges. I have tried to run it in all the possible configurations (First LV17 only, LV16 only, LV17 with LV16 opened, etc) and it is always the same result.

 

The CLFN does not return any errors.

 

I have been in touch with the FTDI technical support and they claim it must be a LV17 issue.

 

Any idea on what to try next?

0 Kudos
Message 6 of 9
(5,495 Views)

@Dominigomes wrote:

wiebe@CARYA wrote:

 

The post has been solved, apparently it was not related to the FTDI dll at all. 



Apologies for that. i was not sure if I should open a new post. I can open it if it is a better practice


The topic is the same, so you're not violating any rules. But a "solved" thread could get less attention.

 


@Dominigomes wrote:
Any idea on what to try next?

You might want to start a new thread. But please link to this thread (or that might be the first answer).

 

Note that you can improve on the title "DLL call problem". "FTDI DLL: works in LV16 but not in LV17" or something like that better covers the topic.

0 Kudos
Message 7 of 9
(5,489 Views)

@Dominigomes wrote:
 

I have been in touch with the FTDI technical support and they claim it must be a LV17 issue.

 


That is of course the easy way out. Reality is that there have been most likely very little changes in that part of LabVIEW so it's highly unlikely that a properly working DLL would suddenly stop working because of a new LabVIEW version.

More likely, the DLL (or the VIs interfacing to the DLL) always had a problem already, but for some obscure reason this error was masked by something in older versions of LabVIEW. Now the error surfaces!

Unfortunately, claiming that everything with a DLL is fine because it can be called in one version of a software is a very tempting but fundamentally flawed argument.

 

It's even very likely that it could still work with LabVIEW 2017 on other computers. But not having any hardware to test this we are pretty limited in what we can help here. FTDI support could at least download an evaluation version of LabVIEW and investigate on their side. 

Rolf Kalbermatter
My Blog
Message 8 of 9
(5,473 Views)