in reply to Write timeout, in perl Win32::Serialport

If you take a look at the Configuration and Capability Methods section of the Win32::SerialPort documentation, there are subsections on "Asynchronous I/O" and "Timeouts" (just before the Exports section). You'll want to check out write_const_time and write_char_time. I think those sections will help you with the timeout stuff.

I mean I want to stop the write command if the other side is empty. Now if i am trying the write command and the other side is inactive or I just plug out the cable the software freezes out.

Perhaps I'm misunderstanding what you're trying to accomplish, but it sounds like you're also needing/wanting some method to detect that the connection is broken (i.e. the serial device is off or disconnected) and to gracefully handle this without locking up your script. You can easily check the success of opening a new connection, but I'm not sure that I would know how to determine that the serial device has dropped the connection. It's been a few years since I wrote something using Win32::SerialPort and I don't think that I had thought about checking for this scenario.

Replies are listed 'Best First'.
Re^2: Write timeout, in perl Win32::Serialport
by Marshall (Canon) on Feb 20, 2012 at 04:25 UTC
    I haven't used this particular Perl module, but I've had some experience with RS-232 devices before. This is, in general, a "painful process".

    There are some control signals, like CTS (Clear-To-Send) and RTS (Request-To-Send) - these are actual hardware lines between the 2 devices. They control whether or not you are able to send or receive a new characters.

    In the "modern era", it is usually better to use in-band flow control because the hardware chip doing the RS232 will have at least 16 bytes of buffer.

    If I'm not ready to receive more info, I will send a "shut up" command, an XOFF. Your RS232 chip is still sending stuff while my IC is sending that, but there is enough buffer for me to get additional characters while you are thinking about it. Modern RS232 chips are smart and process this "shut up" message quickly.

    This does not appear to be a problem in this case, but most USB to serial port devices do not handle the normal RS232 signals correctly. Some do. "Most don't handle correctly" does not mean "all do not" - this is a "heads up" - that many do not.

    To confound this whole business further, In the "beginning of time": computers talked only to modems. Now computers talk to computers and this really complicated the terminology. A "null modem cable" is sometimes required. This just swaps the transmit and receive pairs of these hardware flow control signals.

    Anyway if we are using software, in-band flow control instead of CTS,RTS, then if you are "not there" my sent bits will just go to the "bit bucket" because you are not there telling me that I cannot send. I don't get "hung up on the transmit" part. The "time-out part" happens on the receive at my end.

    It appears to me that the OP is using Hardware Flow Control (the CTS,RTS hardware lines).

    Program hangs on the "write" because there is not a CTS (Clear-To-Send) hardware signal (a specific line on the RS232 interface) from the other side. But the article I mentioned explains how to time this out. It was written in 1999. The advice as written appears to me to be still good although the use of software flow control is much more prevalent a decade later.

    AN OFF TOPIC - OH My GOSH!
    Some cheapo computers only use +5V for a "psuedo RS-232" signal. RS-232 defines a "true" value as +12V not +5V! Some "cheapo" computers simply do not supply enough voltage on their "quote RS-232 ports" to be interfaced with compliant devices. Be aware of this - I've seen it.

[reply]
      AN OFF TOPIC - OH My GOSH!
      Some cheapo computers only use +5V for a "psuedo RS-232" signal. RS-232 defines a "true" value as +12V not +5V! Some "cheapo" computers simply do not supply enough voltage on their "quote RS-232 ports" to be interfaced with compliant devices. Be aware of this - I've seen it.

      Wrong. +5V is a perfectly valid RS232 voltage. The problem is (a) hardware that uses 0 V instead of -3V..-15V and (b) hardware that expects RS232 lines to deliver significant amounts of energy.

      RS232 is specified to use +3V..+15V and -3V..-15V. The range -3V..+3V is undefined. RS232 is not specified to deliver significant current.

      Legacy PC hardware is a completely different thing. Most PC "RS232" interfaces accept any voltage around 0V and below as negative (this does not violate the RS232 spec), and the outputs can deliver several mA at +/-12V, simply because the original IBM PC was build this way, and legacy hardware (mostly serial mice and barcode readers) expect this interface. Some "exotic" systems (e.g. early laptops) had a different line driver circuit that delivered only +/-5V and/or less current, this caused compatibility problems with hardware that expected +/-12V and high current, mostly serial mice. Never the less, the interface was implemented according to the RS232 spec, but the peripheral device was not.

      See also Re^2: Win32::SerialPort v. New computers.

      Alexander

      --
      Today I will gladly share my knowledge and experience, for there are no sweeter words than "I told you so". ;-)
[reply]
        I looked again at the RS232 spec and you are correct, a 3 volt swing would be enough.
        No, not right - transmitter needs at least +5V swing. A normal TTL output can't get there.
        Update: All hardware interfaces have a defined "margin of error". For me to send a "true" value there is a defined voltage level that must be achieved. There is a much lower voltage level that is required for you to "receive that true value". That is the "margin for transmission error". It is completely possible for me to send something to you that "by the books" is not a "true" level for me to transmit, but that you will accept as such.

        This is meaningless to the software folks here..strike.. If these wimpy guys could use an open collector output to get to the full 5V, then it would be fine. But then of course they could just tie that to the 12V rail also. And this would be able to source significant current at the logic "high" level. A standard TTL gate cannot source any significant current at a logic "high" level.

        This whole RS232 I/F stuff is fraught with "how its done" vs "how its spec'd" stuff. We could probably have a many page discussion about this...

        I'm saying that sometimes Box A and B who claim to be compatible, will not "talk". And that does happen. Last time for me was about 18 months ago - rather than buy a serial card and deal with the software hassles with that - the client elected to just buy a different computer. This "bad boy" RS232 computer just has a different job on the network.

        My point is that sometimes some I/F's won't talk to one another. I probably shouldn't have pointed this out, but I did. Its not the "normal" thing, but it can happen in practice.

        UPDATE: Geez what a messy looking post! Sorry about that. The bottom line is that sometimes 2 devices cannot communicate because their hardware just doesn't meet specs, even though they might yet be able to communicate with some other device. This is rare, but it does happen. That was the point.

[reply]
      I using RS232 TTL level driver, so yeah, the CTS and the RTS is not connected, but the signal level is totally good! I can't believe never exist a software method.... :S The connection initalize never make error just if the line is busy or already opened (I monitoring the line and if I open and send data some other software my program is make an error, but if the connection is bad, or the wire bad? NEVER!!! I cant believe it!)
[reply]
Re^2: Write timeout, in perl Win32::Serialport
by prody001 (Initiate) on Feb 26, 2012 at 09:33 UTC
    The article what your mention: I take some time, a lot of time to read it, before I wrote this qoestion, I don't know what to do this 2 register, but it Doesn't help me... :S I Can open the connection every time, when the cabel is not joined too. This is the problem...
[reply]

In Section Seekers of Perl Wisdom