Resolving LOGO! 8 OBA6 'Data Transfer is Busy' RS232 Download Error

1. Problem Summary

The Siemens LOGO! 8 OBA6 230RC logic module (typical MLFB 6ED1 052-1CC08-0BA6 for the 230RC variant with display, and 6ED1 052-2CC08-0BA0 for the 230RCE variant with Ethernet) communicates with a PC using either the legacy LOGO! PC cable (RS232, MLFB 6ED1 057-1AA00-0BA0) or the current LOGO! USB PC cable (MLFB 6ED1 057-1DA00-0BA1). When LOGO! Soft Comfort (LSC) is asked to transfer a circuit program and the dialog "Data transfer is busy" is displayed, the LSC communication thread has failed to acquire exclusive control of the COM port that has been bound to the cable. The message originates in LscCom.dll after the call to CreateFileW("\\.\COMx", GENERIC_READ|GENERIC_WRITE, 0, NULL, OPEN_EXISTING, 0, NULL) succeeds but the subsequent SetCommState/WriteFile pair times out or returns ERROR_ACCESS_DENIED (Win32 error 5).

The condition is recoverable on the host. It does not require a factory reset of the LOGO! module and does not indicate a corrupted circuit program in the controller's flash. The fault lies entirely on the Windows-side communications stack: the COM port is held by another application, the cable hardware is partially degraded, the LOGO! is in the wrong front-panel mode, or the COM port number has shifted after a USB-to-serial enumerator reset.

2. Affected Hardware and Software

Refer to the LOGO! 8 System Manual (Siemens ID 109743670) for the full pin map of the front programming socket and the cable shield grounding requirements for cabinet installation in noisy industrial environments.

3. Root Cause Analysis

The "Data transfer is busy" string is reported by LSC's communication handler when the target COM port is non-responsive at the application layer. The dominant root causes, in order of field frequency, are:

1. COM port held by another process. Windows opens COM ports in non-sharing mode for serial communications. If a previous LSC instance crashed, a HyperTerminal, PuTTY or Tera Term session was left open, or a USB-serial hot-plug event orphaned a handle, the COM port stays locked until the owning process is killed or the device is unplugged and re-enumerated.
2. LOGO! in PARAMETER mode. In PARAM mode the LOGO! front keypad has precedence over the serial port for write operations. LSC sees the controller as perpetually busy and aborts the transfer after the 30-second negotiation timeout.
3. Defective RS232 cable. The original LOGO! RS232 cable uses a stranded DB9 connector that is sensitive to kinking at the strain relief. Internal conductor breaks yield a port that opens without error but never completes a handshake, which LSC interprets as a busy target.
4. USB-to-RS232 adapter enumeration shift. When a USB-to-serial dongle resets after sleep/hibernate, Windows may renumber it to a different COM port. The COM number LSC was configured against no longer exists, so the autodetect sequence opens an unrelated or non-existent port and stalls.
5. Wrong baud rate or flow control. LSC's "Autodetection" negotiates 19 200 bps, 8-N-1 with hardware flow control (RTS/CTS). If the LOGO! has been previously configured to a non-default baud (rare, only with custom function blocks) or the cable's RTS/CTS loop is open, negotiation stalls at the SetCommState call.
6. Driver signature mismatch. On Windows 11 22H2 and later, unsigned or outdated CP210x or FTDI drivers are blocked by Secure Boot, leaving the cable as an unknown device with a phantom COM port that cannot transmit.
7. LOGO! in bootloader mode. A failed firmware upgrade leaves the LOGO! in the ROM-resident bootloader, which only accepts the binary firmware stream over the same port. LSC's high-level protocol sees no FBD response and reports "busy".

4. Pre-Diagnostic Checklist

Before opening LSC, capture the following baseline from Device Manager and the LOGO! front panel:

