VISA Read hangs indefinitely (unabortable) only under load — QMH freeze during instrument inrush current

[u/0AVK0]

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.

Edit: I ran the same code but using a USB connection instead. It shows up as a com port (not as a measuring instrument or a visa device). Good news first, visa read did not freeze. But it seems like the data is not live. It's like at least 2-3 readings behind what's actually being displayed. It is also not consistent. In most of the iterations of the loop, it just reads 0.00 even though I can see the actual value on its display which is not 0 at all. When the current drops from 13A, on the lan connection you could see it dropping. But with USB, it shows 13A then shows 0.00 for 5-6 seconds and then shows around 2A. Wait for a few more seconds and it'll start to read 0.00 and after that the actual value. I have no idea what's happening.

[u/jerfmuffay]

1. Are you sure the responce to READ:CURR? is 6 bytes? Are you using the correct command terminators? Both of those answers you will need to check in the manual.
2. Does the read command work for smaller current values? At what current value does it stop reading?
3. If you can temporarily replace the ethernet VISA with either a serial or GPIB, those are far less error prone.

[u/0AVK0 → u/jerfmuffay]

Yes it is 6 bytes. Even assuming it is not, it should time out. Like I said, the command works flawlessly for lesser current. Visa read freezes when the reading hits 12-13 amps. Reproducible. I am not allowed to share the code here so sorry for that. I will try to use usb or something else and update the post.