Exodriver | LabJack
« Close

Datasheets and User Guides

App Notes

Software & Driver



Which library to use by LabJack device

U3, U6, and UE9: Exodriver is the low-level driver for macOS and Linux. For Windows, the UD library is an easier-to-use, high-level library.

T7 and T4: Use the LJM Library, which is an easier-to-use, high-level library for Windows/Linux/macOS.

U12: For Linux and macOS, the ljacklm library is an easier-to-use, high-level driver. ljacklm requires Exodriver. See the note about installing LabJackHID for macOS below. For Windows, see the ljackuw.

See also: what software to use for which device.

Exodriver (liblabjackusb)

Download 32 and 64 bit driver source code and C/C++ examples.

Other Downloads and Resources

Introducing the Exodriver

The Exodriver (also known as liblabjackusb) is a thin interface (think exoskeleton) to LabJack devices. It’s written as a C library that uses libusb-1.0 for USB communication. The library can open, close, read from, and write to any LabJack device via USB. Because it’s a library and doesn’t have any kernel code, it’s easy to build.

macOS Quickstart

macOS users can use the pre-built installer (click to download) rather than building the Exodriver from the source. We also provide a simple Xcode project (click to download) if you would like to use Xcode to build LabJack applications with the Exodriver. C language examples are provided with the Exodriver’s source code.

If you would prefer to build the Exodriver from the source, the instructions in the next section work on macOS.

Note to U12 Users on macOS: Use the “Customize install” option of the pre-built installer to add the LabJackHID kernel extension. This is a null kernel extension which prevents the OS’s HID driver from claiming a LabJack HID device. This is only required by U12 devices, otherwise it does not need to be installed.

Quickstart: Building from the source

First, make sure the following requirements are met:

  1. A modern Linux or macOS system
  2. A C compiler (gcc, e.g., build-essential on Debian/Ubuntu, Xcode on macOS)
  3. libusb-1.0 library and header files installed (from the source or -dev binary packages)

Linux notes:

  • Most distributions have libusb-1.0 installed, and only the header/development files are needed. It is recommended to not build from source code and to use the libusb-1.0 version from your distribution's package manager.
  • If using Ubuntu or a Debian based distribution, take a look at the in-depth build instructions page. This includes Raspbian on the Raspberry Pi. It provides a full list of commands to fulfill requirements and install Exodriver.

macOS note:

Now after the requirements have been met, building the Exodriver is easy. Download the source (click the “Download ZIP” button on that page), build and install it.

On both Linux and macOS, in the Exodriver directory run

$ sudo ./install.sh

After installing the Exodriver, build the U3, U6, or UE9 example programs:

$ cd examples/U6/
$ make

Run one of example programs like this:

$ ./u6BasicConfigU6

For more information, consult INSTALL.Linux or INSTALL.MacOSX. INSTALL.Linux details which kernel versions are required, and how to manually install the driver and set device permissions properly without the install.sh script. INSTALL.MacOSX lists which releases of macOS are supported.

Known Issues

macOS: As of macOS 10.15, opening a U6 the first time after plugging it in sometimes fails. Subsequent attempts to open succeed.


Support - LJM Installer Location Reminder

Looking for software for the T7, T4 or Digit?

Support - UD Installer Location Reminder

Looking for software for the U3, U6, or UE9?

Support - U12 Installer Location Reminder

Looking for software for the U12?


The installation in ubuntu went exactly as you stated without problems, using the U3. We are now going on to the applications directory. We're somewhat new to python, so I hope we can figure it out. Thanks for all the work making this available in Linux.

Update possibility Ubuntu?

On gizhub there are nice routines included for the El-1050 in u3.py. How to update the installation best?  the "build" directory is locked...


Does the "sudo python setup.py install" not work?  That is the command for LabJackPython installation.  sudo should bypass the locked issues.  If for some reason files in the build directory are not being updated you could "sudo rm -R build" first to delete the build directory.

thanks- I started later with the cookbook - skiped the install thing and went right to the labjackpython git...

Update actions should start from the beginning?



"Update actions should start from the beginning?"

I am confused with your question here.  Running "sudo python setup.py install" will overwrite/update existing LabJackPython library files installed in your Python directory.