• Confirm the cable is seated firmly in the LOGO! front 8-pin mini-DIN socket. The connector keyway must face up; the locking tab must click. A 180° rotated plug powers the cable but cannot handshake.
• Verify that the LOGO! front display reads either LOGO! → RUN (green status) or LOGO! → STOP. Reject PARAM, EDIT and the firmware-update menu.
• Open Device Manager → Ports (COM & LPT) and note the COM number assigned to the cable. For the USB cable the entry reads "Siemens LOGO! USB Cable (COMx)" or "Silicon Labs CP210x USB to UART Bridge (COMx)". For the RS232 cable it reads "Communications Port (COMx)".
• In LSC, choose Tools → Options → Interface and confirm the COM port shown matches Device Manager. Toggle Autodetect off and back on if the values disagree.
• Check the LOGO! LED row: a solid green RUN LED with a blinking red ERROR LED indicates a corrupted program; download is still possible, but the program must be replaced before commissioning.
• Open Event Viewer → Windows Logs → System and filter for Source = "Serial" or "usbser" within the last hour; entries with Event ID 1 or 32 indicate a USB-reset storm that has renumbered the COM port.

5. Solution 1: Release the Held COM Port

The most common fix is to force Windows to release the locked COM handle. The classic field procedure uses HyperTerminal (still present on Windows 10 IoT and legacy installations) or, on Windows 11 23H2 and later, the PowerShell Disable-PnpDevice/Enable-PnpDevice pair.

Method A — mode command (Windows 10 and earlier):

1. Open an elevated Command Prompt (cmd.exe → Run as administrator).
2. Type mode COM3:9600,8,N,1, replacing COM3 with the actual port, and press Enter. A response of Status for device COM3: ... confirms the port is free. A response of Invalid handle or Status: ERROR means the port is still locked; continue to step 3.
3. Open Task Manager → Details and add the PID column. Run resmon.exe (Resource Monitor), switch to the CPU tab, expand Associated Handles, search for \Device\Serial or COMx, and identify the owning PID.
4. Right-click the offending process → End task. If the process is LSC.exe or LscSrv.exe, also check %LOCALAPPDATA%\Siemens\LOGO!\SoftComfort for stale *.lock files and delete them.
5. Unplug the USB cable (or unplug and replug the RS232 DB9), wait five seconds, and reconnect. The COM number should reappear in Device Manager.

Method B — PowerShell (Windows 11 23H2+):

# Enumerate serial ports and detect handles
Get-CimInstance -Class Win32_SerialPort |
  Select-Object DeviceID, Name, Status

# Find the PID holding COM3
Get-Process | Where-Object {
  $_.Modules.ModuleName -match 'serialui|COM'
} | Select-Object Id, ProcessName

# Cycle the COM port to release the handle
$port = (Get-PnpDevice -Class Ports |
  Where-Object {$_.FriendlyName -match 'COM3'}).InstanceId
Disable-PnpDevice -InstanceId $port -Confirm:$false
Start-Sleep -Seconds 2
Enable-PnpDevice  -InstanceId $port -Confirm:$false

6. Solution 2: Switch the LOGO! Out of PARAMETER Mode

