FTDI USB-RS232 converter

[PA-Paul]

Hi All,

I have an FTDI USB-RS232 (FT232R) converter chip in my "system" to enable control of a serial device over usb. In general, it works fine, in labview I'm just treating it as a standard serial device (Using the device's "virtual com port" drivers) through VISA.

However, the default driver settings for this device include a 16 ms latency. I need to send a set of commands as quickly as possible to the device, so I want to set this to a more reasonable 2 ms. I can do this quite happily through the device manager, but I can't really ask/expect an end user to do that! One way I've found to solve this is to create a custom version of the drivers with the default latency set to 2, but that also causes me some minor issues as the drivers are then no longer certified etc etc and it would be much nicer if the user could simply install the standard drivers (especially incase FTDI change the drivers in the future).

So, I wanted to find an alternative... I discovered that FTDI do have a set of labview "drivers" for the product, which appear to allow me to do such things. I can happily communicate with the FTDI device using these and do things like find the currently assigned COM port number (which is nice!) and I can set the latency. The problem is as soon as I close the connection with the device to let VISA take over and deal with the communication, the setting seems to revert to the driver default of 16 ms.

I have traced the problem to VISA - if I open a connection to the device using the FTDI drivers, set the latency, close the connection, re-open the connection and check the latency, the value is maintained. If, however, I open the connection with the FTDI drivers, set the latency, close the connection, open the port with VISA, close the port with VISA and then recheck the latency, it's reverted to the default value.

Does anyone have any experience with these devices and know if there's a way of actually programmatically modifying the driver or making sure VISA uses the last settings I sent the device?

I suppose my only other alternative is to ditch VISA for this and re-write my application (or at least my device drivers for the thing I'm controlling) using the FTDI dll based code... but I'm not so sure that's such a great idea.

Any help or advice would be gratefully received!

Thanks

Paul

[alexwarrior]

Hi Paul,

I've been using the FTDI chips for quite a while. With the virtual com port driver, you can pre-set the latency timer to something other than 16ms in the ftdiport.inf file before installation. I believe there's also a Windows registry value that you can get at for changing the value without going into the Device Manager after installation. A couple of app notes on FTDI's website will hopefully help:

This one talks about latency and modifying the inf file before installation:

http://www.ftdichip.com/Documents/AppNotes...LatencyFlow.pdf

And this one mentions some registry keys you can try:

http://www.ftdichip.com/Documents/AppNotes...s_AN_000073.pdf

Good luck!

- Alex

[Minh Pham]

can you have this check and/or set the latency timer at the begining of your application?

I would use the FT_GetLatencyTimer API to see what is the current value of the timer then based on the returned result I will

continue running my application or set a new value (of 2) for it using FT_SetLatencyTimer API. Include this state somewhere in the begining of the statemachine, and let the application taking care of the customize settings rather than force the driver or user do it.

Just a thought.

[PA-Paul]

Hi All,

Thanks for the replies.

I originally did use the "modify the driver" approach, but then I have to supply a modified driver with my system and make sure its up to date if FTDI release new drivers for future versions of windows etc etc. Which is what I wanted to avoid.

Minh - The problem with your suggested approach is that as soon as I close the device using the FT API "stuff" in order to use VISA, the setting is lost. I emailed FTDI and was told the problem with the device "losing" the setting I set with the FT_SetLatencyTimer subVI was that that VI uses the D2XX driver version whereas the VISA communication is done through the VCP (Virtual COM port) driver, hence the reset to default values. FTDI suggested either using a modified driver file or modifying the registry entry.

Ultimately, I've gone for the latter approach now. So at the beginning of my application, I check the registry entry for the driver settings, if its not set to what I want (2ms), I modify the key in the registry (I can do this now I've found labview's registry editing VIs!). Obviously, for each machine I should only have to write the registry value once (per FTDI device, since the registry key is device specific), but I guess its still best to check it on each run of the application.

Thanks again for your suggestions!

Paul