TxTimeout

Sets a transmit timeout.

Available at design time and runtime. Can not be changed while the port is open.

Important - The default value for this property is 0 (zero) no timeouts are used. Do not change this property unless you understand the implications. However, if the .ParallelEnable property is enabled then timeouts are handled automatically by the parallel thread so this TxTimeouts property will be ignored.

Only available with Comm32. Not available with MSComm32

Syntax object.TxTimeout = value         object Name of the communications control.         value A numerical value in the range 0 to 32000 Measured in ms (1000 = 1 seconds)         Examples object.TxTimeout = 0 '// TxTimeouts are disabled     object.TxTimeout = 500 '// Set the TxTimeouts to 50ms       '// Output functions will return after 50ms '// even if all tx data was not sucessfully '// transmitted. Unsent data is disgarded

Remarks:

This property is only used when ParallelEnable=False.

When the ParallelEnable property is False all output properties and functions are Blocking. They return only after the bytes have been successfully transmitted or after the period specified by the TxTimeout property.

A TxTimeout of 0 (zero) means that the output properties/functions never timeout. Control returns to the calling process only after all bytes have been successfully transmitted.

Here's an example in vb code.

Comm1.ParallelEnable = False
Comm1.TxTimeout = 0
Comm1.PortOpen=True
Comm1.Output = "Hello World - this is a string of text "
DoSomethingElse

' Because ParallelEnable is False it means that the next line of code is only reached when the Output
' is completed.

Under some circumstances that would be desirable. For example if you needed to send a number of separate packets of data or needed to call some other function but did not want to do anything at all until you knew that the Output had completed successfully.

That example works so why have a TxTimeout property at all ?

If transmission was blocked by flow control then the above example would appear to hang. It would block until flow control allowed the transmission to complete. In most cases that would only be a moment and you would not notice. But, if the remote device had crashed or held flow control for an extended period then you could hang forever. But if you set a timeout then you know that in the worst case you will regain control after the time out period.

Unless you're happy to handle this yourself we would suggest you ignore timeouts by setting ParallelEnable=True (enabled) But if you do need to do something like our above example then you should set very short time outs and use the .WriteBytes and .WriteString properties to send data. These two functions will return a value giving the number of bytes that were sent so you will know if a timeout occured. For example - if you used WriteBytes to send 20 bytes and the return value was less than that then you will know that a timeout occured and some bytes were not sent. You can then retry the transmission for the remaining bytes. (Remember, the MSComm compatible.Output property does not have a return value so you would not know how many bytes were sent - if any)

Here's another example

Comm1.ParallelEnable=False
Comm1.TxTimeout = 100
Comm1.PortOpen=True
n = Comm1.WriteString("Hello World - this is another string of text ")
DoSomethingElse. . . .

' You would expect the string to be sent successfully before the next line in the program is reached
' but you set a 100ms timeout just in case. You can now check the variable n which tells you how
' many characters were sent. If it's less than expected then you know a timeout occured and can retry
' the remaining characters.

See the page describing pros and cons of OverlappedIO