# When the widget won't connect - **MCP resource:** rdmbench://help/widget - **Version:** 0.2.0 - **Runs on:** macOS 15 Sequoia or later, Apple silicon or Intel - **Needs:** An Enttec DMX USB Pro with its DMX/RDM firmware (major version 2) - **Price:** Free This topic is about the widget itself: the Enttec DMX USB Pro between the computer and the DMX line. If the widget connects and the line comes back empty, see [When no fixture is found](/help/no-fixtures/) instead. When connecting fails, the **Connect** sheet opens again with a sentence saying why. Find that sentence below. ## Not in the port list The widget is a USB serial device. If **Fixture → Connect…** does not list it, open **Show all ports** first. An adapter that does not name itself as an Enttec is listed there. If it is not there either, the computer cannot see it: - **Try another USB cable.** Some cables carry power and no data. The widget's LED can light on one of those and still not show up. - **Plug it straight into the computer**, not into a hub or a monitor. An unpowered hub can drop it. **On macOS:** - macOS includes the driver for the widget's USB chip, so there is nothing to install. **On Windows:** - Windows needs FTDI's driver, which Windows Update normally installs the first time the widget is plugged in. If the widget is listed in Device Manager but has no `COM` port, open its properties and check **Load VCP** on the **Advanced** tab, then unplug it and plug it back in. **On Linux:** - The kernel's `ftdi_sio` driver handles the widget, and it appears as `/dev/ttyUSB0` or similar. `dmesg` right after plugging it in says whether the kernel saw it. Then choose **Refresh** on the sheet. ## In use by another program *In use by another program* means the port is busy: the widget is plugged in and working, but another program already has it open. Only one program at a time can use the widget. Quit the other one and connect again. It is usually: - a lighting program (QLC+, a desk's offline editor), - Enttec's own software, such as EMU or NMU, - a second copy of RDMBench, or the command-line tool still running in a terminal. ## Not allowed to open the port *This account is not allowed to open* the port means the system refused this user. **On Linux:** On Linux, serial ports belong to the `dialout` group (`uucp` on Arch). Add yourself with `sudo usermod -aG dialout $USER`, then log out and back in. **On macOS, Windows:** This is not expected here. Unplug the widget, plug it back in, and try again. ## The wrong firmware The widget runs one of three firmware builds, and only one does RDM: - **1.x, DMX-only.** Most widgets ship with this one. It sends DMX and cannot do RDM. - **2.x, DMX/RDM.** The build the bench needs. - **3.x, RDM sniffer.** It listens to a line but cannot ask it anything. With 1.x or 3.x, the bench refuses to connect and names the version it found. Flash the DMX/RDM build once with Enttec's EMU tool, and the widget keeps it. ## Nothing answered *Nothing on it answered as a DMX USB Pro* means the port opened but nothing on it answered the widget's own questions. Either the port is not the widget, or the widget is stuck: - Check the port's name on the **Connect** sheet. Another USB serial adapter can sit in the same list. - Unplug the widget, wait a few seconds, plug it back in, and connect again. ## Unplugged while connected *The widget was disconnected* appears within a couple of seconds of the widget going away while connected: the cable was pulled, or a hub lost power. The bench disconnects, as if you had chosen to, and monitoring stops. Reports the bench already saved stay in its captures folder. Any DMX that was held has stopped, since the widget lost power with it. Plug the widget back in, into the same USB port, and the bench connects to it again by itself and looks for fixtures. Until then the status bar says the widget is unplugged; afterwards it says when the bench reconnected, so a line that dropped while you were away still shows. If you chose **Fixture → Disconnect** yourself, or the widget comes back on a different port, the bench waits for you to choose **Fixture → Connect…**. The wire log of the connection that dropped is kept too, so the packets leading up to it can still be read and saved (see [When the widget was unplugged](/help/wire-log/#when-the-widget-was-unplugged)). ## DMX works but RDM doesn't The widget sends DMX on any firmware, so a fixture that responds to levels but never answers RDM can still be the widget. Check its firmware first (see [The wrong firmware](/help/widget/#the-wrong-firmware)). If the widget is on 2.x, the fixture is where to look next: [When no fixture is found](/help/no-fixtures/). The reverse is normal: a widget that has never sent a DMX frame keeps its LED dark, even while it answers RDM. The LED lights once a frame is sent, and stays lit after the program that sent it quits, because the widget keeps repeating the frame. ## Some requests go unanswered under DMX With DMX on the line, about 2 in 100 RDM requests to one fixture in testing were never answered. Without DMX, none were lost. That is why the bench ends a frame at the fixture's last channel instead of sending all 512 slots (see [The frame](/help/send-dmx/#the-frame)). Whether the widget or the fixture loses them is not known yet. The monitor waits and asks again rather than calling the fixture gone (see [Answered late or asked twice](/help/intermittent/#answered-late-or-asked-twice)). ## Other interfaces Some interfaces from other makers copy the Enttec DMX USB Pro's protocol, and the bench may open them. RDM is where copies differ, and the bench has only been checked against a genuine Enttec. If one opens but cannot find fixtures that a genuine widget does find, the interface is the likely cause. ## From the command line `rdmbench-cli widget` reads the widget's firmware, serial number and RDM UID. It works on every firmware build, so it is the first thing to try when the app will not connect. `--port` names the port, and `rdmbench-cli ports` lists them. `--json` prints everything as one object, ready to paste into a bug report.