When the widget won't connect

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 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).

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). If the widget is on 2.x, the fixture is where to look next: When no fixture is found.

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). 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).

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.