FTDI Device not showing up

[Lars Benson]

hello,

I'm trying to get my ultraDMX micro to work with OLA.
I believe the device is started and recognized by olad, but it does not show up as an available device.

lsusb gives:

Bus 001 Device 006: ID 03f0:0024 Hewlett-Packard KU-0316 Keyboard
Bus 001 Device 005: ID 03f0:7411 Hewlett-Packard
Bus 001 Device 004: ID 046d:c018 Logitech, Inc. Optical Wheel Mouse
Bus 001 Device 003: ID 040b:2000 Weltrend Semiconductor
Bus 001 Device 002: ID 1a40:0101 Terminus Technology Inc. 4-Port HUB
Bus 001 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub
Bus 005 Device 002: ID 0403:6001 Future Technology Devices International, Ltd FT232 USB-Serial (UART) IC
Bus 005 Device 001: ID 1d6b:0001 Linux Foundation 1.1 root hub
Bus 004 Device 001: ID 1d6b:0001 Linux Foundation 1.1 root hub
Bus 003 Device 001: ID 1d6b:0001 Linux Foundation 1.1 root hub
Bus 002 Device 001: ID 1d6b:0001 Linux Foundation 1.1 root hub

here is olad start log:
olad -l 3
Olad.cpp:84: OLA Daemon version 0.9.0
OlaDaemon.cpp:109: Using configs in /home/ben/.ola
TCPSocket.cpp:189: bind to 127.0.0.1:9010 failed, Address already in use
OlaDaemon.cpp:122: Could not listen on the RPC port, you probably have another instance of olad running
ben@Odin:~/.ola$ olad -l 3
Olad.cpp:84: OLA Daemon version 0.9.0
OlaDaemon.cpp:109: Using configs in /home/ben/.ola
AvahiDiscoveryAgent.cpp:201: Client state changed to AVAHI_CLIENT_S_RUNNING
OlaServer.cpp:493: Updated PID definitions.
OlaServer.cpp:212: Server UID is 7a70:7b03a8c0
HTTPServer.cpp:461: HTTP Server started on port 9090
AvahiDiscoveryAgent.cpp:236: State for OLA Web Console._http._tcp,_ola, group 0x9261020 changed to AVAHI_ENTRY_GROUP_UNCOMMITED
AvahiDiscoveryAgent.cpp:334: Adding _ola._sub._http._tcp
AvahiDiscoveryAgent.cpp:342: Failed to add _ola._sub._http._tcp
AvahiDiscoveryAgent.cpp:236: State for OLA Web Console._http._tcp,_ola, group 0x9261020 changed to AVAHI_ENTRY_GROUP_REGISTERING
PluginManager.cpp:77: Skipping ArtNet because it was disabled
PluginManager.cpp:77: Skipping Dummy because it was disabled
PluginManager.cpp:77: Skipping E1.31 (sACN) because it was disabled
PluginManager.cpp:77: Skipping ESP Net because it was disabled
PluginManager.cpp:77: Skipping KarateLight because it was disabled
PluginManager.cpp:77: Skipping KiNET because it was disabled
PluginManager.cpp:77: Skipping Milford Instruments because it was disabled
PluginManager.cpp:77: Skipping Enttec Open DMX because it was disabled
PluginManager.cpp:77: Skipping OSC because it was disabled
PluginManager.cpp:77: Skipping Renard because it was disabled
PluginManager.cpp:77: Skipping SandNet because it was disabled
PluginManager.cpp:77: Skipping ShowNet because it was disabled
PluginManager.cpp:77: Skipping SPI because it was disabled
PluginManager.cpp:77: Skipping StageProfi because it was disabled
PluginManager.cpp:77: Skipping Serial USB because it was disabled
PluginManager.cpp:77: Skipping USB because it was disabled
PluginManager.cpp:77: Skipping Pathport because it was disabled
PluginManager.cpp:108: Trying to start FTDI USB DMX
FtdiWidget-libftdi.cpp:291: Found FTDI device. Vendor: 'DMXking.com', Name: 'DMX USB PRO', Serial: '6AX2VATM'
FtdiWidget-libftdi.cpp:299: Unknown FTDI device with vendor string: 'DMXKING.COM'
PluginManager.cpp:112: Started FTDI USB DMX
AvahiDiscoveryAgent.cpp:236: State for OLA Web Console._http._tcp,_ola, group 0x9261020 changed to AVAHI_ENTRY_GROUP_ESTABLISHED