Here it defaults (stops) - even if beginning from the start:

sudo git clone git://github.com/labjack/exodriver.git

 destination path 'exodriver' already exists and is not an empty directory

The github u3 code is from  February and I would like to use the I2C and El-1050 functions from it...


"git clone" only works once for a repository.  If the repository's directories and files already exist on your computer you cannot use "git clone" again.  To update your files after a "git clone", go into the repository's directory (exodriver) and use the "git pull" command to update your files.  Alternatives to this are to delete the exodriver directory and perform the "git clone", or not use "git" all together and download the exodriver and LabJackPython source code from github (there is a "Downloads" button) and build/install from those.

Thanks a lot - this is the answer to version a) "error: cannot open .git/FETCH_HEAD: Permission denied

version b) works neither since the exodriver directory is locked - you cannot delete even using sudo.

I think I need some Ubuntu specialist....


Minimum U3 hardware version not met for this kernel.  This driver supports only hardware 1.30 and above.  Your hardware version is 1.21.
This hardware version is supported under kernel 2.6.28.


Running under linux kernel 2.6.18-194 x64 (Centos5.5)... Get the above error when trying to run the u3BasicConfigU3 in the example directory.



The Exodriver is detecting that your U3 has hardware version 1.21, and that your Linux kernel is less than 2.6.28.  The Exodriver does not support U3 hardware versions 1.20 and 1.21 on Linux kernels less than 2.6.28.  There is a bug between these hardware versions and older kernels that require updating the kernel to fix.

For a full list of Exodriver requirements please refer to the INSTALL.Linux file.

Exodriver_NativeUSB_Setup does not work on Mac OS X 10.5.8.

Python generated this error when importing u3:

<class 'LabJackPython.LabJackException'>: Could not load the Exodriver driver. Ethernet connectivity only.

Check that the Exodriver is installed, and the permissions are set correctly.
The error message was: dlopen(liblabjackusb.dylib, 6): no suitable image found.  Did find:
    /usr/local/lib/liblabjackusb.dylib: unknown required load command 0x8000002

Compiling/installing Exodriver from the Quickstart instructions here solved the problem.

That Python exception occurs when the Exodriver is not installed.  As for Exodriver_NativeUSB_Setup not working, can you describe how it is not working or is there an error message?


The "unknown required load command" error has been fixed in the latest Mac OS X installer update.


Hey folks,

I'm upgrading an old Xcode project of mine for a U3 done a few years ago, and it seems I missed the memo with what got taken out on the way to Exodriver-land. What happened to u3.h, u3.c and all the functions they had such as getCaliInfo and such? If someone could provide me an upgrade guide, I'd appreciate it. My U3 is a 1.20 hardware version. I'd install the old drivers (tell me again why USB needs this stuff? I like the idea of libraries much more, thanks for moving in that direction) but I'd rather stay current, and it doesn't look like you have the old driver installer handy on this here web site.





API-wise not too much has changed, just the inner workings.  The C examples still exist that include the u3.c/h files, and can be found with the Exodriver source code located here: https://github.com/labjack/exodriver.  This isn't obvious on this page's documentation now that I read it, so I'll make a note to include this when we update the page next time.  The labjackusb.h header file has the version history which explains the changes.  In the U3's case some of the pipe defines changed.  Driver installation can now be done with source code or Mac installer.  If you would like the old driver e-mail [email protected] .

For current and possibly new installations of the driver, please note the following:



In Ubuntu, and probably other distributions, there has been a change in:


The SYSFS is being out-phased and replaced with ATTR, thus you might want to change this ASAP by editing the file.

You can check beforehand in the boot.log to see if the change apply to you. If it does, you will see some error messages regarding this.


Thanks for bringing this to our attention.  I'll look into this and see what kind of changes need to be made to the 10-labjack.rules file.

I changed the 10-labjack.rules file to use ATTR instead of SYSFS.  You can find the updated file with the exodriver source code on github.


[email protected]-Aspire-5500Z:~/LabJackPython$ python

Python 2.7.2+ (default, Oct  4 2011, 20:03:08) 

[GCC 4.6.1] on linux2

Type "help", "copyright", "credits" or "license" for more information.

>>> import ue9

>>> d = ue9.UE9()

