Error 0xBFFFF0015 on Linux CP210X and CDC-ACM Devices Upon Calling VISA Write in LabVIEW

Issue Details

Environment:

• Operating system: Ubuntu 24.04 LTS
• Application software: LabVIEW 2024 Q1 or later
• Driver: NI Linux Device Drivers 2025 Q4 (which includes NI-VISA)

I am calling VISA Write on a serial resource on Ubuntu 24.04. It returns the following error, even though the bytes are transmitted over the serial line successfully:

VISA: (Hex 0xBFFF0015) Timeout expired before operation completed.

The call blocks until the configured VISA timeout expires before returning, and writeCount is reported as 0. Why is this happening and how can I resolve this?

Solution

The error only occurs on serial devices that use one of the following Linux kernel drivers:

• cp210x — Silicon Labs CP2102 / CP210x USB-to-serial converters 
• cdc-acm — USB CDC-ACM class devices, such as GNSS receivers, USB radio dongles, and certain modems 

The cp210x driver claims to support TIOCGICOUNT ioctl but it fails to update the tx counter. The tx field counts how many bytes have been physically transmitted off the wire by the UART interrupt handler. NI-VISA polls TIOCGICOUNT waiting for the tx counter to increment until timer expires, which eventually causes viWrite to return with 0 written byte, regardless of how much data actually reached the device. 

A workaround for this is to redirect the affected device through NI-VISA's existing cdc-acm fallback path by creating a /dev/ttyACM_* udev symlink. NI-VISA detects the ttyACM prefix in the device name and uses the tcdrain fallback in place of the broken counter-polling path, which allows the write call to return successfully.

Steps to the workaround:

1.  Identify the USB vendor and product ID of the affected device (Optional):
   
   In a terminal, list the device attributes for the affected ttyUSB* or ttyACM* node. 
   bash
   udevadm info -a /dev/ttyUSB? | grep -E 'idVendor|idProduct'

**Note the idVendor and idProduct values from the first matching block. For a generic Silicon Labs CP2102, these are typically 10c4 and ea60.
   
   
2. Create a udev rule that adds a /dev/ttyACM_* symlink:
   
   Create a new udev rule file. Replace 10c4 and ea60 with the values from Step 1, and choose a descriptive alias (for example, GNSS, KAR, or cp210x) so each device is uniquely identified:
   
   bash
   
   sudo tee /etc/udev/rules.d/99-visa-acm-workaround.rules << 'EOF'
SUBSYSTEM=="tty", ATTRS{idVendor}=="10c4", ATTRS{idProduct}=="ea60", SYMLINK+="ttyACM_cp210x%n" EOF

**The %n placeholder is replaced by the kernel device index, which keeps the symlink unique when multiple identical devices are connected.
   
   
3. Reload the udev rules and verify the symlink:
   
   sudo udevadm control --reload-rules
sudo udevadm trigger
ls -la /dev/ttyACM_cp210x*

The output shows the new symlink pointing at the original device node, for example:
   /dev/ttyACM_cp210x0 -> ttyUSB0


4. Update the NI-VISA configuration file to use the new symlink:
   
   Edit /etc/ni-visa/visaconf.ini. Locate the entry for the affected ASRL resource and change its SystemName value to the new symlink. Set the Enabled field of any duplicate entry that still references the original /dev/ttyUSB? path to 0 so it does not appear as a second resource.
   ini
   

   Name3="ASRL4::INSTR"
   Enabled3=1
   Static3=0
   SystemName3= Change from "/dev/ttyUSB?" to "/dev/ttyACM_cp210x?"
   BaudRate3=9600
   Parity3=0
   StopBits3=10
   DataBits3=8
   FlowCtrl3=0

5. Restart LabVIEW:
   
   Close LabVIEW (or any other NI application that holds the resource) completely, then relaunch it. The next VISA Write call on the resource returns without timing out, and writeCount reflects the bytes that were actually transmitted.

Additional Information

• Drivers known not to require this workaround. ftdi_sio, pl2303, qcserial, ch341, and onboard UART drivers such as dw-apb-uart correctly update the TIOCGICOUNT tx counter and do not exhibit the timeout. No symlink is needed for devices using these drivers.
•  Using ttyACM_cp210x0 (not ttyACM1) here is to avoid collision with real CDC-ACM devices
• Reducing the VISA timeout suppresses the error but introduces a fixed delay on every write call, which is not acceptable for timing-critical protocols.
• Devices using the ftdi_sio, pl2303, qcserial, ch341, or onboard dw-apb-uart drivers are not affected.