When I run ola_dev_info - it returns no devices

Here is my udev rule:
cat /etc/udev/rules.d/30-ftdidmx.rules
# udev rules for ftdi devices
SUBSYSTEM=="usb|usb_device", ACTION=="add", ATTRS{idVendor}=="0403", ATTRS{idProduct}=="6001", GROUP="plugdev"

I'm just stuck at this point.

Any help would be greatly appreciated.

Lars

[RenZO]

Hello,

I guess this device doesn't use the ftdi plugin (which is for rs485 adapters), but the serial usb plugin.
Try to disable ftdidmx and enable usbserial.

RenZO

[Lars Benson]

Ok, thanks a lot I will give it a try.
Can you explain how you figured out it's using the usb plugin?

[Peter Newman]

I think you have two copies of OLA running, see the bind error. Kill both and try again.

[Leslie Rhorer]

I am having precisely the same issue, except without the bind error.  My udev rule is the same, and the ID string from lsusb is the same.

DMXHost:~/.ola$ olad -l 3
Olad.cpp:84: OLA Daemon version 0.9.1
OlaDaemon.cpp:114: Using configs in /home/lrhorer/.ola
OlaServer.cpp:494: Updated PID definitions.
OlaServer.cpp:212: Server UID is 7a70:3601a8c0
HTTPServer.cpp:463: HTTP Server started on port 9090

PluginManager.cpp:77: Skipping ArtNet because it was disabled

PluginManager.cpp:77: Skipping E1.31 (sACN) because it was disabled
PluginManager.cpp:77: Skipping ESP Net because it was disabled
PluginManager.cpp:77: Skipping KarateLight because it was disabled
PluginManager.cpp:77: Skipping KiNET because it was disabled
PluginManager.cpp:77: Skipping Milford Instruments because it was disabled
PluginManager.cpp:77: Skipping Enttec Open DMX because it was disabled
PluginManager.cpp:77: Skipping OSC because it was disabled
PluginManager.cpp:77: Skipping Renard because it was disabled
PluginManager.cpp:77: Skipping SandNet because it was disabled
PluginManager.cpp:77: Skipping ShowNet because it was disabled
PluginManager.cpp:77: Skipping SPI because it was disabled
PluginManager.cpp:77: Skipping StageProfi because it was disabled
PluginManager.cpp:77: Skipping Serial USB because it was disabled
PluginManager.cpp:77: Skipping USB because it was disabled
PluginManager.cpp:77: Skipping Pathport because it was disabled

PluginManager.cpp:77: Skipping UART native DMX because it was disabled
PluginManager.cpp:108: Trying to start Dummy
DeviceManager.cpp:116: Installed device: Dummy Device:1-1
PluginManager.cpp:112: Started Dummy

PluginManager.cpp:108: Trying to start FTDI USB DMX

FtdiWidget-libftdi.cpp:291: Found FTDI device. Vendor: 'DMXking.com', Name: 'DMX USB PRO', Serial: '6AXZTOUB'

[Simon Newton]

On Sat, Nov 8, 2014 at 8:14 PM, Leslie Rhorer <lrh...@mygrande.net> wrote:
>
> I am having precisely the same issue, except without the bind error. My
> udev rule is the same, and the ID string from lsusb is the same.

As odd as it sounds you don't need to use the FTDI plugin for this
device. Try enabling USB Serial.

Simon

> --
> The Open Lighting Group: open-l...@googlegroups.com, #openlighting
> (irc.freenode.org)
> To unsubscribe from this group, send email to
> open-lightin...@googlegroups.com
> For more options, visit https://groups.google.com/groups/opt_out?hl=en

[Leslie Rhorer]

On Saturday, November 8, 2014 11:07:36 PM UTC-6, Simon Newton wrote:

