Timeout behavior changed between version 1.10 and 1.11

[GoogleCodeExporter]

Transport.ReadTimeout and Transport.WriteTimeout changed between version
1.10 and 1.11 from  1000 msec to -1 (I assume this is Infinite).  The
effect is that a call to write or read never fails by default.  Manually
changing read and write timeouts resolves the issue.

Original issue reported on code.google.com by nathan.t...@gmail.com on 12 May 2009 at 10:56

[GoogleCodeExporter]

Yeah, this was a change that I regretfully had to make to support the .NET 
Compact Framework. Several implementations of the CF do not support timeouts; 
the 
properties exist but accessing them causes an exception to occur.

A little more background - The 1.10 behavior was to initialize the read/write 
timeout values to a 1 second if the provided transport object’s (SerialPort, 
TcpClient) timeout was equal to Timeout.Infinte (-1). Obviously this won’t 
work 
for implementations of the CF which don’t support timeouts. I thought about 
using 
a preprocessor directive to only initialize default values when targeting the 
CF 
but by that time the default value initialization strategy started to bother me.

All other settings specific to the underlying transport are controllable by the 
underlying object (e.g. SerialPort BaudRate). A user should expect to be able 
to 
create a SerialPort object, set a timeout value to Timeout.Infinite (-1), pass 
it 
to a ModbusMaster factory method and have those timeout values preserved.

Therefore I ended up deciding to make the change to put the onus of timeout 
initialization on the user.

I should have been more up front about the breaking change. Hope this didn’t 
cause you too much trouble.

Scott

Original comment by sja...@gmail.com on 12 May 2009 at 11:46

[GoogleCodeExporter]

Original comment by sja...@gmail.com on 12 May 2009 at 11:47

• Changed state: WontFix

[GoogleCodeExporter]

Thanks for the explanation.  I was able to find the problem by browsing the 
source
code.  This is an excellent project.  Thanks again.

Original comment by nathan.t...@gmail.com on 13 May 2009 at 12:45

[GoogleCodeExporter]

Should Modbus.Modbus.DefaultTimeout be marked as obsolete as it is not used 
anywhere?
This caused me some confusion until I read this posting.

Original comment by Daniel...@gmail.com on 23 Oct 2009 at 5:26

[GoogleCodeExporter]

Good idea, I will reactivate and fix.

Original comment by sja...@gmail.com on 23 Oct 2009 at 8:34

• Changed state: Accepted

[GoogleCodeExporter]

Original comment by sja...@gmail.com on 15 Nov 2009 at 6:24

• Changed state: Fixed

[GoogleCodeExporter]

So what exactly happened to this? Modbus.Modbus.DefaultTimeout is still 
present... is this deprecated or did you continue using it? The obsolete 
decorator is there but these  comments are unclear...

Original comment by pugglewu...@gmail.com on 2 Jul 2014 at 8:35