VISA Read (ASRL) returns duplicated line content on fast bursty input — persists even with Termination Character, single Read call site in code

[cpiccoli]

I'm reading fast, bursty serial data (short lines terminated with \r\n, sent back-to-back with minimal/no inter-line delay) via a DQMH-based architecture, and I'm seeing individual lines duplicated in the data I receive, even after eliminating what I believed was the root cause.

Setup:

• LabVIEW 2021 SP1, Windows
• Real RS232 port, 115200 baud (also reproduced via a com0com virtual COM pair)
• DQMH module handling serial communication; there is only one VISA Read call site in the entire codebase
• Test traffic from a Python script (pyserial)

History:

• Originally read via Bytes at Port → VISA Read (byte count = N). Intermittent stalls on long/fast bursts, no VISA error ever reported.
• Switched to VI_ATTR_ASRL_END_IN = VI_ASRL_END_TERMCHAR (\n), keeping Bytes at Port > 0 only as a gate before calling Read (byte count parameter left high as a safety cap, not as the actual read length). This did not fix the issue.

Current symptom (with termchar enabled):
Sending exactly 3 lines (LINE00000_XXX..., LINE00001_XXX..., LINE00002_XXX...), the application receives:

LINE00000_XXXXXXXXXXXXXXXXXXXXXXXXXXXXLINE00000_XXXXXXXXXXXXXXXXXXXXXXXXXXXX
LINE00001_XXXXXXXXXXXXXXXXXXXXXXXXXXXXLINE00000_XXXXXXXXXXXXXXXXXXXXXXXXXXXX
LINE00001_XXXXXXXXXXXXXXXXXXXXXXXXXXXX
LINE00002_XXXXXXXXXXXXXXXXXXXXXXXXXXXX

Note: LINE00000 appears 3 times, LINE00001 appears 2 times, LINE00002 once — for only 3 lines actually sent. The order is also slightly interleaved rather than strictly sequential duplicates. No VISA error is ever reported. The port remains fully usable afterward (subsequent writes/reads work normally).

What's already ruled out:

• Only one VISA Read block exists in the entire block diagram (verified)
• Byte-count race condition with Bytes at Port (eliminated by switching to termination-character-based reads — issue persists identically)
• Downstream queue/array/UI logic (duplication confirmed present immediately after VISA Read via probe, before any of that logic runs)

What I'm currently trying to determine:
Whether this single VISA Read call site is somehow being invoked multiple times concurrently for the same incoming data (e.g. an architectural issue in how the DQMH module's loops/events are wired, causing re-entrant or overlapping execution of the same read path), versus a single physical Read genuinely returning duplicated data at the VISA/driver level.

Questions:

1. Is there any known VISA/driver-level behavior on ASRL sessions (with termchar-based reads) that could cause a single VISA Read call to return previously-read data again, under high-speed bursty input?
2. In a DQMH (or general producer/consumer / queued message handler) architecture, what are common causes of a single read/parse VI effectively executing more than once per incoming message (e.g. reentrant VI called from multiple triggers, event structure queuing/firing issues, timeout case overlapping with an explicit request)? Any standard checks/pitfalls to look for here?
3. Has anyone seen this specific "N lines in, more than N (duplicated) lines out, slightly reordered" pattern before, and what turned out to be the cause?

Any guidance — especially on how to definitively distinguish an application-level double-invocation issue from a genuine VISA/driver-level duplication — would be greatly appreciated.

[Bob_Schor]

You show no code.  One important question is how many "physical wires" are involved in sending signals from Line 0, Line 1, and Line 2 to Port 0, Port 1, and Port 2?  Assuming the three Lines are sending their information asynchronously, you need three VISA Line/Port pairs, potentially running concurrently (in parallel).

As has been said multiple times, you should "almost never" use "Bytes at Port".  Show us your code (not "pictures of code", and preferably saved as LabVIEW 2021 or earlier).  If you have multiple serial data paths running in parallel, they should probably be running in VIs also running in parallel.

A decade ago, I developed a routine for testing behavior (of mice), where some of the data were coming over serial lines (VISA).  If we tested N mice, we spawned N asynchronous VIs to handle each experimental station running in parallel.  No problem handling 4 to 12 (depending on the experiementer) subjects at a time.  Note that the key to getting this code to work was to design it for a single channel -- get that working, then "clone" that code for each station and embed it in a controlling design like the DQMH (I used the Channel Message Handler).

Bob Schor

[OneOfTheDans]

I recommend creating a new VI and replicating the bare minimum VISA calls to replicate this issue. This will eliminate all the questions about re-entrancy, event handlers, DQMH, etc. You will either find the bug in your code, or end up with a good example to share here (or with NI) for support.