This is the number of milliseconds that the port scanner waits for a reply before concluding that there is nothing connected. It seems very short to me.
My test setup is a virtual null modem and a simple modbus slave simulator. Usually it is plenty fast, but I cannot get reliable detection of the slave simulator unless I increase this number significantly. I would imagine you might hit the same problem out in the real world.
Increasing this number will slow the scanning, but make it more reliable.
A couple side issues:
The define has some source documentation. On my screen it is unreadable gibberish.
The first check for devices on a port involves broadcasting a read query. This is repeated 9 times and any error or inconsistency in the first value returned on the last 3 read attempts cases the port to be rejected. Was this the intention? Or was it intended to check the return from all 9 reads? If the latter, then there is a missing break after the flag is set to false on line 2934 of file T3000_Building_Automation_System\T3000\TStatScanner.cpp
I realised that my modbus slave simulator was polling at just 1 Hz. When I increase the polling to 10Hz, the T3000 COM port scanner works reliably with a latency of 60 milliseconds.
This is the number of milliseconds that the port scanner waits for a reply before concluding that there is nothing connected. It seems very short to me.
My test setup is a virtual null modem and a simple modbus slave simulator. Usually it is plenty fast, but I cannot get reliable detection of the slave simulator unless I increase this number significantly. I would imagine you might hit the same problem out in the real world.
Increasing this number will slow the scanning, but make it more reliable.
A couple side issues: