Serial buffer size at PC?

[Beagles]

Hi!

I have a question regarding the VISA Bytes at port. I am using Labview 7.1 and utilizes serial communication.

"Bytes at port" shows how many bytes there is in the incoming buffer (correct??).

My questions is about how much buffer size Labview "lends" from the PC to this function, ie. how much of the RAM is used for buffering on, lets say, an ordinary PC??

I am getting bytes up to app. 9000-10 000 in my "Bytes at Port", which leads me to the question that maybee the buffer can be overun?? Is that possible, or has Labview that in mind????

I am using a baudrate of 115200 kbps now, but would like to increase the speed to app. 200 kbps. The hardware I am using is a USB Bluetooth dongle for receiving, so the PC looks at this as a COM port.

Kind regards Peter

[LuI]

Beagles,

serial comm on a desktop OS involves some 'tricks' to be reliable. The serial data on such a machine is received by a chip called UART, that has a defined buffer of between 16 to 256 or even more bytes. This buffer can be filled with a baud rate of 230kBaud within 0.6 to 11 ms. When the UART buffer reaches a given filling limit, the UART raises an interrupt. In the ISR, the OS copies the data from the UART buffer to a system buffer. When the limit is -say- 80%, such an ISR is raised every 0.5 to 9 ms.
Normal user apps, one of which is LabVIEW, can not reach those short latencies reliably, so they could just reach serial data in the system buffer only (this is where 'bytes_at_serial_port' checks).
I had a system working with 13 serial ports, each of them running at 230 kbaud. I do not remember what the default size of the system buffer was. But I do remember that I could set it to a value of 32766 (2^15 - 2). This gave room for more than 1.5 seconds before LabVIEW has to remove (read_serial_port) data to prevent the serial buffer from overrun. This is fairly enough and can be handled easily with a proper program design in LabVIEW.
A proper program design in this circumstances means, that you should divide your app into a receiving part and a storing and maybe a processing part. The receiver should just do that and provide the data by means of a queue or socket or so to the other parts. A storage part should just stream the data to disk, if necessary. Depends on the importance and amount of your data and the stability of your system. The processing part (which includes even a raw viewer if necessary) should run at lower priority. If your machine is quick enough to handle everything, than this would be done as well. Otherwise the receiver is higher prioritised and you'd probably not loose data.

HTH and
Greetings from Germany!
--
Uwe

[Jimmie_A.]

Hello Beagles!

I believe that Uwe answered your questions in full detail, an excellent answer.

If you have any further questions just post them here (if they are related that is).

Regards,
Jimmie A.
Applications Engineers, National Instruments

[Beagles]

Wow!

That was a good lesson Uwe, thanks a lot!

Just couldn´t believe that the buffer wouldn´t last enough for my "small" application : ). So you are saying that if one will fill the buffer to fast, that is sending data to the UART fairly quickly, that fills the UART buffer so fast that labview won´t have "time" to do the interupt request in the same speed that it should...so when the UART buffer is filled...bytes will be lost that is written to the UART but not taken care of??? Labview can only check the system buffer at that point??

But I am not quite with you when you say that expanding the buffer (system buffer) would help when the UART is still having the same size? Of course the system buffer would take more bytes, but the byte buffer size in the UART is still the same right??

If one would like to change that buffer size, where would that be?? E.i the one that you mentioned, that could be in a size up to 32766 (bytes or bits??).

Hope you can bare with my confusion 🙂

Many stupid questions, but it would be nice to see how I could change this desktop PC to work with the same hardware but still be able to read in data in the speed that I need!

Thanks again for all the help!!

Kind regards Beagles

[LuI]

Beagles,

thx. Just some clartifications:
1. LabVIEW or any other application mode program could not keep up to be an ISR (for allmost any interrupt). This is due to the fact that those applications run in a context (layer3) where direct HW access is not allowed. An ISR need direct HW access and can run just in layer 0 of the OS. A change between layers can be just one step and takes some time. So no chance.
2. That leads to the implementation of device drivers. Those run entirely in layer 0 and can access the HW directly and very quickly. For serial comm, there is a device driver in the system that acts as an ISR and copies data fom the UART to the system buffer (which is located in the RAM) and vice versa.
3. With LabVIEW, you can configure just the system buffers size to (in my case) up to 32766 Bytes. Depending on the LabVIEW version you may use a vi named 'Serial Port Init.vi' or on newer LV versions the vi 'VISA Set I/O Buffer Size'.
4. The LabVIEW node 'Bytes at serial port' checks the content of the system buffer only. But as the ISR copies data from the UART to the system buffer within parts of ms, this is sufficient even for fast baud rates.

Again, one of my apps runs 13 serial ports with 230 kBaud full speed _simultaneously_ on a rather old PC now, some PII/300 MHz or so.

HTH and Greetings from Germany!
--
Uwe

[hellolv]

Hi,

My RS-485 communication always runs fine in the beginning then goes unstable.  If I know exactly what I should receive, how do I set or flush the buffer?


hellolv

[Dennis_Knutson]

duplicate post

[LuI]

Set buffer is answered above.

Flush buffer: just read everything!

Greetings from Germany!
--
Uwe

[usman.arif]

Hi

Its been very informative discussion, but i had a confusion, that if the PC buffer for serial port data gets overflow and our labview  program dont read it, then buffer would wait to be read or it will overwrite the data by new incoming data at serial port??

[crossrulz]

I beleive the data is overwritten and you get an error (or at least a warning) about a buffer overflow.