RS232: Read port delays

[csi04]

I am sending a command from my PC to a unit using RS232 port. Using the serial snooper, I saw that the unit responds with a ACK within 4 msecs everytime. However, my read routine loops for "atleast" 100 msecs before it finds the ACK. I have configured a timeout of 30msecs and I am doing a read only when I see there are non-zero # of bytes at the port. Why is it taking me so much time to see the ACK?

Thanks,
sam

[shoneill]

Something to try would be to check the buffer settings for the serial port in your operating system (Windows I presume?).

These buffers are, to the best of my knowledge, controlled by the operating system and your program will see the data only after the OS has decided to process the buffer. Try setting the buffer size to a smaller value and see if your responsiveness improves.

On another level, if you're only reading when byates are present, what timeout have you set to 30ms? If you mean the read timeout, this will have no influence on the speed when not reading.

Hope this helps.

Shane.

[Shawn B.]

Shane,

You are right, in the windows device manager under port settings, advanced, you can set the size of your FIFO buffer for your serial card. If you set this this to a low number for example 1 the OS will set an interrupt every time you receive a byte. This means your LabVIEW application will get the byte right away. However this usually requires a lot of processing power to remove 1 byte at a time from the FIFO.

If you set this to a large number like 14 the interrupt will be set when you have received 14 bytes, or the OS decides to check if there is information in the FIFO. This means you might not get your data right away, but it will require less CPU usage since you computer can grab 14 bytes at a time.

Shawn B.
National Instruments

[shoneill]

Is using the "flush serial buffer" VI a viable alternative? Does this force Windows to pass on the contents of the receive/transmit buffers?

I've always had this in my programs (flushing the read buffer before reading and flushing the transmit buffer after writing), but I don't actually know how effective it really is.

Shane.

[Shawn B.]

Shane,

I assume you are talking about "Flush I/O Buffer". This does not do the same thing, as changing the FIFO size in windows. Changing the FIFO size in Windows controls how often VISA will check to see if new data has arrived. By setting it to a smaller value you ensure you receive your data promptly, but it also means that VISA will be constantly removing byte by byte from the FIFO.

The "Flush I/O Buffer" flushes, and discards the data. It basically erases all data that is in the FIFO waiting to be sent, or read into the OS. If you flush the buffer then do a read, you will only receive data that arrived after the flush.

Shawn B.
National Instruments

[shoneill]

As far as I know, that's incorrect.

When running the flush I/O buffer, you can specify whether or not the contents are to be discarded or not.

The VI is located under "Instrument I/O"-"Visa"-"Advanced"-"interface specific"-"Flush I/O Buffer"

I've translated from the german version, so some names may differ in proper english.

In the help file associated with this VI it states "Maskieren (16) bezeichnet den zu entleerenden Puffer. Beim Entleeren des Empfangspuffers (16) wird der Inhalt verworfen, während beim Entleeren des Ausgangspuffers (32) abgewartet wird, bis der verbleibende Inhalt des Übertragungspuffers an das Gerät gesendet wurde. Verwenden Sie (64), um Die Daten des Empfangspuffers zu verwerfen. Verwenden Sie (128), um alle restlichen Daten des Übertragungspuffers zu verwerfen."

You may realise this as not being English. A rough translation is , set input 16, the transmit buffer is emptied (discarded). Setting 32 will empty the transmit buffer, without discarding. It waits until (forces) the contents of the buffer is transmitted. The further text is not clear to me, stating that (64) discards the receive buffer, whereas (128) discards all other data. I've always assumed this is a typo, and that 128 causes no data loss. Maybe this is my mistake?

Personally, I find this a good way of regaining control of the serial buffer for sending data at least.

Can someone else maybe give the english version of the help file a look and share with us what it says there?

Shane.

[Shawn B.]

Shane,

Sorry, you are correct, mask 32 Flushes the buffer by writing the data to the device. I guess I should read the help a little closer! Here is what the English version says about the mask:

mask designates the buffer to flush. Combine the buffer masks by bit to flush more than one buffer simultaneously. Use logical OR, also known as OR-ing or adding, to combine the values.

Mask Values Hex Codes Description
16 0x10 Flushes and discards contents of the receive buffer.
32 0x20 Flushes and discards contents of the transmit buffer by writing all the buffered data to the device.
64 0x40 Flushes and discards contents of the receive buffer.
128 0x80 No I/O to the device.

Even the English version is a little unclear, and will be updated in the next release. 16, and 64 both do the same thing, discarding (erasing) the receive buffer. 32 and 128 are for the transmit buffer. 32 flushes the buffer by sending the data to the device, and 128 flushes the data by erasing it (No I/O to the device). You should only combine 1 receive mask with 1 transmit mask. For example you should not combine 16 and 64.

Hope this clears things up!

Shawn B.
National Instruments

[shoneill]

While we're on the subject, would it be possible to get this function to properly flush both directions without data loss in a future release?

I personally always thought this was what was going on. I shudder to think how often I've used this wrongly.

Thanks

Shane.

[Shawn B.]

Shane,

You can always provide product suggestions by going to www.ni.com, clicking on the Contact NI tab, and then selecting the feedback link.

Shawn B.
National Instruments