Install the AC4 driver package first. Device Manager will list the cable as an AC4, but it opens a COM port and programs the relay normally. The two devices are hardware-compatible. Only the USB identity differs, and that is why nothing installs automatically.
Open Device Manager before you reinstall anything, and look at the cable in context. How it appears tells you where the failure sits.
| What you see | Likely cause | First move |
|---|---|---|
| Unknown device or "Other devices" entry with a yellow bang | No installed INF lists the cable's hardware ID | Read the hardware ID, then force the AC4 driver |
| Driver from the kit disk installs, but with an error or no working COM port | Disk driver doesn't match this OS or this cable's ID | Stop reinstalling it. Go to the AC4 driver. |
| Driver from the chip vendor's site installs but the cable isn't claimed | Generic bridge INF doesn't contain the OWEN-assigned VID/PID | Manual binding, not another generic package |
| COM port appears but the software can't reach the relay | Wrong COM number in the software, or a relay-side connection issue | Check the port number and the cable seating at the relay |
| Nothing appears at all when you plug in | Dead USB port, cable, or hub | Try a rear USB port on the machine, no hub |
Check the hardware ID first. Right-click the device, then go to Properties, Details, Hardware Ids. Write down the VID and PID. That string decides which driver Windows will match on its own. It also confirms you're looking at the cable and not some other device.
Understand why the generic bridge driver refuses the cable
Many vendors ship a common bridge chip, often a Silicon Labs part such as the CP2102 in this class of cable, but program their own VID/PID into it.
Windows Plug and Play binds a driver only when an INF file lists the exact hardware ID the device reports. The consequences:
- The chip vendor's generic driver installs cleanly but never claims the cable. Its INF doesn't contain OWEN's ID.
- A kit disk driver built for another OS version, or for another ID revision, installs "crooked". The service loads but the device node never gets a working port.
- Deleting every Silicon Labs driver and starting over changes nothing. The mismatch is in the ID table, not in leftover files.
The AC4 driver works because the silicon underneath is compatible. The driver talks to the bridge chip, not to the VID/PID. When you choose it by hand, you skip the ID match and the driver loads against the compatible hardware.
Order matters.
- Download the AC4 driver package from the OWEN website, on the AC4 converter product page. Follow the install instructions supplied with it.
- Run the AC4 driver installation. On a fresh Windows install, this is the step that's usually missing. The option you need in step 5 doesn't exist until the AC4 driver has been installed.
- Choose
Browse my computer for driver software, thenLet me pick from a list of device drivers on my computer. - If Windows asks for a device class, pick
Ports (COM & LPT)orShow All Devices. - If the AC4 entry isn't listed, clear
Show compatible hardware. Then select the OWEN AC4 driver from the installed list. - Accept the warning that the driver may not be compatible with the hardware. That warning is exactly the ID mismatch you're overriding on purpose.
- Let the installation finish, then unplug and replug the cable once.
Afterward the device shows as an AC4 under Ports. That's the expected state, not a fault. Leave it named that way.
Confirm the COM port reaches the relay
- Under
Ports (COM & LPT), confirm the AC4 entry shows no warning icon. Note itsCOMxnumber. - In the relay programming software, set the connection port to that COM number.
- Connect to the relay and read something back, such as device info or the current project, before you write anything.
- Download a small test change, read it back, and compare.
If you also own an actual AC4 converter, plug it in too. Both devices should enumerate and be recognized. Each one gets its own COM number.
Avoid the fixes that waste an afternoon
- Reinstalling the kit disk driver repeatedly. If it went in crooked once, it will do it again. Move to the AC4 method.
- Chasing newer generic chip drivers. A newer package still won't list OWEN's VID/PID. Newer isn't the problem.
- Trying manual binding before the AC4 package is installed. The pick-from-list dialog only offers drivers already in the store. Install first, then bind.
-
Stale driver packages. Failed attempts leave
oem*.infentries in the driver store. On Windows 7, list them withpnputil -e. Delete the broken ones withpnputil -d oemNN.inf, taking the file name from that list, so Windows doesn't keep grabbing a bad package. - COM number drift. A different USB socket can bring up a new device instance and a new COM number. Keep using the same port, or recheck the number in the software each time.
- USB hubs and docks. Rule them out early. Plug directly into the laptop while you commission the driver.
- Automatic driver replacement. If Windows Update later swaps in a generic driver and the port stops working, repeat the manual binding.
FAQ
You bound the AC4 driver to it by hand. Device Manager shows the name from the driver's INF, not the cable's identity. The bridge hardware is compatible, so the port works normally even though it carries the AC4 label.
Why does the Silicon Labs CP2102 driver install but not recognize the programming cable?
The generic driver's INF only lists the chip vendor's own hardware IDs. The cable reports an OWEN-assigned VID/PID, so Plug and Play never matches it. Check Hardware Ids in the device's Details tab to confirm, then bind a compatible driver manually from the installed list.
Contact them if the AC4 driver binds and a COM port appears, but the relay still won't respond after you've confirmed the port number, a direct USB connection, and a clean driver store. Also contact them if the manual binding won't load at all on your Windows version. Send OWEN technical support the device's Hardware Ids string, your OS version and bitness, and the driver package version you used.