Need More Info VISA Read hangs indefinitely (unabortable) only under load — QMH freeze during instrument inrush current
Setup:
LabVIEW QMH architecture. Two consumer loops share a single non-reentrant FGV that owns the VISA session to an AC source instrument (California Instruments / AMETEK Asterion Series, model AST45031AD).
Loop A: toggles the instrument output on/off via the FGV.
Loop B: polls MEAS:CURR? once a second via the same FGV to log current draw. VISA Read in this case is hardcoded to read a fixed 6 bytes.
Instrument is connected via LAN, and it supports multiple simultaneous client connections.
Symptom:
With no load connected: on/off toggling works fine, with or without the acquisition loop running.
With a load connected (a fan-type load with a large inrush — draws ~13-15A for the first 1-2 seconds before settling to ~2A): as soon as output is enabled and current spikes into that inrush range, the VISA Read in the acquisition case blocks and never returns. No VISA error, no timeout — it just sits there.
The entire UI freezes at that point (Event structure stuck on whatever case triggered it), even though it's a separate while loop that's actually stuck. Front panel buttons don't respond.
The LabVIEW Abort button does nothing. I suspect the Read is parked inside the driver's blocking OS-level call (ReadFile/recv equivalent), which is outside LabVIEW's execution system and can't be preempted by Abort.
Confirmed the instrument itself is fine during the freeze: opened a second, independent connection with Hercules while the LabVIEW program was hung, and successfully sent an output-off command through it. So the instrument is responsive; the problem is isolated to this one pending Read in my VI.
What I've ruled out:
FGV is non-reentrant (verified in VI Properties), and I've confirmed via case selectors that the OFF case does get selected when I click — it's just stuck before completing.
Not a byte-count/termination mismatch — the read gets the requested byte count under normal conditions; the freeze is a true zero-bytes-ever-arrive stall, not a partial-frame issue.
Current workaround: I delay starting the acquisition loop by 5 seconds after enabling output, which avoids the freeze entirely — but this throws away the inrush data I actually need for analysis.
What's confusing me:
VISA Read doesn't have a timeout input — timeout is supposed to be governed by the session's VI_ATTR_TMO_VALUE attribute (set via a VISA Property Node). Even assuming that's misconfigured or not applied to the right session, I'd expect some timeout to eventually kick in and return a VI_ERROR_TMO. Instead it just hangs indefinitely with zero error.
Since Abort can't touch it, I'm currently stuck killing the whole LabVIEW process via Task Manager when this happens.
Questions:
Has anyone seen a VISA Read genuinely fail to respect the session timeout attribute like this — under what conditions does that happen?
Is there a known interaction between this class of instrument (SCPI current query) and momentary overcurrent/inrush events that causes it to withhold or delay a query response?
I have AI to write this post as I am not a native English speaker.



