LabVIEW

cancel
Showing results for 
Search instead for 
Did you mean: 

FDTI (FT245BM)

Hi all,

i have some trouble with using the externel DLL of the ftdi chip. I need
some advice how to impelemntate the ftd2xx.dll.

All i found out yet is how to call a function but every time i send
something i got wrong parameter type Errorlevel back

FT_listdevice ( PVOID pvArg1, PVOID pvArg2, DWORD dwFlags)

pwArg1&2 depends on dwFlags So i create the symbol and create a string
input for dwFlags a NULL String for pvArg2 and a string output for
pvArg2. But all i get is a errorlevel output, invalid Parameter ...


I hope some off you know what to do here.


thanks
Andreas
0 Kudos
Message 1 of 8
(8,285 Views)

Hello Andreas,

You may have better luck finding people who have worked with this DLL at the FTDI Home Page. From their support page they have links to web boards specific to USB development.

The following link should be of help in calling external code in LabVIEW.

Using External Code in LabVIEW

Please let me know if you have any questions specific to external code calls in LabVIEW.

0 Kudos
Message 2 of 8
(8,282 Views)
Hello,

I´ve the same problem.

Is somebody her who have the solution??

Thank you
0 Kudos
Message 3 of 8
(8,261 Views)
The FTDI site has example Labview programs here:

http://www.ftdichip.com/Projects/CodeExamples/LabVIEW.htm
0 Kudos
Message 4 of 8
(8,209 Views)
Hi,

I encounter a specific problem when using the functions from D2XX.DLL to communicate to the FT232BM USB->Serial chip.

I use in my programs a SubVI which passes all the communication to and from the USB chip, 'USB_Send_Receive.vi'. In that VI first a dll function 'Open' is called, which returns a Handle used in subsequent Read and Write calls, and at the end of the VI the dll function 'Close' is called which releases the Handle. That all works fine.

The problem is that frequent calls of the 'Open'->'Read/Write'->'Close' sequence slow down my main app appreciably. (The slowing doen is by a factor 10 in my top level measurement program). Since the repeated Open/Close is not necessary in principle, I changed the 'USB_Send_Receive.vi' to perform an 'Open' only on first call and store the Handle in an uninitialized shift register. No 'Close' is perfomed. That also works fine, but only as long as the VI is kept in memory. When it is released from memory, later reloaded and started again, the VI will call the 'Open' function from the dll which now returns an error,(probably since the last handle has not been cleared by a 'Close' call). That does not happen when LabVIEW itself is released from memory, so obviously releasing LabVIEW does more cleanup with the used dll than just releasing the VI using the dll.

I don't know how to proceed here and try to find help in this forum.

What I tried already is this:
I stored the handle (which is a 32 bit integer) aquired by a successful 'Open' call in a file and reused this value later after releasing, reloading, restarting the VI. That also failed (knowing the handle obviously is not the same as 'owning' the handle).

What I will try next is to call the 'USB_Send_Receive.vi' with some flag telling it to release the handle when it is no longer used. I don't like that solution, though, since it shifts the responsibility of rleasing the handle from the VI which aquires it to a higher level VI.


What I ideally would like to have is a sort of 'On Exit' function in Labview, which is called automatically when a VI is removed from memory (i.e. the counterpart of an automatic initialize code). AFAIK this is not implemented yet, so I'll put it on the LV feature wishlist for the future...


Franz
0 Kudos
Message 5 of 8
(8,182 Views)

I have trouble using the VIs made available from FDTI.


I got "Invalid handle" from status of FT_Open_Device_By_index.vi

 

If, instead, I use only FT_Open_Device_By_index the device is recognized properly.

 

I attach my VI.


Thanks in advance

 

 

Message 6 of 8
(7,398 Views)

OK... it works now...device has to be configured in synchronous mode (non asynchronous)....

 

Only an issue..Once stopped the VI the next run (sometime) I must unplug and plug again the USB...to get a valid handle (different than 0).

 

Any hint?

 

Thanks in advance

0 Kudos
Message 7 of 8
(7,385 Views)

Andreas;

 

I too, have that chip.  I wrote the package at:

https://sourceforge.net/projects/serial-gpibnicl/ 

I tried to stay with the NI-GPIB library function calls, I also include VIs that go with it.  I've tested it with Linux, not with WinXP.

 

FYI:  The NI-GPIB routines such as ibwrt()  are included in the basic LV runtime, I had to do a bulk re-name to call my DLL instead of the LV runtime DLL.

 

   ...Dan
 

0 Kudos
Message 8 of 8
(7,378 Views)