Timing issue in ethernet_SCPI_service

[renereimann]

The _reconnect function in ethernet_SCPI_service (see here), first checks for unprompted response via self._listen() before sending the command at reconnect to verify the connection.

At one device I have issues, where the timing of the messages is unfortune so that the self._send_commands is ignored by the device.
Apparently while sending the unprompted responds the device needs a tiny extra time to be able to receive requests via self._send_commands.
In case the self._send_commands is executed to fast after self._listen() returns, the device ignores the self._send_commands and the reconnect test is not succesful.

It has to be a timing issue, since if I execute the commands one after the other by hand, the process is successful. To allow for a tiny dead-time between sending the initial unprompted response and the first command to be accepted by the device, an additional sleep has to be implemented.
This can not be handled by the receive timeout since apparently the command is not recogniced by the device if it arrives to early.

While this is more an issue of the device a short sleep should not be harmful here. Since this only happens at reconnect, the overall delay should be minimal.

[renereimann]

    # Lantronix xDirect adapters have no query options
    if self.cmd_at_reconnect is None:
        return
    commands = self.cmd_at_reconnect[:]
    # Agilent/Keysight instruments give an unprompted *IDN? response on
    #   connection. This must be cleared before communicating with a blank
    #   listen or all future queries will be offset.
    while commands[0] is None:
        logger.debug("Emptying reconnect buffer")
        commands.pop(0)
        self._listen(blank_command=True)
        time.sleep(1)                                        ### extra delay ###
    response = self._send_commands(commands)
    # Final cmd_at_reconnect should return '1' to test connection.
    if response[-1] != self.reconnect_test:
        self.socket.close()
        logger.warning(f"Failed connection test.  Response was {response}")
        # exceptions.DriplineHardwareConnectionError
        raise ThrowReply('resource_error_connection', "Failed connection test.")

[renereimann]

The device that I have which results in the timing issue is a Pfeiffer CCT 362 vacuum gauge. In the documentation it states a response time of 60ms.

All other devices that I tested are Pfeiffer HTP200 which have a measurement cycle of 10ms. In these cases I do not need an extra delay.

For the CCT 362 with a response time of 60ms things are working fine if I put a delay of 0.07 s (=70ms).
It may be an option to make the response time / measurement cycle a configuration parameter but maybe 0.1s waiting should be fine as well.