Intermittent USB Serial Read Glitches (only appear in labview)

[millonas]

I'm trying to do serial reads from an FT232R USB UART device manufactured by FTDI. The settings are 115200 baud, 8 data bits, 1 stop bit, no parity, XON/XOFF flow control. I have also tried both software and hardware handshaking and those appear to make no difference in my problem. I’m using an FTDI library, FTDI vi’s that make calls to the library, and the basic plan of their example Labview programs which all can be found here if anyone if anyone is interested

http://www.ftdichip.com/Support/SoftwareExamples/CodeExamples/LabVIEW.htm

When the output of the device is read by a serial terminal program such as the PuTTY terminal (http://en.wikipedia.org/wiki/PuTTY) everything works correctly, no glitches or anything. When I read the serial data in labview (see attached main, subvis and .dll) everything works perfectly as well, but every once in a while there is a “glitch”. The application spits out a line of data every 250 ms, and this line is read off by a timed loop with the same interval. The glitch takes a peculiar form, at least to me – I’m very new at USB serial communications with labview.  The lines of data, complete with and end of line \r\n will scroll down the “screen” nicely if using a terminal program. In this case each good line is 30 bytes. The “glitches” occur about every 30-100 lines, at random as far as I can tell. A “glitch” stretches over 2 or more lines.  When the glitches occur for 2 or 3 (or 4) lines the individual waiting buffers read are not 30 bytes, but when you add up the total number of bytes transferred during the glitch it is always a multiple of 30. Not too weird. As it turns out there is no “missing” data, also not too weird.

HOWEVER, the weird thing is that what is happening during these glitches is that either a single byte, or often a sequence of connected bytes are “cut and pasted” from  one place in the data stream either forward or backward in time. It seem like this also can happen multiple times in “one” glitch. I include a .txt file with several of the glitches so you can see what I mean by this. I paste just one of these here as an example:

1 44027 45633 2 47596 41210

1 44031 45640 2 47589 41211

1 44029 45633 2 47586 41209

1 44029 45642 2 47589 41209

92 41209

1 44027 45640 2 4751 44029 45635 2 47596 41210

1 44028 45636 2 47593 41210

1 44028 45621 2 47586 41209

1 44026 45633 2 47588 41210

1 44030 45635 2 47591 41209

The first and last 4 lines are normal. The glitch is the middle 2 lines. While the individual 5 digit numbers in the lines vary, they don’t by much and usually it is possible to figure out what happened. In this particular case the end of one line, complete with the new line chars, got cut off and transposed BEFORE that line. The next line was ok, but without the new line it appear attached. I have color coded this to make it easier to see.

The glitches are pretty impossible to parse/repair in an automated way.  I post this in the hopes that someone with more experience in USB serial communications w/labview might have a clue what is going on here.  BTW, I also tried just reading one byte at a time and this appeared to make absolutely zero difference in the problem. I’ve been searching the NI forums and website, and otherwise googling this one for a few days. Perhaps I don’t know the right key words, but I haven’t been able to glean anything enlightening.

PLEASE HELP is you have some idea of what is going on here!

[Dennis_Knutson]

So, do you also have the virtual com port driver installed as well? That is what PuTTY would be using if you are able to select 'ComX'. Check to see if the port is listed in device manager and MAX (make sure VISA is installed). If it is,  just use the regular serial functions in LabVIEW. That is all that I have ever used and never saw a problem. Your approach is pretty uncommon. What made you choose it? With your method, you would be forced to always use a USB-Serial converter with the FTDI chip set instead of anyone that was handy.

[millonas]

The FTDI device is listed in both widows and max devices.  The FTDI chip uses the ftd2xx.dll driver (included in my original attachments). Is that what you meant?

Unfortunately I have no control over the communication hardware - that is one of the boundary condition of my work.  I'm a technical consultant with a Ph.D. in Physics, not Computer Science, but I gradually got drawn into doing the whole project myself in Labview. My main job is what to DO with the data, and that is a very complex one. I would have liked, frankly, to simply have had the data provided to me on a silver platter so I could focus on the "hard" stuff. LOL. I didn't want to waste my time on coding up a new serial interface, which was not something I knew much about. But I agree this approach is now seeming more and more attractive.

[Dennis_Knutson]

No, the device does not use the ftd2xx.dll driver unless you purposely choose to use it. The standard way of using a USB-RS232 converter is with the serial VISA functions because the VCP driver from FTDI is installed. Start by looking at the serial examples. There should be no difference between LabVIEW and PuTTY because then you would be using the same driver.

You might also want to provide the make and model of the instrument you are trying to communicate with. You might find that there is existing code for it.

[millonas]

A I mentioned, I DID choose to use it. Yeah, I should have done it with VISA first. I just wrote a VISA-based reader. My first reaction (beyond "damn! Should have done it this way first!") was that it was working perfectly, but glitches do show up, but not nearly as often at all. Here is an example of one (butr it ran for like 5 minutes without any of these.

1 44090 45676 2 48910 41006 6 50551 39263
1 44088 45685 2 48936 41008 6 50551 39264
08 6 50551 39262
1 44093 45682 2 48918 4101 44091 45683 2 48944 41008 6 50551 39263
1 44089 45684 2 48938 41009 6 50551 39263
1 44091 45683 2 48932 41008 6 50549 39263

I've attached by simple vi. I probably need to put in some "close" commands etc., but it works. Do these glitches make sense now? Any suggestions?

[millonas]

OK, the attached is a bit better coded, but still has the same glitches.

[Dennis_Knutson · Accepted solution]

One thing you are doing is using both the termination character and the VISA Bytes at Serial Port. I would not recomend this combination. If the instrument is sending a CR/LF, just put a large number constant for the number of bytes to read. VISA Read will automatically terminate when the LF is detected.

You'll also want to be careful about memory useage. The concantanate string with the shift register can create a pretty long string if used for a while.

[millonas]

YUP! That fixed it. Thanks so much.  Final vi that works attached.

Roger on the concatenate .  That was just a quick and dirty way to visually parse the data. It doesn't appear in the real code.

[Albert.Geven]

Hi

Why are you using a timed loop?

The timing is determined by the serial read so no reason to use a more difficult loop than a normal while as far as I know.

[millonas]

This isn't the whole prorgams, of course. The new data only appears every quarter second, and the computation on the data is very intense. The results and display of the data (and other data being collected at the same time through other channels)  have to be finished by the end of each 250 ms - so in sync with the data.  I wanted to make sure that the data is always collected first (at the beginning of the loop), and then the computation on the new data is data performed. I didn't want any looping serial calls, and NO extra "wait" functions if possible. This appears to work perfectly in this regard. If there is a better way to do this I'm all ears. 

At the completion of the computation performed in each loop I get a readout for the percent of the time in that loop use up by all computation, and so get an idea of the computational load. if it can't complete all the computations with time to spare in the 250 ms then there will be trouble. I obviously don't want any kimd of continuously looping serial reads, and puttting in a wait is no good because every ms counts in this application. I suppose there were a few other ways to do this, but if this works then it would be the most efficient.