Q Light Controller+

I've been using my Enttec open dmx usb with qlc for some years without problems until some time before devolopment stopped there, when suddenly it wouldn't work. I discovered that it was because of a problem with reading the serial number. I made a patch to work around the problem. When I now tried qlc+, it has the same problem. I don't know the real reason, it could be that my device is broken, but I don't think so. Anyway, here's the patch, although I think it's not the correct way to fix it...

Robert

~~~~~~~
diff -Naur qlcplus-4.4.1-old/plugins/dmxusb/src/qlcftdi-libftdi.cpp qlcplus-4.4.1-new/plugins/dmxusb/src/qlcftdi-libftdi.cpp
--- qlcplus-4.4.1-old/plugins/dmxusb/src/qlcftdi-libftdi.cpp 2013-08-29 12:19:40.000000000 +0200
+++ qlcplus-4.4.1-new/plugins/dmxusb/src/qlcftdi-libftdi.cpp 2013-09-13 15:43:31.536740169 +0200
@@ -269,7 +269,7 @@
return true;

if (ftdi_usb_open_desc(&m_handle, QLCFTDI::VID, QLCFTDI::PID,
- name().toAscii(), serial().toAscii()) < 0)
+ name().toAscii(), NULL) < 0)
{
qWarning() << Q_FUNC_INFO << name() << ftdi_get_error_string(&m_handle);
return false;
~~~~~~~

Your patch wouldn't work when more than one FTDI adapter is connected at the same time.
Maybe you should concentrate on why the serial number of your adapter causes the problem. Linux's dmesg helps you.
If the adapter EEPROM is corrupted and the serial number cannot be read, then maybe that can cause issues.

Yes, I think I know why it doesn't work. My FTDI adapter doesn't seem to have a Serial number, or it can't be read.

dmesg doesn't give any error messages, I think:

~~~~~
[677859.538691] usb 1-1.4: new full-speed USB device number 4 using ehci-pci
[677859.828549] usbcore: registered new interface driver usbserial
[677859.828563] usbcore: registered new interface driver usbserial_generic
[677859.828572] usbserial: USB Serial support registered for generic
[677859.836526] usbcore: registered new interface driver ftdi_sio
[677859.836545] usbserial: USB Serial support registered for FTDI USB Serial Device
[677859.836698] ftdi_sio 1-1.4:1.0: FTDI USB Serial Device converter detected
[677859.836770] usb 1-1.4: Detected FT232BM
[677859.836772] usb 1-1.4: Number of endpoints 2
[677859.836774] usb 1-1.4: Endpoint 1 MaxPacketSize 64
[677859.836776] usb 1-1.4: Endpoint 2 MaxPacketSize 64
[677859.836778] usb 1-1.4: Setting MaxPacketSize 64
[677859.837074] usb 1-1.4: FTDI USB Serial Device converter now attached to ttyUSB0
~~~~~

But iSerial in lsusb -v is listed as 0, which I guess means no iSerial was found:

~~~~~
Bus 001 Device 004: ID 0403:6001 Future Technology Devices International, Ltd FT232 USB-Serial (UART) IC
Device Descriptor:
bLength 18
bDescriptorType 1
bcdUSB 1.10
bDeviceClass 0 (Defined at Interface level)
bDeviceSubClass 0
bDeviceProtocol 0
bMaxPacketSize0 8
idVendor 0x0403 Future Technology Devices International, Ltd
idProduct 0x6001 FT232 USB-Serial (UART) IC
bcdDevice 4.00
iManufacturer 1 FTDI
iProduct 2 USB Serial
iSerial 0
...

~~~~~

There is no other hints that there is something wrong with my adapter. With the patch it works perfectly. Do you know of some other way I can test what's actually happening? If not I'll just have to patch new releases of qlcplus. When I was reporting this last year in the qlc mailing list, there was someone else who also had the same problem, so maybe it's something common to this type of adaptor.

>From: Alex Paul - 2012-08-04 22:40
>
>I've been having the same issue, also with Arch, for a few weeks as
>well. I've found that using tags/3.2.2 does work, so I know that it's
>not a hardware or library issue.

Luckily for me, I don't have or need more than one adaptor, so I will be fine But this might be of some help if someone else have the same problem.

Robert

Hi,
it seems that I have similar problem. I used to run Enttec open dmx usb clone on two different OSX machines with QLC 3.2.2 - no problem. When I try the latest QLC+ 4.6.1
- the interface is recognized (working properly);
- instead of some normal SN there are just garbage symbols which change on restart;
- the second led on interface does not lit (it does when old QLC is running);
- no DMX signals come out of the interface.

As I need only one interface I would like to try this patch Robert posted, but (please bear with non programer) where and how can I use it?

I have the same problem as Janez described above. I use QLC+ 4.6.1 running on Mac OS X 10.9 Mavericks. My USB2DMX (by JMS) interface is not responding and behaving the same way as described above:
- the interface is recognized (working properly);
- instead of some normal SN there are just garbage symbols which change on restart;
- the second led on interface does not lit (it does when old QLC is running);
- no DMX signals come out of the interface.

Two remarks:
- I already disabled the "AppleD2XX embedded driver as I read in other posts
- the USB2DMX (by JMS) IS working with some other free software I downloaded and tried out, just pointing out that the DMX device is not broken or so... The DMX interface is recognized as "Enttec Open Dmx USB"

Any help here would be much appreciated.

FYI - I also tried using the "Enttec DMX USB PRO" interface (got it from my brother for testing) , and that works perfectly.

Look for FtProg utility on the FTDI website. It allows you to set the serial number to whatever you want. I'm not sure if it supports OSX, I used it on Windows.

In Linux I saw garbage in serial number when I didn't have proper privileges to communicate with the card.

I sort of have a similar problem in that my generic FTDI USB-DMX card is recognised by OSX and a valid serial number is displayed. It's also recognised by QLC+ on the Mac (FT232R USB UART (S/N: AD01XXT9)), but there's no DMX output. However same card with QLC+ in a virtual Win 7 PC on same Mac works perfectly. I'm about to pull my hair out since I work almost exclusively in a Mac environment. Any suggestions for a better OSX compatible controller card?

Hey guys, not sure if this is the answer or is a repeat of what has already been written but I found out there is indeed a driver problem with OSX Mavericks 10.9 disabling any D2XXX drivers. Compiling what I learned after a lot of digging around, if you want to use your USB DMX card (FDTI based) under 10.9, open a terminal and copy this:

sudo mv /System/Library/Extensions/IOUSBFamily.kext/Contents/PlugIns/AppleUSBFTDI.kext /System/Library/Extensions/IOUSBFamily.kext/Contents/PlugIns/AppleUSBFTDI.disabled

Type your root password when asked for and reboot your system. Alternatively there is a simple utility to do the same here:

http://www.dmxis.com/os-x-mavericks-iss ... how-buddy/

This utility has worked a treat in my case at least. Hope this in someway helps.

Exactly what it's written in the QLC+ documentation, Questions & Answers page.

And here too: https://sourceforge.net/p/qlcplus/discu ... it=25#1630

Sorry to say, but have done that long time before writing my post here. Still does NOT work in my case...
Strange thing is, that the OPEN-USB-DMX device works perfectly fine on the same MacBook Pro, same OS X version, with other DMX software (recognized as Enttec Open USB DMX)... (that software package has files as ftd2.cfg, libd2xx_table.dylib and libftd2xx.1.2.2.dylib embedded in the app-package - don't know if that makes a difference or not for activating the device properly)
ALSO, QLC+ works perfectly together with another DMX device, the Enttec DMX USB PRO.
I'm not an expert in these things, but only can notice that QLC+ software together with an Open USB DMX device is not working on my MAC.
Heard from the Vendor of the DMX device, that more people seem to be facing the same problem.
Thx for reviewing this !!!

I finnaly solved my problem by using FT_PROG 2.8.2.0 - EEPROM Programming Utility which can be downloaded from http://www.ftdichip.com/Support/Utilities.htm (runs on Windows only)

Lack of SerialNumber in my Enttec open dmx usb clone prevented communication with QLC+ and following FT_PROG instructions it was easy to flash the chip with autogenerated serial number.

Now everythings works as expected and I am ready to do some lights
Thanks Massimo and all contributors for making fantastic software!

Thank you Jano for perfect advice. Mystery solved!

For my Enttec opendmxusb clone by JMS (limited Edition, bought 2007) it seems to be that FT_Prog doesn't work.
With reinstalled newest CDM-Drivers, I have tried also with the EEPROM function demos, coded in VB6 - without any success in reading out data, therefore I'd like to ascribe that Mr. JMS has saved some connections on that PCB to the FT232BL chip...
So, preliminary thankful for Roberts "Patch" it is the first time for me on Linux at all, that I can have usable dmx output with that device.
@massimo: I agree, this solution is not very satisfying and I like to know too, how the zero SN from lsusb or dmesg gets to that garbage symbols, randomly changing each time I'm refreshing the device in its Options dialog.
Here's that piece of the Log after two tries:
virtual void DMXUSB::configure()
serial: "" name: "USB Serial" vendor: "FTDI"
void IOPluginCache::slotConfigurationChanged()
serial: "`v³Âÿ" name: "USB Serial" vendor: "FTDI"
void IOPluginCache::slotConfigurationChanged()
serial: " ù" name: "USB Serial" vendor: "FTDI"
void IOPluginCache::slotConfigurationChanged()

If this garbage is not coming directly from the device, perhaps we can give serial a default value, up-counting like "device1" and used if it is read empty?
I' m not good enough in c++ to realize this thought, but if someone can give me assistance I'm ready to debug it...

Manfred, that might happen the first time you install QLC+.
Restart udev or reboot your computer.

no, udev was restarted and I'm member of dialout too, so I have all needed rights to that dev.
I have made the 4.7.4 Git on this machine a few days ago, and
have the meanwhile patched release v. on my laptop, running both on opensuse 13.1.
I've had only an output with that NULL instead of serial().toLatin()

BTW, OSL 13.1 is picky about the rules:
I need SUBSYSTEM=="usb" without *, otherwise I get "invalid rule"
and SYSFS{idVendor} causes "unknown key" in /var/log/messages.