I suppose also if you switch to software in-band flow control, (XON XOFF) instead of hardware flow control, then the bits would just go into "never land" if the device is not connected.

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.

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.

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". ;-)

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!)

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...