05-30-2026 10:07 AM
I've implemented these 3 things:
It seems to be working OK now.
Many thanks to mcduff, LV_Tim, & JÞB.
05-30-2026 10:27 AM
@paul_a_cardinale wrote:
@JÞB wrote:
Better Idea: update you resume! Your skinflint management is probably cost cutting on payroll too!
I'm retired.
8-Ball calibration confirmed:D.
05-30-2026 10:39 AM - edited 05-30-2026 10:51 AM
@paul_a_cardinale wrote:
I've implemented these 3 things:
![]()
![]()
It seems to be working OK now.
Many thanks to mcduff, LV_Tim, & JÞB.
I always hated that the glyph indicated Asynchronous. As a rule of thumb, the only real way to get in any trouble with the mode is Asynchronous write immediately followed by a Synchronous read on a low BW bus. Which I almost overlooked. I haven't seen that specific behavior since circa 6.1 or 7.0 on non-compliant IEEE-488 devices. But, I have been down that rabbit hole!
The *WAI SHOULD be moot at best, troublesome at worst. IIRC the command forces the device to block all further incoming messages until the device command buffer is empty. This can cause a notable delay between VISA Write mode return times if *WAIting when additional Writes are sent. Only use *WAI if you expect the device's command buffer is limited.
05-31-2026 03:28 AM
From the example you posted the scope may be cheap but the communication protocol doesn't look like early last century and seems a fairly well behaved SCPI like protocol.
Your problem simply was that you had not yet remembered or watched https://labviewwiki.org/wiki/VIWeek_2020/Proper_way_to_communicate_over_serial. This is one of the most useful presentations about LabVIEW VISA and especially serial port communication. From what you provided in your later response this would have given you all the needed answers.