CVI serial comms program does not work with a serial to USB adapter

[Margaret Wilkerson]

We want to use an FTDI based serial-to-USB adapter, using the vitual com port provided by the driver, to connect a USB port to an RS232 port on a device. This does not work using the standard ComWrt() and ComWrtByte() functions. The data received by the device is corrupt: some blocks of the data have been sent twice. The problem is not in the FTDI driver because we have written a similar program in Microsoft Visual C using the Windows SDK comms API and this works perfectly.

I am using CVI v5.5.1 and Windows 2000.

Is this a problem in CVI or the way we are using CVI's functions?

[src75082]

I just tried this with a FTDI USB to RS232 adapter that I got yesterday, and I don't seem to have any problems.

I am using CVI 7.1.1, but I would be surprised if it didn't work the same in 5.5.

I wrote a simple test program, which I have attached. I threw it together, so you have to change the #defines to set the com port, baud rate, and number of iterations to test.

I tested it with a serial loopback adapter, to eliminate other sources of errors. You can either buy one for about $5, or build one using this pinout: http://www.airborn.com.au/serial/rs232b.gif

I was able to test mine successfully all the way up to 921600 baud.

[src75082]

By the way, the USB TO RS232 converter that we are using is the US232B from Saelig (www.saelig.com). It uses the FTDI FT232BM (425-1) chip.

[src75082]

I was just able to reproduce exactly what you are seeing.

I was playing around with my test application, to make sure that the serial port would work on com ports above 4 (which it doesn't by the way... I guess I need a different comm.drv), and I noticed that after I changed the serial port from COM3 to COM4, I started getting errors. The input queue was reporting that it was twice as long as it should be.

The problem seemed to go away after a reboot (I guess you need to reboot whenever you re-assign the COM port, even though it doesn't tell you to), but I left my test running while I was doing other things (like just scrolling up and down in CVI, or clicking around in the editor, or even opening the windows "start" bar) and I started seeing the double length buffer again.

If I let the test program run without touching the mouse, it passes, but as soon as I start doing other things, it fails.

I attached a newer version of the test program with some added error handling.

[src75082]

Just thought I would give an update, in case anyone else is playing along. 🙂

I can run the exact same test on the COM ports on my motherboard at 115.2k, and I never see an errors, but when I try the same thing on the USB to RS232 adapter at 115.2k, I consistently see errors when I move the mouse while the application is running.

I have tried different US232B's, but I get the same results, so it is not just faulty hardware in the one I'm using.

It looks like I get the double buffer error when I am at speeds above 115.2k, but at 115.2k, the error I see most of the time is that the input buffer is empty when I check it.

I'm going to try and find a different brand of USB to RS232 adapter around, and see if I get the same results.

Also, I am now able to get the COM ports above 4 to work. I'm still not sure why it wasn't working before, and I haven't really changed anything. I think it may have just needed a reboot before.

[src75082]

I tried this with a Prolific USB to RS232 adapter, and it didn't get any errors from my test program, but it would crash XP about every third time I tried to run my test program (blue screen of death saying the prolific driver was the cause).

I also tried my application with a Silicon Labs USB to RS232 converter (CP2101 chip), but for some reason, it always locks up on trying to open the serial port. It works fine under hyperterminal, just not with CVI.

Has anyone been able to successfully use a USB to serial adapter with the CVI serial library, and if so, which adapter did you use?

[src75082]

I've done some more testing with the FTDI adapter, and it looks like some of the things I was considering as errors before, were not truly errors.

The USB adapter seems to behave a little bit differently than a UART on the motherboard, in the fact that if you check the output queue on a UART on a motherboard immediately after doing a write, you will always be able to see that the data is still there. With a USB to RS232 adapter, this is not always the case. You have to keep in mind that the USB transfers can take a little while, and by then the UART sometimes has a chance to propagate the data from the output queue to the input queue. With this in mind, I now ignore the error if the output queue is empty when I check it. If the data truly is missing, I will catch it when I check the input queue.

After ignoring the output queue errors, I no longer get any errors when I set the baud to 115.2k. The help for the RS-232 Library also lists 256k as a valid baud rate, and I see no errors there either. The help also states that " You can use nonstandard baud rates. All baud rate values are interpreted literally by the comm driver.", which would lead me to believe that I can also use any baud rate supported by the driver, but when I try 230.4k, 460.8k, or 921.6k, I start seeing duplicate data sporadically.

Can someone at NI, or elsewhere, please verify whether or not nonstandard baud rates (or baud rates above 256k) are supported by the RS-232 Library?

Thanks in advance.

[Margaret Wilkerson]

I have also been experimenting further and am, if anything, more confused than before.
We bought some new USB to RS232 adapters, still using the FTDI chip, and they seemed to work OK.
So I retried the original adapter, and that now works. I'm fairly sure I've not changed the driver (FTDI version 1.00.2154.0), but something is obviously different.
I would be be interested to hear any comments on this.

[src75082]

I did some more testing yesterday, and I figured out why the Silicon Labs adapter wasn't working. I had configured 2 stop bits when I was testing the other UARTs, and according to the data sheet, silabs doesn't support 2 stop bits. Once I changed the setting, it started working. I still see sporadic problems when I have hardware handshaking enabled, but with it disabled, I left it running over night at 921.6k baud and had no errors.

When I use the same settings on the FTDI version, I still see duplicate data. I don't see the errors all of the time. Sometimes it takes a while before I see any errors. I haven't seen any errors at all when the baud is 115.2k, and I rarely see errors at 230.4k. The higher the baud rate the more likely the duplicate data errors are. I also see the errors more when I am doing other things at the same time. If I start the test and don't touch the computer, I don't see as many errors.

Margaret, what baud rate are you using?

[Margaret Wilkerson]

I have only tried to use 115Kbaud, as that is the speed we usually use for comms with devices.
I don't use hardware handshaking, or XON/XOFF, and I always use 8 data bits, 1 stop bit, no parity.
Do you have any ideas why you somtimes get duplicate data, and sometimes not?