Timeout behavior changed between version 1.10 and 1.11 about nmodbus HOT 7 CLOSED

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

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.

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