Ruby/SerialPort Library is slow/delay/portions on Windows

Hi

I was doing serial port reading software with Ruby and Ruby/SerialPort
Library on Windows. I noticed that port reading works but with delays or
jitter when data from serial port comes, reading works in portions. In
reality, data comes twice per second but Ruby software detects data and
shows data only in portions. It means, at some particular time, there is
no data even if it is actually arriving on port. Then, occasionally, the
data comes all together for all the time when it was expected as one
single portion. And then data receive stops again. Point is the data
receive is correct, there is no lost data os something like that. But
Ruby software simply does not detect data at the time when it arrives.
It detects the data some time later and it combines the data arrival
into one portion, and until the portion is full, it simply does not
detect any data.

This is strange thing happens only on Windows XP, on Linux everything is
fine.

Serial software is typical with threads as given in example included
into Ruby/SerialPort Library package.

I did not build library for Windows XP by myself. I took it binary. For
Linux, I took binary as well.

Does anybody has a clue why it works differently? How possible to avoid
that delay or data delivery in portions? Is this Ruby threads issue on
Windows?

Thanks in advance
chelex

Does anybody has a clue why it works differently? How possible to avoid
that delay or data delivery in portions? Is this Ruby threads issue on
Windows?
Does eventmachine do anything with serial ports?
-=R

Roger P. wrote:

Does anybody has a clue why it works differently? How possible to avoid
that delay or data delivery in portions? Is this Ruby threads issue on
Windows?
Does eventmachine do anything with serial ports?
-=R

I do not use eventmachine in my code. It does not have any GUI, just
simple console software. As far as I know, serial port library is also
mostly C software just with bindings to Ruby. But still, there is some
sort of buffering effect which exists only on Windows. Linux variant
works absolutely smoothly.

On 8/20/08, Alexander C. [email protected] wrote:

Does anybody has a clue why it works differently? How possible to avoid
that delay or data delivery in portions? Is this Ruby threads issue on
Windows?

But still, there is some
sort of buffering effect which exists only on Windows. Linux variant
works absolutely smoothly.

It does sound like a buffering configuration problem. Under Windows,
the driver is responsible for maintaining a buffer for incoming data.
It’s possible it won’t notify windows that data is ready until it has
reached a certain size. You can specify the recommended size through
the API. The ruby/serialport lib hardcodes an incoming buffer size of
1024 - to change that you’d have to recompile. But it may make no
difference since according to MSDN: “The device driver receives the
recommended buffer sizes, but is free to use any input and output
(I/O) buffering scheme, as long as it provides reasonable performance
and data is not lost due to overrun”.
Another place to check the driver buffer sizes is in the Windows
Device Manager under Ports/Properties/Port Settings/Advanced.

The other thing you might try is changing the read_timeout value. The
lib is using a blocking read call, so given ruby’s thread
implementation on Windows, that will block your whole program. From
the docs, it seems like a timeout of -1 (return immediately) is what
you want, but you may try a small positive value too - at least one
newsgroup post suggested that was the best fix.

Hope this helps
-Adam

I do not use eventmachine in my code. It does not have any GUI, just
simple console software. As far as I know, serial port library is also
mostly C software just with bindings to Ruby. But still, there is some
sort of buffering effect which exists only on Windows. Linux variant
works absolutely smoothly.
If you’re not afraid of experimenting then you could try it
[EventMachine is just a ruby library].
http://rubyforge.org/pipermail/eventmachine-talk/2008-January/001567.html
-=R

This forum is not affiliated to the Ruby language, Ruby on Rails framework, nor any Ruby applications discussed here.

| Privacy Policy | Terms of Service | Remote Ruby Jobs