Separate Allocation Churn from a Memory Leak
The two LabVIEW 14.1 routines are allocation-heavy: the VISA query builds a response string byte-by-byte, while the converter builds a DBL array element-by-element. That makes both worth refactoring, but the available evidence does not establish either routine as the source of an unbounded memory leak. Measure memory across repeated identical transactions before assigning root cause.
| Routine | Current behavior | Supported optimization | Primary risk |
|---|---|---|---|
| Query Command.vi | Concatenates bytes as VISA reads them | Reuse a grow-only buffer and create the result with one final copy | Changing byte-count or termination behavior |
| Real 64 Converter.vi | Appends converted values individually | Convert complete elements from the string in one operation | Applying the wrong byte or word order |
Refactor the VISA Query Around a Reusable Buffer
The application configures serial termination with 0xA, but Query Command.vi also requests a byte count. Preserve both behaviors until testing establishes whether VISA stops at the termination character, the requested count, or whichever condition occurs first under the existing serial initialization.
- Allocate a reusable buffer sized for the current request and enlarge it only when a later response requires more capacity.
- Write incoming bytes into existing buffer positions instead of concatenating a new string on every loop iteration.
- After the read completes, copy only the occupied portion into the returned string.
- Regression-test the returned bytes, response length, and inclusion or exclusion of
0xAagainst the original VI.
A grow-only buffer retains its largest allocation by design. A stable high-water mark after the largest response is therefore expected; continuing growth during identical requests indicates that another allocation path still requires investigation.
Convert Complete Values Without Losing Byte Order
Unflatten from String can consume the bytes forming complete output elements instead of extending an array one value at a time. The evidence states that it returns error 74 when the string is too short to produce even one array element. Treat trailing incomplete data as a framing or payload-length failure rather than silently accepting it.
Do not treat “Swapped” and “Little Endian” as interchangeable without confirming the instrument's wire format. The reviewed alternatives did not all preserve the original exchanges of 16-bit entities or 32-bit halves. A DBL destination is 64 bits, but the evidence also says the instrument API uses a fixed data width and may not require a 64-bit wire-format case; distinguish destination type from wire width. Preserve the original full-reversal behavior until a device specification or known payload proves the required byte and word order.
Verify Memory and Numeric Integrity
Run the original and refactored paths with identical commands and compare the raw response bytes before conversion. Then compare converted values using a known instrument payload for every byte-order mode the API exposes. Include an undersized payload to confirm error 74, and test responses ending in 0xA at and below the requested byte count.
For memory verification, repeat one fixed-length query, then a larger query, followed by the original query again. The reusable buffer may grow for the larger response but should not continue allocating on later repetitions that fit its existing capacity. If total application memory still increases without reaching a plateau, continue the leak search outside these two routines.
FAQ
Does building a VISA response byte-by-byte prove a LabVIEW memory leak?
No. It can cause repeated allocations and copies, but the evidence does not show that it creates unbounded retained memory. Confirm the leak by checking whether memory continues growing during identical repeated queries.
How should Query Command.vi handle the 0xA termination character?
Keep the existing 0xA serial termination configuration and byte-count request unchanged during the buffer refactor. Verify the returned length and whether the terminator is included by comparing raw output with the original VI.
Why can Unflatten from String return LabVIEW error 74?
Error 74 occurs when the input string is too short to form at least one complete output element. Check payload length and framing before changing the converter or byte-order mode.