On Sat, Nov 8, 2014 at 8:14 PM, Leslie Rhorer <lrh...@mygrande.net> wrote:
>
> I am having precisely the same issue, except without the bind error.  My
> udev rule is the same, and the ID string from lsusb is the same.

As odd as it sounds you don't need to use the FTDI plugin for this
device. Try enabling USB Serial.

Simon

Unfortunately, that doesn't do it, or at least not simply enabling the ola-usbserial.conf file.  OLAD starts the serial USB driver, but it doesn't seem to register the device.  Only the dummy device comes up when I try to define a universe.  I don't know if this helps, but from lsmod:

DMXHost:~/.ola$ lsmod | grep ftdi
ftdi_sio               41955  0
usbserial              31597  1 ftdi_sio
usbcore               170994  5 btusb,usbserial,ftdi_sio,xhci_hcd

[Simon Newton]

Please post the olad logs.

--

[Leslie Rhorer]

Unless I am missing something, the logs are uninformative.  The init script is broken.  (I'm really starting to move over to the camp that hates systemctl.)  If I try to run `olad --daemon --syslog`, I get "Failed to initialize event logging".  Olad runs as a daemon, but nothing shows up in syslog.  If I run `olad -l 3` I get the above if FTDI is enabled, and the following if usbserial is enabled:

DMXHost:/root$ olad -l 3

Olad.cpp:84: OLA Daemon version 0.9.1
OlaDaemon.cpp:114: Using configs in /home/lrhorer/.ola
OlaServer.cpp:494: Updated PID definitions.
OlaServer.cpp:212: Server UID is 7a70:3601a8c0
HTTPServer.cpp:463: HTTP Server started on port 9090
PluginManager.cpp:77: Skipping ArtNet because it was disabled
PluginManager.cpp:77: Skipping E1.31 (sACN) because it was disabled
PluginManager.cpp:77: Skipping ESP Net because it was disabled
PluginManager.cpp:77: Skipping KarateLight because it was disabled
PluginManager.cpp:77: Skipping KiNET because it was disabled
PluginManager.cpp:77: Skipping Milford Instruments because it was disabled
PluginManager.cpp:77: Skipping Enttec Open DMX because it was disabled
PluginManager.cpp:77: Skipping OSC because it was disabled
PluginManager.cpp:77: Skipping Renard because it was disabled
PluginManager.cpp:77: Skipping SandNet because it was disabled
PluginManager.cpp:77: Skipping ShowNet because it was disabled
PluginManager.cpp:77: Skipping SPI because it was disabled
PluginManager.cpp:77: Skipping StageProfi because it was disabled

PluginManager.cpp:77: Skipping Pathport because it was disabled

PluginManager.cpp:77: Skipping FTDI USB DMX because it was disabled

PluginManager.cpp:77: Skipping UART native DMX because it was disabled
PluginManager.cpp:108: Trying to start Dummy
DeviceManager.cpp:116: Installed device: Dummy Device:1-1
PluginManager.cpp:112: Started Dummy

PluginManager.cpp:108: Trying to start Serial USB
PluginManager.cpp:112: Started Serial USB
PluginManager.cpp:108: Trying to start USB
PluginManager.cpp:112: Started USB

[Leslie Rhorer]

When I plug in an Anyma clone, it is recognized.  If I then plug in the DMXKing controller, I get:

WidgetDetectorThread.cpp:204: Found potential USB Serial device at /dev/ttyUSB0
IOUtils.cpp:38: Failed to open /dev/ttyUSB0: Permission denied

Repeating over and over again.  I don't know why permission is being denied (or at least it thinks it is), since the user olad is a member of the dialout group, and dialout has group ownership of /dev/ttyUSB0:

crw-rw---- 1 root dialout 188, 0 Nov  9 02:36 /dev/ttyUSB0

[Simon Newton]

On Sun, Nov 9, 2014 at 12:09 AM, Leslie Rhorer <lrh...@mygrande.net> wrote:
> Unless I am missing something, the logs are uninformative. The init script
> is broken. (I'm really starting to move over to the camp that hates
> systemctl.) If I try to run `olad --daemon --syslog`, I get "Failed to
> initialize event logging".

What platform and version of OLA are you running? From my reading of
the code that message should only occur on WIN32 platforms.

Simon

[Simon Newton]

Ok, that's progress. You just have to solve the permissions error and
it should start working.

Are you sure olad is running under the user olad? What happens if you
change ownership of the device to your user account and run olad from
the command line?

Simon

[Leslie Rhorer]

On Sunday, November 9, 2014 3:12:12 AM UTC-6, Simon Newton wrote:

On Sun, Nov 9, 2014 at 12:09 AM, Leslie Rhorer <lrh...@mygrande.net> wrote:
> Unless I am missing something, the logs are uninformative.  The init script
> is broken.  (I'm really starting to move over to the camp that hates
> systemctl.)  If I try to run `olad --daemon --syslog`, I get "Failed to
> initialize event logging".

What platform and version of OLA are you running? From my reading of
the code that message should only occur on WIN32 platforms.
Simon

Debian "Jessie" linux, kernel 3.16-2-686-pae
OLA olad version: 0.9.1

[Leslie Rhorer]

On Sunday, November 9, 2014 3:13:16 AM UTC-6, Simon Newton wrote:

On Sun, Nov 9, 2014 at 12:56 AM, Leslie Rhorer <lrh...@mygrande.net> wrote:
> When I plug in an Anyma clone, it is recognized.  If I then plug in the
> DMXKing controller, I get:
>
> WidgetDetectorThread.cpp:204: Found potential USB Serial device at
> /dev/ttyUSB0
> IOUtils.cpp:38: Failed to open /dev/ttyUSB0: Permission denied
>
> Repeating over and over again.  I don't know why permission is being denied
> (or at least it thinks it is), since the user olad is a member of the
> dialout group, and dialout has group ownership of /dev/ttyUSB0:
>
> crw-rw---- 1 root dialout 188, 0 Nov  9 02:36 /dev/ttyUSB0

Ok, that's progress. You just have to solve the permissions error and
it should start working.

Oh, hey, I used sudo to run as user olad, and it worked!

Are you sure olad is running under the user olad?

No, I was running it under my account.  Olad is not set up as a real user, so I can't su to olad.  I can sudo as olad, however.
 

What happens if you
change ownership of the device to your user account and run olad from
the command line?

Well, it works.  Either is a bit of a kludge, though. I still don't have logging to syslog working, either.

[Peter Newman]

Leslie, can you give us any more diagnosis on syslog, as Simon commented, the line you mentioned should be Windows only, it may be that something as changed as it looks like you're running a fairly new version of the kernel.

[Christian Windeck]

Hello,

I also had a problem with my FTDI device not showing up in ola but the problem was a wrog productID (namely 0x0000 and not 0x6001).
That caused the plugin to skip the device.
I was able to fix this issue by falshing the EEPROM using FT_Prog from the FTDI website.
You could try checking your pID using

lsubs-v

[Jason Kyle]

If your PID was 0x0000 then it’s not a genuine FTDI chip and searching around a little you’ll see that FTDI started bricking clones by re-writing PID to 0x0000. Not a great move by FTDI some would say and it’s created a fair amount of discussion!

All DMXking products use genuine FTDI chips so won’t suffer from PID 0x0000 issues.

 

In the lsusb output below you can see the device in question is VID 0403 PID 6001 which is correct.

 

Has anyone else encountered PID 0x0000 issues with their USB DMX devices? I’m curious to know how much of an issue it is for lighting people.

--

[Christian Windeck]

Yes I head of that one. And this is actually well possible because Windows went setting the PID to 0x0000 every time I reconnected it. Though I think it did work with ola and the rewritten PID.

I also discovered someone else. His PID was was 0xe... something

b...@Odin:~/.ola$ olad -l 3

[Jason Kyle]

I believe since early this year the Windows FTDI driver has been detecting and re-writing PIDs. The “issue” became widespread when FTDI pushed out a new driver release via Windows Update and many people got caught out. To my knowledge FTDI have pulled the offending driver from windows update but the version on their website v2.12.00 will brick your clone device. Go searching for an earlier version of the driver.

[Leslie Rhorer]

How can I do that, since logging fails?

[Peter Newman]

I thought logging was working earlier? Can you do it with -l 4 or lsusb?