Siglent: Improve SetADCMode reliability under slow/unstable network connection

[hansemro]

Setup

• Arch Linux
• scopehal-apps (45d255de8795bf5cf62054145907fcb5a022a104)
• SDS2004X Plus connected via lan and lxi
  • Hardware revision: 05-05
  • Tested versions:
    • v1.5.2R3

Issue Description:

SetADCMode currently uses thread sleep to ensure sufficient delays between commands. However, 200 millisecond delays do not propagate well enough under slow/unstable network connection which may result in the :WAVeform:WIDTh command failing to execute.

Increasing the delay is one option, but not foolproof.

[azonenberg]

You're using SendCommandQueued(), which writes commands to the FIFO but they don't get flushed to the instrument until FlushCommandQueue() is called on the transport or a SendCommandQueuedWithReply() call is made. So you're racing the GUI thread against ScopeThread which may be in the middle of AcquireData() and not flushing write side data.

If exact timing is important, call FlushCommandQueue() before the sleep to ensure the first command is actually pushed out the socket.

[azonenberg]

The whole point of the queued command API is to avoid the GUI thread blocking on ScopeThread unless absolutely necessary. So instead of locking the mutex and waiting for an in progress AcquireData() call - usually pretty slow - to finish., it simply locks the queue mutex, writes the command to the queue, and returns immediately even if the socket is busy.

[hansemro]

Makes sense. Thanks for explaining. I will look more into this.