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

(No comment was entered for this change.)

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

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

Good idea, I will reactivate and fix.

(No comment was entered for this change.)