Labview with FTDI D2XX drivers?

[htram]

You can use the "VISA Resource" drop down box and you can select your device from a list of all available devices in your system (COM, LPT, GPIB...)

[echarry]

Hi all,

Hopefully this thread is still alive. I added another post about FTDI problems with the ft2xx.dll but apparently in the wrong forum (VB6). Didn't get a response so far.

Anyway, first of all all I need to know is if what I am doing is right or not: I want to reverse-engineer the communication between a proprietary application and a FTDI-based device.

Would it be possible to create a wrapper DLL in Labview (which obviously uses the same function callers than the original FT2xx.dll), but create a trace in each VI so that I am able to see the order and the parameters of each function?

I have downloaded the LV drivers in the FTDI website and created the DLL, through which I can call the functions in Labview. However when I open the proprietary app I get the error: "Can't find entry point FT_Get_Status in FT2xx.dll", and the applications obviously doesn't work. I imagine that the way LV exports the functions is slightly different. I changed that particular function to "standard calling conventions" during the build, but still didn't work.

Any light? Is is possible to do this?

Thanks,

Edgar Charry

[Julio_HDT]

hi, im usin ft245 to, could you post an example, I've tried with the exmaple of FTDI i can receive data from device to pc, but i can order correctly the data, thanks 

[sydbarrett]

I support BlueTwo; my experience is not to use 'FT Read String Data' VI. It never worked fully for me (sometimes it did and sometimes it did not leading to hours of frustration) - all sorts of strange results including returns from the function indicating the correct number of bytes had been read but nothing in the output string. I thought I was using it incorrectly until I found this thread. I conclude that FT_Read cannot handle strings correctly. As BlueTwo says, use 'FT Read Byte Data'.

Alternatively, edit 'FT Read Byte Data' and simply insert the 'Byte Array to String' on the 'Data bytes' indicator and pipe that to another indicator. I also added a 'Handle out' indicator to make things more VISA-like and help data flow sequencing (edited VI attached). I did not have any problems with 'FT Write String Data' but avoided this function as well (alternative attached based on 'FT Write Byte Data'). I am using LV v10.

I was happy using the VCP and VISA/VISA-serial but found no way of automatically detecting the USB-serial converter port requiring ugly user interaction. So I changed everything to the D2XX solution - a pain to change all the port functions but automatically detecting the port is now satisfactorily slick. (Coming from the VISA solution, I started to use the 'FT Read String Data' VI initially and discovered problems with it.)

More testing to do but this seems to have solved my problems for now...

[Hoss183]

Old thread resurrection..

I've been using the D2xx labview driver/Vi on a test system, and i have a problem thats driving me crazy.

On my first develeopment PC (HP 8440 laptop, Win XP 32) everything was fine. I develped a test system talking to a board with USB-FT245BM, in Labview(2010) & Teststand (2010).

But when i came to deply the system to another laptop (XP) it ran much much slower (10x).

Then i deployed it to a desktop macine (Win7) same story.

I've run diagnostics and determined that on my origial machine the FT_Write fucntion is taking 2ms to execute and over 100ms on other PCs!

I've compared drivers (ok win 7 are diff versions than XP), hardware etc but no luck.

Any ideas? 

[myle00]

In what mode are you using the device. I have worked with the FT232R in c on different computers and never noticed any differences. However, I used bit bang modes and I can probably help you more if that's what you're doing.

First, which version driver do you have? Go to FTDI's website and make sure you have the latest drivers (.14) for each computer. Can you test the program in a c environment to see if you see these delays in there as well?

To me, the extra 100ms sounds like a timeout issue. That is, the latency timer might be set incorrectly to a large value and you're not writing with large enough buffers so the chip sits and waits for more data until it times out. Try changing the latency timer to smaller values and see if it persists. These docs talk about latency. http://www.ftdichip.com/Support/Documents/AppNotes/AN232B-04_DataLatencyFlow.pdf http://www.ftdichip.com/Support/Documents/AppNotes/AN232B-03_D2XXDataThroughput.pdf

Matt

[Hoss183]

Hi,

I'm reading & writing bytes with FT_Write_Byte.vi (uses FT_Write function) and FT_Read_Byte.vi

I dont have any easy way to program in C. (My C experience is limited, mostly embedded stuff)

Yes all PCs were using 2.8.14.0.

I also noticed a new beta today (2.8.17.0 and have tried that, but no improvement)

Latency timer only seems to apear in the VCP mode. I actually had 'load VCP driver' disabled as i just use the direct .vi to D2XX calls. But enabling it, and checking the settings, latency timer is set to 16, and min timeouts 0, they seem to be defaults.

I tried it lower, no noticable effect.

.... any more ideas?

[Julio_HDT]

hi, what kind of method do you use to stop data transfer in labview???

[Hoss183]

How do you mean? Those fucntions send & recieve a byte, thats it.

If you mean closing the port, then i use FT_Close.vi (which calls FT_close function) before exiting my application.

[myle00]

What mode are you using? I.e. do you bit bang or do you use its serial port functionality? Also, the latency timer definitely has an effect in d2xx mode, at least with the FT2232H and FT232R because I tested those. There's a FT_SetLatencyTimer function and VI to do that.

If you wish, I can make a small exe in c that times writes. However, you'd have to tell me a bit more about how you use and initialize the FT_ VIs so I can replicate it in c. Keep in mind, that I have a lot of experience with the bit bang mode but not that much with serial modes.

It might be helpful anyway if you elaborate a bit more on the parameters you use to set up and then write to the device. I mean like how many bytes you write in one ft_write/read call etc. because otherwise it's hard to tell if you're doing something wrong. You should read the pdfs I linked to because they might help you.