The LOGO! OBA6 keypad cycles through RUN → STOP → PARAM with successive presses of ESC. LSC cannot begin a write transfer while the front panel is in PARAM mode because the operating-system flag (bit 0 of the mode register inside LSC's view of the LOGO! firmware) is held at "user input active".

1. Press ESC on the LOGO! until the display reads LOGO! → RUN or shows the I/O status line.
2. If the program currently in the LOGO! is password-locked, the password prompt must be cleared first. Use the cursor keys to enter the password; if it is forgotten, a factory reset is required and the existing program is lost.
3. Re-attempt the transfer from LSC: Tools → Transfer → PC → LOGO! or the keyboard shortcut F5.

7. Solution 3: Inspect and Replace the Programming Cable

The original RS232 cable (MLFB 6ED1 057-1AA00-0BA0) is unshielded at the DB9 strain relief and the cable jacket becomes brittle after two to three years of flexing in control cabinets. Field reports consistently link this fault mode to intermittent "busy" responses: the cable is electrically open on one or two lines, but the COM port is still acquired by Windows without error.

Continuity test procedure:

• Disconnect the cable from both ends.
• Use a multimeter on continuity between the DB9 pins and the 8-pin mini-DIN pins per the Siemens wiring diagram in the LOGO! 8 System Manual (109743670), section 6.2. The required signal pairs are:

Any reading above 5 Ω on a data line indicates a fatigued conductor; replace the cable. If the test passes but the fault persists, swap the cable with a known-good spare to isolate the LOGO! front socket from the cable.

8. Solution 4: Configure LOGO! Soft Comfort Communication Settings

The default LSC settings suffice for the OBA6 firmware, but a manual override is required when a third-party USB-to-serial adapter is in use or when the COM port has been re-enumerated:

1. In LSC, open Tools → Options → Interface.
2. Set the Interface drop-down to Serial (or USB if using the USB cable).
3. Set the COM port manually to the value shown in Device Manager. Pin the value below COM10 to avoid Windows' reserved-name collision on systems with aggressive name mangling.
4. Set the baud rate to 19200, parity None, data bits 8, stop bits 1, flow control Hardware (RTS/CTS). These values match the LOGO! 8 OBA6 firmware default documented in the LOGO! Soft Comfort V8.3 Operating Manual (109811612), section "Communication parameters".
5. Tick Autodetect to allow LSC to negotiate against the LOGO! once the link parameters are confirmed.
6. Click Test connection. A successful test returns "LOGO! found, firmware x.xx.xx".

9. Solution 5: Migrate to the LOGO! USB Cable

Switching to the USB cable (MLFB 6ED1 057-1DA00-0BA1) eliminates three of the seven root causes listed above: the COM-port lock, the DB9 connector damage, and the baud-rate negotiation drift. The migration is one-way; the RS232 cable is obsolete and no longer orderable through Siemens regional stocking.

1. Connect the USB cable to the PC. Windows Update retrieves the CP210x driver automatically on Windows 10 1909 and newer. On isolated networks, pre-stage the driver from the Silicon Labs website (v6.7.10 or later for Windows 11 24H2).
2. Verify that Device Manager shows "Silicon Labs CP210x USB to UART Bridge (COMx)".
3. In LSC, change the interface to USB and run Autodetect.
4. If the autodetect returns "No LOGO! found", swap the cable's orientation at the LOGO! end; the 8-pin mini-DIN has a keyway that is easily inserted 180° off, in which case the LOGO! powers the cable but cannot handshake.
5. Pin the COM number through Device Manager → Port → Properties → Advanced → COM Port Number to a value below 10 to prevent renumbering after sleep/wake.

10. Verification Procedure

After applying any of the fixes above, validate the link end-to-end:

1. Power-cycle the LOGO! (remove the 230 V AC supply for 5 seconds, restore).
2. Open LSC and load the existing circuit program (File → Open).
3. Press F5 (PC → LOGO! transfer). The status bar must read Transfer in progress followed by Transfer successful. The dialog must not read "Data transfer is busy" at any point.
4. On the LOGO! display, confirm that the program version banner appears (e.g. Prog: V1.0.0).
5. Toggle one digital input and verify the corresponding output on the LOGO! status screen. This confirms that the program is actually executing in the module, not just transferred to RAM.
6. Close and re-open LSC, then repeat the transfer. A persistent success across two consecutive sessions proves the COM port lock has been cleared, not merely masked for the first session.
7. Save the LSC project with a versioned filename (e.g. MyMachine_V1.1.lsc) and back up the project to a network share — losing the only copy of the FBD on the LOGO! is the most common follow-on fault after a download failure.

11. Troubleshooting Matrix

12. Frequently Asked Questions