>>> d.configUE9()

Traceback (most recent call last):

  File "<stdin>", line 1, in <module>

AttributeError: 'UE9' object has no attribute 'configUE9'



That function is not available for the UE9.  You will want to use commConfig and controlConfig functions instead.  Most of the UE9 class' functions are based on the low-level functions, and the UE9 does not have a ConfigUE9 low-level function.  For a list of all available UE9 Python functions and documentation (which include some examples), look at the ue9.py source code, or use the Python help function on the UE9 class:

import ue9


I installed exodriver and LabJackPython on linux. When I want to open my U3 device in python, it fails, giving the following error: 


libusb couldn't open USB device /dev/bus/usb/006/007: Permission denied.

libusb requires write access to USB device nodes.


I realized this could be an issue with permissions, so I ran python as root, and it works perfectly. How do I get this running without root privileges?


First try disconnecting and reconnecting your U3 and see if that helps.  Your U3 may still be using the old, default udev rules from before the installation which may cause permission issues.  Reconnecting makes it use the currently installed settings.  If this does not resolve the issue, refer to the INSTALL.Linux file in the Exodriver download.  The "liblabjackusb Library Installation" section provides more details on the udev rules and what group your current user needs to be a part of so you do not need to run as root.

Probably a noob question but can the exodriver work on cygwin/Windows-7? I realize I can use the Windows driver but I like working in the Unix shell. Thanks.

The Exodriver is only supported on Linux and Mac OS X.  You may however be able to get it to work with the latest version of libusb 1.0 which now supports Windows.

ElectroLund's picture

Am I right in thinking that the Exodriver is the only method for doing 1-wire comms?  I read somewhere else that 1-wire must be done via the LJ "low-level" driver.

From the U3 User's Guide, chapter 4:

The low-level U3 functions are described in Section 5, but most Windows applications will use the LabJackUD driver instead.

The above lead me to this Exodriver page. I'm sort of surprised that it would be this convoluted to do 1-wire (or other protocols) via a LabJack.  Am I wrong?

labjack support's picture

1-wire communications can be done in the Windows UD driver, but only through using the 1-wire low-level function (command/response packets) and UD raw output/input. If you haven't already take a look at the 1-wire app note. There is also a 1-wire Python example in the LabJackPython examples. We'll be reponding shortly to your other related comment in the 1-wire low-level function page.

If you are using Tiny Core Linux you must load the following extensions in order to compile:

1.  make.tcz

2.  compiletc.tcz

3.  gcc.tcz


Thank you for providing that helpful compiler information for Tiny Core Linux users.

I received an error when I did:

$ cd ../examples/Uwhatever/
$ make

