VISA Serial Loopback Speed and Accuracy with Dual Loops and a Queue

[MF]

I am working on a communication test between 2 PCs. I am testing the RS422 serial communication ports using a simple loopback. PC2 writes continuous data at 38400 baud to PC1 (LabVIEW test code resides here). PC1 reads the data and writes the data back on the same port as fast as it can. PC2 reads the data and compares to what should be returned. The highest speed I can get is a baud rate of about 37300. Becuase it is continous, eventually I get errors because the buffer (read and write buffers are 65kB) overruns.

It seems that the VISA write takes a lot longer than the VISA read. I am doing the read/write operations asynchronously. I read a fixed amount of data (1024 bytes) and then queue the data in order to write in another loop. My timeout is set to 0.5 seconds which is plenty opf time at 38400 baud (4800 bytes/second).I have played around with these numbers and they are about the best I can get. If I increase the data read to 2kB, the queue members increase. If I go too low, I start getting the data in the input buffer overrunning.

Has anyone had experience with this type of test? Attached is the code. Please take a look and see if I am doing things correctly.

Michael

[RavensFan]

Is the code on the other PC identical to this?

Where is the 1024 bytes of data initiated? 

Here you read 1024 bytes of data which it puts into the queue, (if the other PC hasn't sent anything, then an empty string gets put in the queue).

If there is something in the queue (by previewing it) then an element is dequeued (which is currently an empty string) and written out.  Which means nothing goes out if it is empty.

If the other PC is doing the same thing, where does the packet of data start?

Assuming one PC actually initiates a packet, I don't see how your buffer would fill up as you would essentially have one packet of data being sent from one PC back and forth chased around in circles.  Where is additional data coming from to fill up the buffer.

Even if both PC's initiate a packet of data, then it is just two packets chasing each other back and forth.

[MF]

Hello Ravens Fan,

Here is the scenario,

PC2 (not a Windows PC but an embedded PC) - writes continuous data (Perbs data, miscellaneous data, at 38400 baud). Its other purpose is to read any data sent to it and compare it to the data it originally sent. It matches it up and if the data is correct and at least sent at 70% of 38400 baud rate, test is a Pass. Otherwise Fail. The data that is read is not resent to the othe rPC, it is discarded.

PC1 (windows PC with LabVIEW on it) - set to read and write that is read out. It is in hold mode until the first data arrives then it is off to the races. If the queued item is an empty string, an empty string (i.e. nothing) is really written to PC2. I picked 1024 because it seemed to give good rates. If less than 1024 is available, it does not matter. A smaller string will be sent but since PC2 is just looking for data in a continuous stream, it is added to the stream and comparison continues.

So PC2 initiates the packets and because PC1 cannot keep up with reading and writing the packets where PC2 can keep up with writing and reading, the buffer on PC1 gets filled slowly (about 150-200 bps). If I run the test for an hour, my buffer gets filled. There is not one packet of data as PC2 creates new data continuously.

Michael

[RavensFan]

I don't know whether a VISA write would take any longer to execute than a VISA read.  I would think not, but I don't know and it is possible.  I would think that even if it took longer, since the reads and writes are executing in parallel loops, even if it took slightly longer, it wouldn't take so long as waiting for the next packet to write to arrive from the queue.  And that enqueueing process is being throttled by how long it takes to read 1024 bytes.  At a 38,400 baud rate, that is going to be about 3840 bytes per second (depending on parity and stop bits) or about 1/4 second.  So keep that in mind when comparing to a 1/2 second timeout.

A couple other things come to mind.  Since the one end is running on windows, is it possible that some windows processes are getting in the way such as a virus scan, hard disk activity, checking e-mail...  Windows is not a realtime operating system, so you can't guarantee a particular activity will occur on schedule.  I've seen plenty of times where a virus scan or something else seems to hang the PC for a second or two, much longer than the 1/4 second a 1024 byte packet of data would take.

Are you using any hardware or software flow control?  Back in the days when buffers were small and serial chips and baud rates were slow, flow control was needed to prevent things like filled up buffers.  Nowadays, in normal applications, flow control is very rarely needed because the buffers are larger, the chips are faster, as well as the PC's and OS.  Things run fast enough to keep a buffer from filling up.  But your application is kind of special in that you are trying to push the limits and 38,400 baud rate is a bit faster than typical.  So flow control might be needed.

You may want add some monitoring on both your receive and transmit buffers so you can see clearly how things are growing or shrinking as time passes.  You could also use preview queue with the return elements option turned on and watch how your queue fills and shrinks.  Even if you don't use hardware or software flow control at the port level, you may want to do something at the application level where if the buffer fills, you send a message to the embedded PC and tell it to slow down.  Or just flush the buffer and let the other PC know that you had to do that.

[MF]

I am attaching a simple vi that shows time it takes to write 12000 bytes at 9600 baud. For stop and start bits of 1.0, the character rate is calculated using 10 bits to transmit each byte. So it should take about 12.5 seconds for 12000 bytes (10 * 12000 / 9600 ). For a com port on the motherboard, I am getting this rate. For a com port through a Digi USB 1.1 Edgeport with 8 ports, I am getting 13.3 seconds. This rate holds for 38400 baud also. Eventually, I fall far enough behind that I get rate and data errors.

I know this is not the way that serial testing is done on a continuous basis but this is the way we are trying to do it in an automated tester.

Can anyone tell me what the trasmit buffer size is used for? The VISA write operation does not come back until the write is finished. I am working with a C programmer and he basically keeps the serial transmit buffer full and sleeps when he cannot write to the buffer. His operation wakes up when the transmit buffer becomes empty enough to write data to the buffer. Is there a similar technique in LabVIEW? Thanks for all the help.

Michael

[RavensFan · Accepted solution]

I don't know whether it explains a 0.8 second differential between what you are expecting and what you are getting, but you've added another level of complication by using the digiboard.  You don't have a real serial port, but a simulated serial port that is hanging off the end of a USB bus.  The digiboard's software is creating a virtual comport, and thus its driver software and the firmware on the board side of the USB bus has to handle some translations to go from a comport number, transfer over the bus, and decode the comport number so that it knows which of the 8 physical ports it needs to send the message to.  You may be seeing delays in the translation at each end as well something in the USB protocol itself where it must packetize the information.

If you have another, different brand of virtual serial ports you can use, you might want to try one of those to see if you get similar or different results.  But I don't think it is a good idea to try to test the limits of a serial communication device by using hardware that adds other layers to the communication protocol and thus complicates the results.

[Ben]

A couple of comments that may help or hurt.

instead of trying to read exactly 1024 bytes, use the property node ""Bytes at Port" prior to the VISA read and read only that number for the port. Whatever you read, write it back out.

instead of using the "Value property node" (that executes in the UI thread and therefore will either forrce the VI to execute in the single threaded UI thread or will require some thread swapping, read from a local or add explicit support for the stopping.

Over-all I have to side with Bill's suspicion about the USB adding delays. NI's USB hardware stuff seems to have a USB delay as well. I have also written apps that are basically very close to what you have porototyped but used SCRAMNet instead of the serial and i was able to update rates that were mainly limited by the macihne buss speed, so I suspect the USB could be an issue. make usre you are using USB 2.0 or better. If I understood correctly, USB can set up pipes that can be used to transefer data while USB 1.0 had to peek and poke.

Ben

[MF]

Hello Ravens Fan and Ben,

Thanks for the quick responses. I have come to the conclusion after trying in vain many different read/write methods with different number of characters etc. that the Edgeport USB 1.0 will not work correctly due to latency in the USB 1.0 bus conversions, etc. I have a couple of new options, get a USB 2.0 box (i saw this one http://microcontrollershop.com/product_info.php?products_id=3613), add delays in the hardware that writes data to my PC (I figure I can get 90% of the speed which should be ok), or go with a PCI/PCIe solution which gets the serial port into native mode. I give you both kudos for helping me from chasing my tail on this issue.

Cheers!

Michael