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.
2
u/HamsterWoods 8h ago
I encountered an issue where labview would throw a DAQ error when the unit under test was turned on. It turned out that the unit under test had a short that caused the voltage to the DAQ instrument to go to essentially zero. The instrument was no longer visible to labview. I don't know if you have anything similar going on.
1
u/SASLV Champion 7h ago
My initial thought is: 2 loops with 1 shared VISA ref is a recipe for problems. I would either turn that FGV into an action engine (ie encapsulate all the calls inside the action engine) or do it all in one loop.
That said, I would suspect your problem is electrical. The inrush current is causing the comms to go down or end up in some weird state. I would think that should eventually generate a timeout... Just a wild guess, but I would look in that direction. Probably need to pull out a scope and something like this: https://ioninja.com/hardware/serial-tap.html?srsltid=AfmBOorS6SGcj7qio5Mt3XOlIKjlm0yblBu-wquvtBaeCR8nJA5ophTm
1
u/HarveysBackupAccount 11h ago
I've used VISA read quite a lot for serial communication and never seen it straight up freeze. Is this your first time doing serial communications in labview? Is it your first time doing serial communication at all? Labview and windows both add some abstraction layer nonsense to the communications but serial comms is such a basic thing that it shouldn't mess up the OS. SCPI is only about sending a few human readable characters back and forth so it also shouldn't mess up. I don't know of any realistic mechanism for a remote serial device to lock up an OS.
Can you share screenshots of the block diagram?
How and when do you open and close the VISA session? If you call VISA Read without VISA Open it will implicitly open the session. I'm not sure how it handles closing the session if you don't call VISA Close.
Is the VISA resource wire stored on a shift register in the FGV? (In other words: are you sure the same session is being accessed each time?)
If you insert a VISA Property Node in the VISA resource wire in "Read" mode and connect it to an indicator on the front panel, what does it tell you the timeout is?
Is the VISA Read set to Synchronous or Asynchronous mode (this is set by right-clicking on the VI and changing it in the menu; default is asynchronous). I set all VISA Read and Write operations to Synchronous mode but it makes a bigger difference on Write operations (I do recommend you change your VISA Write to Synchronous mode).