Fix HMI USB driver missing and slow PLC tag updates

Which fault is which when the panel will not download and the tags crawl?

Split them by link: a new-hardware wizard that finds no driver is the USB fault on the laptop-to-panel link, while tag values arriving 30 to 40 seconds late with a communication error on the panel is the serial fault on the DH485 link to the PLC.

The two links share nothing except the panel itself. A download that works tells you nothing about the tag link, and a slow tag link does not block a download once the driver is in. Keep the repairs apart. A driver fix will not speed up one slow tag, and a network fix will not make a missing driver appear. Downloads that run but take minutes instead of seconds are a third fault with its own page: Fix an HMI panel project download that takes 2 minutes.

Why does Windows find the panel but ask for a missing driver?

Because the driver belongs to the panel maker's programming software package, not to Windows. The installer only loads it when its USB driver option stays ticked during installation or upgrade.

The wizard appearing at all is good news about the hardware: cable, port and panel are enumerating correctly. The wizard's appearance does not prove the driver is present, and that gap is the entire fault. Swapping cables or USB ports changes nothing. Vendor documentation across several HMI ranges states the same behavior: the driver installs with the programming software, through a ticked option during setup or as a standalone executable on the installation media. Upgrades are the classic trap. An upgrade leaves the existing USB driver untouched, so a driver that was never installed stays missing. The first download attempt after an upgrade is where the fault usually shows.

How do I check in Device Manager whether the driver bound?

Open Device Manager, plug the panel in through the USB programming cable, and read the entry. A warning icon under Other devices means the driver is absent. A clean entry means the driver bound, and whatever remains sits in the software's communication settings.

1. Plug the cable in and give Windows a few seconds to enumerate.
2. Open Device Manager and look under Other devices for an entry carrying a yellow warning icon.
3. Warning icon present: the driver is absent. Go to the next section and install it.
4. Entry clean but the software still cannot see the panel: close and reopen the programming software, replug the cable, and select USB as the transfer link in its communication setup.
5. If the laptop also carries other USB serial adapters, the port number the software expects may not match the one Windows assigned. That separate mix-up is covered in Remap a USB serial adapter COM port when software stops at COM4.

How do I install the USB driver the right way?

Re-run the programming software installer with the Install USB Driver option ticked, or launch the standalone driver executable on the installation media. Either route loads the same driver, and the panel then binds without opening the wizard.

1. Unplug the panel's USB cable.
2. From the installation media, run the standalone driver executable with administrator rights. On many packages it is a single file named along the lines of USBDriver.exe; read the exact name from your own media. Re-running the main installer with Install USB Driver ticked achieves the same result.
3. If you prefer not to reinstall, use Update Driver Software on the warning-icon entry in Device Manager, choose the browse option, and point Windows at the driver folder inside the programming software's installation directory.
4. Plug the cable back in. The entry should now appear with no warning icon.
5. Push a test download of the current project.

If the media carries no driver executable, get the current software package from the panel maker or its authorized distributor. A generic driver from a driver-download website will not bind to the panel and adds a second unknown to the fault. The permanent repair is habit, not hardware: keep Install USB Driver ticked on every install and every upgrade, and keep the driver installer that matches the installed software version in the laptop's tool kit.

Example: how does a 3-second timeout grow into a 35-second tag wait?

A tag that lands after 35 seconds did not travel slowly. Ten failed waits of 3 seconds with 0.5-second retry gaps produce exactly that delay, plus one fast transfer at the end. That is why the cure is settings and network repair and never a faster cable.

Take example values a panel might hold: a 3 s response timeout and a fault raised after 10 failed attempts. Read your own values from the panel's device settings; the arithmetic works on whatever they are.

• One failed attempt: 3 s timeout + 0.5 s retry interval = 3.5 s.
• Ten failed attempts: 10 x 3.5 s = 35 s of waiting.
• The next attempt succeeds, and the transfer itself takes milliseconds.
• Total: about 35 s, inside the 30 to 40 s window the panel shows.