cc -Wall -g   -c -o ue9BasicCommConfig.o ue9BasicCommConfig.c
cc -o ue9BasicCommConfig ue9BasicCommConfig.o  -lm -llabjackusb
/usr/bin/ld: warning: librt.so.1, needed by /usr/lib/libusb-1.0.so.0, not found (try using -rpath or -rpath-link)
/usr/bin/ld: warning: libpthread.so.0, needed by /usr/lib/libusb-1.0.so.0, not found (try using -rpath or -rpath-link)
/usr/lib/libusb-1.0.so.0: undefined reference to `[email protected]_2.4'
/usr/lib/libusb-1.0.so.0: undefined reference to `[email protected]_2.4'
/usr/lib/libusb-1.0.so.0: undefined reference to `[email protected]_2.4'
/usr/lib/libusb-1.0.so.0: undefined reference to `[email protected]_2.4'
/usr/lib/libusb-1.0.so.0: undefined reference to `[email protected]_2.4'
collect2: error: ld returned 1 exit status
make: *** [ue9BasicCommConfig] Error 1

For me (running Archlinux on a BeagleBone) the solution was to edit the Makefile and add '-lrt -lpthread' to the line for LIBS:

$ nano Makefile

Then, change the line:

LIBS=-lm -llabjackusb

to the line

LIBS=-lm -llabjackusb -lrt -lpthread

and run make again.

Thank you for providing this information for Archlinux and BeagleBone users.  The examples are tested on Ubuntu and Fedora distributions which did not need the "-lrt" and "-lpthread" links for their versions of libusb.

I'm having trouble with your MacOS prebuilt installer (10.7.5).  After completing installation and firing up python I get the following message when trying to "import u3":

<class 'LabJackPython.LabJackException'>: Could not load the Exodriver driver. Ethernet connectivity only.

Check that the Exodriver is installed, and the permissions are set correctly.
The error message was: dlopen(liblabjackusb.dylib, 6): no suitable image found.  Did find:
        /usr/local/lib/liblabjackusb.dylib: stat() failed with errno=13

Any advice on how to proceed/troubleshoot would be appreciated.  If this is truly a permissions issue which is the file(s) that need to have permissions changed and where are they.

One think that may be an issue for me is when to connect the U3.  Does this need to be attached prior to running the installer?





"stat() failed with errno=13" indicates file or folder permission issues.  Check your /usr/local/lib directory and make sure both the directory and the library files (libusb and liblabjackusb) have read and execute permissions for all users and groups.  The installer should install the files with the correct file permissions, and /usr/local/lib should have these permissions but I've seen cases where this is not true.

Using a terminal you can check permissions with the following commands:

ls -l /usr/local/
ls -l /usr/local/lib

Permissions should look like "drwxr-xr-x" or "-rwxr-xr-x".  To change the permissions in a terminal use the chmod command on the directory and files you want to change.  For example, to add read and execute permissions to the /usr/local/lib directory for all users and groups use this command:

sudo chmod a+rx /usr/local/lib

The U3 does not need to be connected prior to running the installer.


This might be a noob problem. But when I try to "make" the libusb i get an error: "too many #pragma options align=reset" in /System/Library/Frameworks/IOKit.framework/Headers/usb/USB.h .

Does anybody have a solution for this problem?

"./configure" needs to be ran before "make".  Did you do that first?

Of course I did do ./configure beforehand. After using ./configure CC=clang it worked. But what else do I have to change now because of this?


Currently we only support and tested building the Exodriver with gcc.  Try building the Exodriver like normal and see if that works.  Otherwise, if you haven't done so already, download and install XCode (it includes gcc) and then try building libusb and Exodriver with the default configuration.  If you are having trouble with building and installing libusb look at their documentation in their download.

If you do not want to worry about compiling, you can use the Mac installer on this page which installs both libusb and Exodriver (32 and 64-bit) for you.

I feel I must be doing something wrong without realizing it.

I installed the exodriver with the Mac installer, but when I try to compile/run the simple Xcode project in XCode 4.6.2, it fails with the following error: "The run destination My Mac 64–bit is not valid for Running the scheme 'Exodriver example'. The scheme 'Exodriver example' contains no buildables that can be built for the SDKs supported by the run destination My Mac 64–bit. Make sure your targets all specify SDKs that are supported by this version of Xcode."

From Qt Creator, using C++ with either GCC or Clang I received the error "Symbols not found for architecture x86_64" when trying to call any LabJackUSB function after including the header file (#include "labjackusb.h").

From terminal, I saw that the exodriver seems to have all three possible architectures (x86, x86_64, and PPC).

Uncertain why it wasn't working, I followed the instructions above to rebuild libusb-1.0 and the exodriver from source. I confirmed that both installed "correctly":

/usr/local/lib/libusb-1.0.dylib: Mach-O universal binary with 2 architectures
/usr/local/lib/libusb-1.0.dylib (for architecture i386):    Mach-O dynamically linked shared library i386
/usr/local/lib/libusb-1.0.dylib (for architecture x86_64):    Mach-O 64-bit dynamically linked shared library x86_64

/usr/local/lib/liblabjackusb.dylib: Mach-O universal binary with 2 architectures
/usr/local/lib/liblabjackusb.dylib (for architecture i386):    Mach-O dynamically linked shared library i386
/usr/local/lib/liblabjackusb.dylib (for architecture x86_64):    Mach-O 64-bit dynamically linked shared library x86_64

However, I get precisely the same errors from XCode and Qt Creator. I've installed both XCode and the optional command line tools for XCode, as well as Clang and GCC through Qt.

My computer is an Intel MacBook Pro running OSX 10.8.4 ("Mountain Lion").  Is there a way to use a LabJack with C++ on a computer of this type?

Do the examples from the Exodriver source code compile/run correctly?


I fixed the Xcode example and it will work on OS X 10.8 now (I tested). The project settings were set to use the OS X 10.6 SDK, but it is now set to use the current OS X SDK of the user. Thanks for making us aware of this.

As for QT creator, are you linking to the Exodriver in your project/Makefile? The link option is typically "-llabjackusb".

Also, I tested the Exodriver source code examples I linked to on OS X 10.8 and they are working.

Hi, pardon my ignorance, I've got a U6 labjack device and I would like to use it with Psychtoolbox. I've installed the pre-built installer from the website, however, I'm still unsure of how this will interface with Psychtoolbox. Would someone be so kindly to point out what else I will require to do in order to use the Labjack device to send TTL triggers via the Macbook?


I believe you can use MATLAB scripts/code. Currently we do not have Mac OS X MATLAB examples, but someone on the forum wrote a U6 MATLAB class that could help:


I am not sure if the class provides digital I/O functionality. If not, you can set a digital line using the Feedback low-level function with Bit/PortStateWrite IOType:


The Exodriver source code provides U6 C examples that demonstrate this.

A quick note, with a LabJack T7 or UE9 you can communicate through TCP which most languages support and not use the USB driver.


thanks for the reply. If I understood correctly, by using the pre-built installer as specified in the earlier text, I should have install exodriver in my macbook pro and I'm now ready to use the scripts to control U6 device?


The Mac OS X installer installs our USB driver (Exodriver). Psychtoolbox seems to runs in MATLAB so you should be able to access our driver through MATLAB scripts. The first link I provided will give a helpful starting point on that.

Hi, I installed the pre-installer for Mac OSX and tried to test the labjack system, however I get an error message like this:

PTB-INFO: Connection to Psychtoolbox kernel support driver instance #0 (Revision 0) established.

PTB-INFO: Connection to Psychtoolbox kernel support driver instance #1 (Revision 0) established.

---> labJack: Loading the exodriver library failed: Failed to preprocess the input file.

 Output from preprocessor is:/bin/bash: gcc-4.2: command not found

 | open method


I'm not sure what I did wrong, and how I can resolve this issue.

Please help! Thanks.

I believe this is a MATLAB issue. First, make sure you have XCode installed as it installs gcc. If you are still getting the problem then apparently Xcode is not installing "gcc-4.2" like MATLAB is expecting, but "gcc" should be installed. Someone on our forum was also having this issue and resolved the problem by creating a "gcc-4.2" alias/shortcut to "gcc" using the terminal. See if that helps your issue out.


http://ss64.com/osx/alias.html - helpful alias reference

Hi LabJack

I had my UE9 running via USB with my x86 based LapTop with Ubuntu 10.10.
'exodriver/examples/UE9/ue9SingleIO' was running fine.

After ugrade Ubuntu 10.10 -> 12:04 I ran into problems.

I did run the exodriver/install.sh again, no complaints.

But running the 'ue9SingleIO' now fail if run by me, ok as root:

$ ./ue9SingleIO
Open error: could not find a UE9 with a local ID or serial number of -1
$ sudo ./ue9SingleIO
[sudo] password for xyz:
Set DAC0 voltage to 2.500 V ...
Voltage read from AI0: 0.5098 V
Temperature read internal temperature sensor (channel 133): 289.5 K

Accecs trouble seems to be here...

strace ./ue9SingleIO
open("/dev/bus/usb/007/002", O_RDWR)    = -1 EACCES (Permission denied)
write(2, "libusb error: LIBUSB_ERROR_ACCES"..., 34libusb error: LIBUSB_ERROR_ACCESS

$ ls -l /dev/bus/usb/007/002
crw-rw-r-- 1 root root 189, 769 sep 28 23:22 /dev/bus/usb/007/002
$ ls -l /dev/bus/usb/007/
totalt 0
crw-rw-r-- 1 root root 189, 768 sep 28 22:49 001
crw-rw-r-- 1 root root 189, 769 sep 28 23:22 002
$ ls -l /dev/bus/usb/
totalt 0
drwxr-xr-x 2 root root 60 sep 29  2013 001
drwxr-xr-x 2 root root 80 sep 29  2013 002
drwxr-xr-x 2 root root 60 sep 29  2013 003
drwxr-xr-x 2 root root 60 sep 29  2013 004
drwxr-xr-x 2 root root 80 sep 29  2013 005
drwxr-xr-x 2 root root 60 sep 29  2013 006
drwxr-xr-x 2 root root 80 sep 28 22:56 007

Owner / Group = root  root, should it be root / adm ?

Is this perhaps changed between the Ubuntu releases?

Please advice how to proceed.

By the way, my user is member of groups:
[email protected]:~$ groups
xyz adm dialout fax cdrom floppy tape audio dip video plugdev fuse netdev lpadmin admin sambashare

Also, there was nother libusb used than i expected.
$ ldd ./ue9SingleIO
        linux-gate.so.1 =>  (0x003fd000)
        libm.so.6 => /lib/i386-linux-gnu/libm.so.6 (0x004fc000)
        liblabjackusb.so => /usr/local/lib/liblabjackusb.so (0x00ec3000)
        libc.so.6 => /lib/i386-linux-gnu/libc.so.6 (0x00528000)
        /lib/ld-linux.so.2 (0x00262000)
        libusb-1.0.so.0 => /lib/i386-linux-gnu/libusb-1.0.so.0 (0x009eb000)
        librt.so.1 => /lib/i386-linux-gnu/librt.so.1 (0x00937000)
        libpthread.so.0 => /lib/i386-linux-gnu/libpthread.so.0 (0x00d58000)


/Roger S

Hi LabJack

I did post an entry here during the weekend about usb device write permission denied,
and I think I have to correct myself.

The Ubuntu upgrade I did was from 11.10 to 12.04.

Later I tried download the latest version from
git clone git://github.com/labjack/exodriver.git
and run the insallation again. Write permission trouble reman.

Roger S


This is in response to both your posts. Yes, the owner/group should be root/adm after running install.sh.

Did you try power cycling your UE9 afterwards? If you had your UE9 connected during installation it could still be using the default root/root permissions and not the root/adm permissions from the newly installed 10-labjack.rules udev rules file. Power cycling the LabJack or restarting Ubuntu will resolve this issue and from then on the root/adm permissions will be in effect.

Also, if you were not part of the adm group before running the installer script you will need to log off the user and log back in for the group changes to take effect.

No, reboot of computer, power cycle of UE9, log out - login does not change this.
User group membersip seems to be as expected. Write access denied still.

But I think I have found the problem. 10-labjack.rules in two places,

After hiding (renaming) the
the access trouble dissapeared.

This was the old version, right?
$ cat /etc/udev/rules.d/10-labjack.rules
SUBSYSTEM!="usb_device", ACTION!="add", GOTO="labjack_rules_end"

# U3
SYSFS{idVendor}=="0cd5", SYSFS{idProduct}=="0003", GROUP="adm"
# U6
SYSFS{idVendor}=="0cd5", SYSFS{idProduct}=="0006", GROUP="adm"
# UE9
SYSFS{idVendor}=="0cd5", SYSFS{idProduct}=="0009", GROUP="adm"
# U12
SYSFS{idVendor}=="0cd5", SYSFS{idProduct}=="0001", GROUP="adm"
# SkyMote Bridge
SYSFS{idVendor}=="0cd5", SYSFS{idProduct}=="0501", GROUP="adm"


Now I have only this one. The new one, right?
$ cat /lib/udev/rules.d/10-labjack.rules         
SUBSYSTEM!="usb_device", ACTION!="add", GOTO="labjack_rules_end"

# LabJack Vendor ID
ATTRS{idVendor}=="0cd5", GROUP="adm"


Maybe exodriver/install.sh could check for this?
Anyway, my system is running again now.

Roger S

/etc/udev/rules.d was the old default installation directory for the rules, but with the current install script it is /lib/udev/rules.d by default and the /etc path as an alternative if the /lib path is not found. The issue might of been that udev was using the rules file from /etc that used SYSFS. SYSFS was deprecated and supposed to be removed from udev at some point, and we changed it to ATTRS a couple of years ago.  I can look into updating the install script to account for this and remove duplicates to ensure the latest rules are being used. Thank you for pointing this out.

Update: The newest version of install.sh checks for the old rules file and removes it.