In PR #132 , the read_status function for the PrawnBlaster was modified to (indirectly) use serial readlines instead of readline. This is good for error checking and mitigates potential issues with serial buffers not being fully emptied if status returns an error instead of the status. Unfortunately, readlines relies on a timeout to determine when to finish reading, and is thus potentially slow. Since the timeout is set to 1s in the current BLACS worker, users might experience the slow scenario.
For reasons I do not understand, this issue seems to vary somewhat between setups. I was unable to recreate it with a simple PrawnBlaster + PrawnDO + camera test setup, but my lab's main machine experiences it reliably.
I see two potential straightforward fixes:
- Change
readlines to False in the send_command call within read_status.
- Decrease the timeout of the serial connection to something smaller (10ms would be as responsive as the code intends if we remove the wait in the
transition_to_manual loop.
Option 1 has the drawback of potentially not handling errors being returned in response to status. In principle, this should never happen, and I think it would require rebooting the PrawnBlaster if it did.
The main downside of option 2 that I foresee is the possibility of spurious timeouts. This might depend on USB bus utilization, so it could be difficult to predict.
In PR #132 , the
read_statusfunction for the PrawnBlaster was modified to (indirectly) use serialreadlinesinstead ofreadline. This is good for error checking and mitigates potential issues with serial buffers not being fully emptied ifstatusreturns an error instead of the status. Unfortunately,readlinesrelies on a timeout to determine when to finish reading, and is thus potentially slow. Since the timeout is set to 1s in the current BLACS worker, users might experience the slow scenario.For reasons I do not understand, this issue seems to vary somewhat between setups. I was unable to recreate it with a simple PrawnBlaster + PrawnDO + camera test setup, but my lab's main machine experiences it reliably.
I see two potential straightforward fixes:
readlinestoFalsein thesend_commandcall withinread_status.transition_to_manualloop.Option 1 has the drawback of potentially not handling errors being returned in response to
status. In principle, this should never happen, and I think it would require rebooting the PrawnBlaster if it did.The main downside of option 2 that I foresee is the possibility of spurious timeouts. This might depend on USB bus utilization, so it could be difficult to predict.