Set that against a healthy link, by the same arithmetic. DH485 defines two rates, 9600 and 19200 baud. At 19200 baud, counting start and stop bits, the line carries roughly 1,920 bytes per second, so a 30-byte read response occupies 30 / 1,920 = 16 ms of line time, plus a token pass measured in milliseconds. A clean link answers in well under 0.1 s. Of the 35 seconds, about 16 ms is the actual transfer; the rest is waiting out timeouts. Shortening the timeout value or the retry count trims the wait but leaves the first attempt failing. The only fix that brings updates under a second is making the first attempt succeed.

Why does a healthy DH485 link never take 30 seconds for one tag?

DH485 is a token-passing network across addresses 0 to 31 with two baud rates, 9600 and 19200. On a clean link a small read finishes in milliseconds, so a 30 to 40 second delay can only be stacked timeouts with retries behind them.

Token passing explains how far the symptom spreads. Each node may transmit only while it holds the token, and the token travels in address order, so a node that holds it too long or fails to pass it stalls every other node on the network. One bad device drags a whole line of panels, and the panel's complaint is delay plus intermittent errors rather than a constant ceiling. The panel raises "PLC Communication error" when a request waits out its timeout with no response.

Decide by what the panel shows:

• The error constant and no tag value ever appearing: configuration. Work items 1 to 3 of the table below. The step-by-step pairing of panel and PLC settings is in HMI panel not talking to the PLC: serial settings mismatch.
• Values arrive but slowly, or drop in and out: network quality or token load. Work items 4 to 6.

The ground-reference first instinct is worth one 30-second test: unplug the programming cable and read again. When the delay and the errors stay with the cable off the panel, cross that cause off and work the table. The same timeout-and-retry logic, with the same arithmetic, applies on other serial protocols: Fix DF1 NAK errors and PLC comm timeout on serial HMI links walks it on DF1.

Which DH485 settings do I check, and in what order?

Work the table top to bottom and change one item at a time. Protocol match comes first, then a matching baud rate, then unique node addresses, then the max node address trimmed to the highest node in use, then cable and termination, then tag layout.

Menu names and value ranges differ between panel generations and PLC models, so read the exact paths from the panel's manual and the PLC's channel documentation for your processor. Before touching any number, confirm the panel's device driver matches the PLC's protocol: Check the panel driver list before tuning serial settings explains that order.

How does a two-node test show which node is poisoning the network?

Disconnect every node except the panel and the PLC, then read. A two-node link that answers in milliseconds convicts a third node. A two-node link that still crawls at 30 to 40 seconds convicts the settings or the cable.

With two nodes reading fast, bring the remaining nodes back one at a time and read after each. The node that brings the delay or the errors back carries the fault, most often a duplicate address, a baud rate set differently on its channel, or a failing interface converter. With two nodes still slow, the fault sits in items 1 to 5 of the table above: settings and the panel-to-PLC cable. While you wait for parts or a maintenance window, trimming the max node address is free and immediate, and cutting the tag count on the active screens reduces how many requests wait out a timeout on each refresh.

What is the fix tonight, and what is the fix for good?

Tonight, run the standalone driver executable, trim the PLC port's max node address to the highest node in use, and re-test with two nodes. Permanently, tick Install USB Driver on every install and upgrade, keep node addresses unique within 0 to 31, and match baud at 9600 or 19200.

Recommendation: Fit the USB driver from the panel maker's installation media before touching any network setting, because no panel change is possible until the programming software connects. Then run the two-node test before buying or replacing anything. Fast at two nodes means reintroduce the rest one at a time until the delay returns; slow at two nodes means correct protocol, baud, node address and max node address from the table, in order. If the panel is due for replacement anyway, confirm the protocol the PLC port speaks before ordering, as Check the PLC serial protocol before replacing a legacy HMI sets out. Other repairs for machine-mounted screens and panels live in the shop-floor screens section.

Questions