The instrument may not have fully processed the original write before the error query arrives, which makes the fallback decision depend on command timing instead of a more reliable synchronization point.
Fix approach
Add a more reliable synchronization step before checking the error state, for example:
a small delay
an *OPC? poll
or another explicit command-completion check
Status
Still open.
Not fixed in the current v0.2 working copy.
### Problem
Sweep fallback currently depends on querying `SYST:ERR?` immediately after sending the first sweep command.
### Current code pattern
```python
err = self.i.query_retry("SYST:ERR?")
if not err.startswith("0"):
parts2 = [p.replace("WAV,", "SPAC,") for p in parts]
```
### Why this is a problem
This sequence can be timing-sensitive.
The instrument may not have fully processed the original write before the error query arrives, which makes the fallback decision depend on command timing instead of a more reliable synchronization point.
### Fix approach
Add a more reliable synchronization step before checking the error state, for example:
- a small delay
- an `*OPC?` poll
- or another explicit command-completion check
### Status
Still open.
Not fixed in the current v0.2 working copy.
tgohle
self-assigned this 2026-04-17 12:09:17 +00:00
tgohle
changed title from Sweep fallback from WAV to SPAC is timing-fragile to [Bug:] Sweep fallback from WAV to SPAC is timing-fragile2026-04-18 11:17:39 +00:00
tgohle
changed title from [Bug:] Sweep fallback from WAV to SPAC is timing-fragile to [Bug]: Sweep fallback from WAV to SPAC is timing-fragile2026-04-18 11:18:07 +00:00
This change removes the timing-fragile sweep fallback logic.
The old path decided between WAV and SPAC by querying SYST:ERR? immediately after the first SWWV write. In v0.2.2, the sweep write is now synchronized before the error check by using a command-completion step (*OPC?), and stale old errors are cleared first with *CLS. That makes the fallback decision depend on the result of the current sweep command instead of socket timing or leftover error state. The SDG programming guide documents *OPC? as returning only after the previous command has been entirely executed. :contentReference[oaicite:0]{index=0}
Tested on a real Siglent SDG2042X (*IDN? -> Siglent Technologies,SDG2042X,SDG2XFBC8R0225,2.01.01.38).
Regression test result for Issue #10 was successful: direct WAV and SPAC checks returned no error, the production-like helper passed, the stale-error-immunity test also passed, and the final result was critical tests passed: True. :contentReference[oaicite:1]{index=1}
Fixed in **v0.2.2**.
This change removes the timing-fragile sweep fallback logic.
The old path decided between `WAV` and `SPAC` by querying `SYST:ERR?` immediately after the first `SWWV` write. In v0.2.2, the sweep write is now synchronized before the error check by using a command-completion step (`*OPC?`), and stale old errors are cleared first with `*CLS`. That makes the fallback decision depend on the result of the current sweep command instead of socket timing or leftover error state. The SDG programming guide documents `*OPC?` as returning only after the previous command has been entirely executed. :contentReference[oaicite:0]{index=0}
Tested on a real **Siglent SDG2042X** (`*IDN? -> Siglent Technologies,SDG2042X,SDG2XFBC8R0225,2.01.01.38`).
Regression test result for Issue #10 was successful: direct `WAV` and `SPAC` checks returned no error, the production-like helper passed, the stale-error-immunity test also passed, and the final result was `critical tests passed: True`. :contentReference[oaicite:1]{index=1}
Archive location for this version:
https://gitea.togo-lab.io/tgohle/0003-SDG2042X-PyQt-GUI-for-Linux/src/branch/master/script/archive
Blocking a user prevents them from interacting with repositories, such as opening or commenting on pull requests or issues. Learn more about blocking a user.
Problem
Sweep fallback currently depends on querying
SYST:ERR?immediately after sending the first sweep command.Current code pattern
Why this is a problem
This sequence can be timing-sensitive.
The instrument may not have fully processed the original write before the error query arrives, which makes the fallback decision depend on command timing instead of a more reliable synchronization point.
Fix approach
Add a more reliable synchronization step before checking the error state, for example:
*OPC?pollStatus
Still open.
Not fixed in the current v0.2 working copy.
Sweep fallback from WAV to SPAC is timing-fragileto [Bug:] Sweep fallback from WAV to SPAC is timing-fragile[Bug:] Sweep fallback from WAV to SPAC is timing-fragileto [Bug]: Sweep fallback from WAV to SPAC is timing-fragileFixed in v0.2.2.
This change removes the timing-fragile sweep fallback logic.
The old path decided between
WAVandSPACby queryingSYST:ERR?immediately after the firstSWWVwrite. In v0.2.2, the sweep write is now synchronized before the error check by using a command-completion step (*OPC?), and stale old errors are cleared first with*CLS. That makes the fallback decision depend on the result of the current sweep command instead of socket timing or leftover error state. The SDG programming guide documents*OPC?as returning only after the previous command has been entirely executed. :contentReference[oaicite:0]{index=0}Tested on a real Siglent SDG2042X (
*IDN? -> Siglent Technologies,SDG2042X,SDG2XFBC8R0225,2.01.01.38).Regression test result for Issue #10 was successful: direct
WAVandSPACchecks returned no error, the production-like helper passed, the stale-error-immunity test also passed, and the final result wascritical tests passed: True. :contentReference[oaicite:1]{index=1}Archive location for this version:
https://gitea.togo-lab.io/tgohle/0003-SDG2042X-PyQt-GUI-for-Linux/src/branch/master/script/archive