driplineorg / driplineorg/dripline-python
Timing issue in ethernet_SCPI_service
- Dominant language
- Python
- Stars
- 3
- Forks
- 6
- PR merge metrics
- No merged PRs in 30d
Description
The `_reconnect` function in ethernet_SCPI_service (see [here](https://github.com/driplineorg/dripline-python/blob/main/dripline/implementations/ethernet_scpi_service.py#L72)), 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.
Contributor guide
No contributing guide indexed for this repository
Assessment
This issue has not been assessed yet.