mccdaq / uldaq

MCC Universal Library for Linux

MCC Universal Library for Linux (uldaq)

Info: Contains a library to access and control supported Measurement Computing DAQ devices over the Linux and macOS platforms. The UL for Linux binary name is libuldaq.

Author: Measurement Computing

About

The uldaq package contains programming libraries and components for developing applications using C/C++ on Linux and macOS Operating Systems. An API (Application Programming Interface) for interacting with the library in Python is available as an additional installation. This package was created and is supported by MCC.

Prerequisites:

---

Building the uldaq package requires C/C++ compilers, make tool, and the development package for libusb. The following describes how these prerequisites can be installed on different Linux distributions and macOS.

• Debian-based Linux distributions such as Ubuntu, Raspberry Pi OS

   $ sudo apt-get install gcc g++ make
   $ sudo apt-get install libusb-1.0-0-dev

• Arch-based Linux distributions such as Manjaro, Antergos

   $ sudo pacman -S gcc make
   $ sudo pacman -S libusb

• Red Hat-based Linux distributions such as Fedora, CentOS

   $ sudo yum install gcc gcc-c++ make
   $ sudo yum install libusbx-devel

• OpenSUSE

   $ sudo zypper install gcc gcc-c++ make
   $ sudo zypper install libusb-devel

• macOS (Version 10.11 or later recommended)

   $ xcode-select --install
   $ ruby -e "$(curl -fsSL https://raw.githubusercontent.com/Homebrew/install/master/install)"
   $ brew install libusb

Build Instructions

---

1. Download the latest version of uldaq:

  Linux
     $ wget -N https://github.com/mccdaq/uldaq/releases/download/v1.2.1/libuldaq-1.2.1.tar.bz2

  macOS
     $ curl -L -O https://github.com/mccdaq/uldaq/releases/download/v1.2.1/libuldaq-1.2.1.tar.bz2

2. Extract the tar file:

  $ tar -xvjf libuldaq-1.2.1.tar.bz2

3. Run the following commands to build and install the library:

  $ cd libuldaq-1.2.1
  $ ./configure && make
  $ sudo make install

Note: To install the Python interface, follow the above build instructions then go to https://pypi.org/project/uldaq/ for further installation.

Examples

The C examples are located in the examples folder. Run the following commands to execute the analog input example:

  $ cd examples
  $ ./AIn

Refer to the uldaq PyPI page for instructions on installing Python examples.

Usage

The following is a basic C example of using the Universal Library for Linux to perform analog input. Further examples are available in the Examples folder.

#include <stdio.h>
#include "uldaq.h"

#define MAX_DEV_COUNT  100
#define MAX_STR_LENGTH 64

int main(void)
{
	unsigned int numDevs = MAX_DEV_COUNT;
	DaqDeviceDescriptor devDescriptors[MAX_DEV_COUNT];
	DaqDeviceHandle handle = 0;

	int chan = 0;
	double data = 0;
	UlError err = ERR_NO_ERROR;

	// Get descriptors for all of the available DAQ devices
	ulGetDaqDeviceInventory(ANY_IFC, devDescriptors, &numDevs);
	
	// verify at least one DAQ device is detected
	if (numDevs)
	{
		// get a handle to the DAQ device associated with the first descriptor
		handle = ulCreateDaqDevice(devDescriptors[0]);

		// check if the DAQ device handle is valid
		if (handle)
		{
			// establish a connection to the DAQ device
			err = ulConnectDaqDevice(handle);

			// read data for the first 4 analog input channels
			for (chan = 0; chan <= 3; chan++)
			{
				err = ulAIn(handle, chan, AI_SINGLE_ENDED, BIP5VOLTS, AIN_FF_DEFAULT, &data);

				printf("Channel(%d) Data: %10.6f\n", chan, data);
			}

			ulDisconnectDaqDevice(handle);
			ulReleaseDaqDevice(handle);
		}
	}

	return 0;
}

Uninstall Instructions

Run the following command to uninstall the library

  $ sudo make uninstall

Support/Feedback

The uldaq package is supported by MCC. For support for uldaq, contact technical support through support page. Please include detailed steps on how to reproduce the problem in your request.

Documentation

Online help for the Universal Library for Linux is available for C/C++ and Python.

If Doxygen is installed and you wish to build the API documentation on your system, run the following commands:

  $ cd doc
  $ doxygen Doxyfile

Changelog

The changelog for this project can be found here

uldaq's Issues

When trying to install uldaq 1.2.0, it showed error: Library libusb-1.0 was not found on this system.

Hi,
I was trying to install uldaq 1.2.0 on my MacBook Pro with M1 apple silicon. After I installed libusb 1.0.24 with: brew install libusb, I tried ./configure and it showed below error, saying Library libusb-1.0 was not found on this system. Same version of uldaq was installed on another intel based MacBook Pro without any problem.

locals-MBP:libuldaq-1.2.0 local$ ./configure
checking for a BSD-compatible install... /usr/bin/install -c
checking whether build environment is sane... yes
checking for a thread-safe mkdir -p... ./install-sh -c -d
checking for gawk... no
checking for mawk... no
checking for nawk... no
checking for awk... awk
checking whether make sets $(MAKE)... yes
checking whether make supports nested variables... yes
checking for style of include used by make... GNU
checking for gcc... gcc
checking whether the C compiler works... yes
checking for C compiler default output file name... a.out
checking for suffix of executables...
checking whether we are cross compiling... no
checking for suffix of object files... o
checking whether we are using the GNU C compiler... yes
checking whether gcc accepts -g... yes
checking for gcc option to accept ISO C89... none needed
checking whether gcc understands -c and -o together... yes
checking dependency style of gcc... gcc3
checking for ar... ar
checking the archiver (ar) interface... ar
checking whether make supports nested variables... (cached) yes
checking for g++... g++
checking whether we are using the GNU C++ compiler... yes
checking whether g++ accepts -g... yes
checking dependency style of g++... gcc3
checking for gcc... (cached) gcc
checking whether we are using the GNU C compiler... (cached) yes
checking whether gcc accepts -g... (cached) yes
checking for gcc option to accept ISO C89... (cached) none needed
checking whether gcc understands -c and -o together... (cached) yes
checking dependency style of gcc... (cached) gcc3
checking build system type... arm-apple-darwin20.5.0
checking host system type... arm-apple-darwin20.5.0
checking how to print strings... printf
checking for a sed that does not truncate output... /usr/bin/sed
checking for grep that handles long lines and -e... /usr/bin/grep
checking for egrep... /usr/bin/grep -E
checking for fgrep... /usr/bin/grep -F
checking for ld used by gcc... /Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin/ld
checking if the linker (/Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin/ld) is GNU ld... no
checking for BSD- or MS-compatible name lister (nm)... /usr/bin/nm -B
checking the name lister (/usr/bin/nm -B) interface... BSD nm
checking whether ln -s works... yes
checking the maximum length of command line arguments... 786432
checking whether the shell understands some XSI constructs... yes
checking whether the shell understands "+="... yes
checking how to convert arm-apple-darwin20.5.0 file names to arm-apple-darwin20.5.0 format... func_convert_file_noop
checking how to convert arm-apple-darwin20.5.0 file names to toolchain format... func_convert_file_noop
checking for /Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin/ld option to reload object files... -r
checking for objdump... objdump
checking how to recognize dependent libraries... pass_all
checking for dlltool... no
checking how to associate runtime and link libraries... printf %s\n
checking for archiver @file support... no
checking for strip... strip
checking for ranlib... ranlib
checking command to parse /usr/bin/nm -B output from gcc object... ok
checking for sysroot... no
checking for mt... no
checking if : is a manifest tool... no
checking for dsymutil... dsymutil
checking for nmedit... nmedit
checking for lipo... lipo
checking for otool... otool
checking for otool64... no
checking for -single_module linker flag... yes
checking for -exported_symbols_list linker flag... yes
checking for -force_load linker flag... yes
checking how to run the C preprocessor... gcc -E
checking for ANSI C header files... yes
checking for sys/types.h... yes
checking for sys/stat.h... yes
checking for stdlib.h... yes
checking for string.h... yes
checking for memory.h... yes
checking for strings.h... yes
checking for inttypes.h... yes
checking for stdint.h... yes
checking for unistd.h... yes
checking for dlfcn.h... yes
checking for objdir... .libs
checking if gcc supports -fno-rtti -fno-exceptions... yes
checking for gcc option to produce PIC... -fno-common -DPIC
checking if gcc PIC flag -fno-common -DPIC works... yes
checking if gcc static flag -static works... no
checking if gcc supports -c -o file.o... yes
checking if gcc supports -c -o file.o... (cached) yes
checking whether the gcc linker (/Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin/ld) supports shared libraries... yes
checking dynamic linker characteristics... darwin20.5.0 dyld
checking how to hardcode library paths into programs... immediate
checking whether stripping libraries is possible... yes
checking if libtool supports shared libraries... yes
checking whether to build shared libraries... yes
checking whether to build static libraries... yes
checking how to run the C++ preprocessor... g++ -E
checking for ld used by g++... /Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin/ld
checking if the linker (/Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin/ld) is GNU ld... no
checking whether the g++ linker (/Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin/ld) supports shared libraries... yes
checking for g++ option to produce PIC... -fno-common -DPIC
checking if g++ PIC flag -fno-common -DPIC works... yes
checking if g++ static flag -static works... no
checking if g++ supports -c -o file.o... yes
checking if g++ supports -c -o file.o... (cached) yes
checking whether the g++ linker (/Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin/ld) supports shared libraries... yes
checking dynamic linker characteristics... darwin20.5.0 dyld
checking how to hardcode library paths into programs... immediate
checking operating system... arm-apple-darwin20.5.0
Mac OS X
checking for libusb_init in -lusb-1.0... no

Library libusb-1.0 was not found on this system.
Please install it and re-run ./configure

can we use in k8s pod?

Reading the USB counter at high rates fails

I am having trouble running ulDaqInScan on the USB-CTR08 at rates greater than 1000 Hz with UL for Linux. It works fine with cbDaqInScan on UL for Windows.

I have written a test program to demonstrate the problem.
https://github.com/epics-modules/measComp/blob/UL_for_Linux_Direct/measCompApp/src/test_USB_CTR.cpp

These are the comments at the beginning of the program that explain how to run it, and the problem I observe.

    Does a DaqInScan on a USB-CTR04/08 to test problems with rates >1000 Hz on Linux.
    Runs on both Windows and Linux.
    It reads all of the counters and the DIO.
    For best diagnostic results make the following physical connections:
    - Timer 0 connected to Counter 0 (TMR0 to C0IN).  The program configures this for 1 MHz square wave.
    - Timer 1 connected to Counter 1 (TMR1 to C1IN). The program configures this for 100 kHz square wave.
    - Timer 2 connected to Digital input 0 (TMR2 to DIO0). The program configures this for 10 Hz square wave.
    Program requires 3 arguments:
      1) The UnigueID of the device (serial number for USB, MAC address for Ethernet)
      2) The scan rate in Hz
      3) The sleep time in seconds between reading and printing the scan data
      
   The program works as expected on Windows.
   On Linux it works as expected when rate <= 1000 Hz.  
   Above 1 kHz (e.g. 2 kHz) it works the first time it is run at that rate.
   However, on subsequent runs the data is not in the right order, and the scan never stops.

This is the output running the program on Windows with rate=1000 Hz and sleep time = 50 ms. It works as expected. Counter 0 has 1000 counts in each scan point (1 MHz input), Counter 1 has 100 counts (100 kHz input), and DIO0 toggles between 0 and 1 (10 Hz input).

J:\epics\devel\measComp>bin\windows-x64-static\test_USB_CTR.exe 1E538A2 1000 .05
Found 6 DAQ device(s)
Running on Windows
Connecting to device type=USB-CTR08 serial number=1E538A2
ctrStatus=1, ctrCount=384, ctrIndex=369, counts=1000 100 0 0 0 0 0 0 0x1
ctrStatus=1, ctrCount=896, ctrIndex=882, counts=1000 100 0 0 0 0 0 0 0x0
ctrStatus=1, ctrCount=1280, ctrIndex=1269, counts=1000 100 0 0 0 0 0 0 0x1
ctrStatus=1, ctrCount=1792, ctrIndex=1782, counts=1000 100 0 0 0 0 0 0 0x0
ctrStatus=1, ctrCount=2304, ctrIndex=2295, counts=1000 100 0 0 0 0 0 0 0x1
ctrStatus=1, ctrCount=2816, ctrIndex=2799, counts=1000 100 0 0 0 0 0 0 0x0
ctrStatus=1, ctrCount=3200, ctrIndex=3186, counts=1000 100 0 0 0 0 0 0 0x1
ctrStatus=1, ctrCount=3712, ctrIndex=3699, counts=1000 100 0 0 0 0 0 0 0x0
ctrStatus=1, ctrCount=4224, ctrIndex=4212, counts=1000 100 0 0 0 0 0 0 0x1
ctrStatus=1, ctrCount=4608, ctrIndex=4599, counts=1000 100 0 0 0 0 0 0 0x0
ctrStatus=1, ctrCount=5120, ctrIndex=5103, counts=1000 100 0 0 0 0 0 0 0x1
ctrStatus=1, ctrCount=5632, ctrIndex=5616, counts=1000 100 0 0 0 0 0 0 0x0
ctrStatus=1, ctrCount=6016, ctrIndex=6003, counts=1000 100 0 0 0 0 0 0 0x1
ctrStatus=1, ctrCount=6528, ctrIndex=6516, counts=1000 100 0 0 0 0 0 0 0x0
ctrStatus=1, ctrCount=7040, ctrIndex=7029, counts=1000 100 0 0 0 0 0 0 0x1
ctrStatus=1, ctrCount=7424, ctrIndex=7407, counts=1000 100 0 0 0 0 0 0 0x0
ctrStatus=1, ctrCount=7936, ctrIndex=7920, counts=1000 100 0 0 0 0 0 0 0x1
ctrStatus=1, ctrCount=8448, ctrIndex=8433, counts=1000 100 0 0 0 0 0 0 0x0
ctrStatus=1, ctrCount=8832, ctrIndex=8820, counts=1000 100 0 0 0 0 0 0 0x1
ctrStatus=0, ctrCount=9000, ctrIndex=8991, counts=1000 100 0 0 0 0 0 0 0x0

This is the output on Windows when the scan rate is increase to 2000 Hz. The program is run twice, and both times the output is as expected. Counter 0 is 500, Counter 1 is 50, and DIO0 toggles between 0 and 1.

J:\epics\devel\measComp>bin\windows-x64-static\test_USB_CTR.exe 1E538A2 2000 .05
Found 6 DAQ device(s)
Running on Windows
Connecting to device type=USB-CTR08 serial number=1E538A2
ctrStatus=1, ctrCount=768, ctrIndex=756, counts=500 50 0 0 0 0 0 0 0x0
ctrStatus=1, ctrCount=1792, ctrIndex=1782, counts=500 50 0 0 0 0 0 0 0x1
ctrStatus=1, ctrCount=2560, ctrIndex=2547, counts=500 50 0 0 0 0 0 0 0x0
ctrStatus=1, ctrCount=3584, ctrIndex=3573, counts=500 50 0 0 0 0 0 0 0x1
ctrStatus=1, ctrCount=4608, ctrIndex=4599, counts=500 50 0 0 0 0 0 0 0x0
ctrStatus=1, ctrCount=5376, ctrIndex=5364, counts=500 50 0 0 0 0 0 0 0x1
ctrStatus=1, ctrCount=6400, ctrIndex=6390, counts=500 50 0 0 0 0 0 0 0x0
ctrStatus=1, ctrCount=7424, ctrIndex=7407, counts=500 50 0 0 0 0 0 0 0x1
ctrStatus=1, ctrCount=8192, ctrIndex=8181, counts=500 50 0 0 0 0 0 0 0x0
ctrStatus=0, ctrCount=9000, ctrIndex=8991, counts=500 50 0 0 0 0 0 0 0x1

J:\epics\devel\measComp>bin\windows-x64-static\test_USB_CTR.exe 1E538A2 2000 .05
Found 6 DAQ device(s)
Running on Windows
Connecting to device type=USB-CTR08 serial number=1E538A2
ctrStatus=1, ctrCount=768, ctrIndex=756, counts=500 50 0 0 0 0 0 0 0x1
ctrStatus=1, ctrCount=1792, ctrIndex=1782, counts=500 50 0 0 0 0 0 0 0x0
ctrStatus=1, ctrCount=2560, ctrIndex=2547, counts=500 50 0 0 0 0 0 0 0x1
ctrStatus=1, ctrCount=3584, ctrIndex=3573, counts=500 50 0 0 0 0 0 0 0x0
ctrStatus=1, ctrCount=4608, ctrIndex=4599, counts=500 50 0 0 0 0 0 0 0x1
ctrStatus=1, ctrCount=5632, ctrIndex=5616, counts=500 50 0 0 0 0 0 0 0x0
ctrStatus=1, ctrCount=6400, ctrIndex=6390, counts=500 50 0 0 0 0 0 0 0x1
ctrStatus=1, ctrCount=7424, ctrIndex=7407, counts=500 50 0 0 0 0 0 0 0x0
ctrStatus=1, ctrCount=8448, ctrIndex=8433, counts=500 50 0 0 0 0 0 0 0x1
ctrStatus=0, ctrCount=9000, ctrIndex=8991, counts=500 50 0 0 0 0 0 0 0x0

This is the output when the program is run on Linux with rate=1000 Hz. It works fine, just like on Windows. I can run it many times and it always works.

> ../../bin/linux-x86_64-ub18/test_USB_CTR 01E538A2 1000 .05
Found 7 DAQ device(s)
Running on Linux
Connecting to device type=USB-CTR08 serial number=01E538A2
ctrStatus=1, ctrCount=459, ctrIndex=450, counts=1000 100 0 0 0 0 0 0 0x0
ctrStatus=1, ctrCount=909, ctrIndex=900, counts=1000 100 0 0 0 0 0 0 0x1
ctrStatus=1, ctrCount=1368, ctrIndex=1359, counts=1000 100 0 0 0 0 0 0 0x0
ctrStatus=1, ctrCount=1818, ctrIndex=1809, counts=1000 100 0 0 0 0 0 0 0x1
ctrStatus=1, ctrCount=2277, ctrIndex=2268, counts=1000 100 0 0 0 0 0 0 0x0
ctrStatus=1, ctrCount=2727, ctrIndex=2718, counts=1000 100 0 0 0 0 0 0 0x1
ctrStatus=1, ctrCount=3186, ctrIndex=3177, counts=1000 100 0 0 0 0 0 0 0x0
ctrStatus=1, ctrCount=3636, ctrIndex=3627, counts=1000 100 0 0 0 0 0 0 0x1
ctrStatus=1, ctrCount=4086, ctrIndex=4077, counts=1000 100 0 0 0 0 0 0 0x0
ctrStatus=1, ctrCount=4545, ctrIndex=4536, counts=1000 100 0 0 0 0 0 0 0x1
ctrStatus=1, ctrCount=4995, ctrIndex=4986, counts=1000 100 0 0 0 0 0 0 0x0
ctrStatus=1, ctrCount=5454, ctrIndex=5445, counts=1000 100 0 0 0 0 0 0 0x1
ctrStatus=1, ctrCount=5904, ctrIndex=5895, counts=1000 100 0 0 0 0 0 0 0x0
ctrStatus=1, ctrCount=6354, ctrIndex=6345, counts=1000 100 0 0 0 0 0 0 0x1
ctrStatus=1, ctrCount=6813, ctrIndex=6804, counts=1000 100 0 0 0 0 0 0 0x0
ctrStatus=1, ctrCount=7263, ctrIndex=7254, counts=1000 100 0 0 0 0 0 0 0x1
ctrStatus=1, ctrCount=7722, ctrIndex=7713, counts=1000 100 0 0 0 0 0 0 0x0
ctrStatus=1, ctrCount=8172, ctrIndex=8163, counts=1000 100 0 0 0 0 0 0 0x1
ctrStatus=1, ctrCount=8631, ctrIndex=8622, counts=1000 100 0 0 0 0 0 0 0x0
ctrStatus=0, ctrCount=9000, ctrIndex=8991, counts=1000 100 0 0 0 0 0 0 0x1

This is the output on Linux when the rate is increased to 2000 Hz. The first time the program is run with this rate it works fine, and the results are the same as Windows.

> ../../bin/linux-x86_64-ub18/test_USB_CTR 01E538A2 2000 .05
Found 7 DAQ device(s)
Running on Linux
Connecting to device type=USB-CTR08 serial number=01E538A2
ctrStatus=1, ctrCount=768, ctrIndex=756, counts=500 50 0 0 0 0 0 0 0x0
ctrStatus=1, ctrCount=1792, ctrIndex=1782, counts=500 50 0 0 0 0 0 0 0x1
ctrStatus=1, ctrCount=2560, ctrIndex=2547, counts=500 50 0 0 0 0 0 0 0x0
ctrStatus=1, ctrCount=3584, ctrIndex=3573, counts=500 50 0 0 0 0 0 0 0x1
ctrStatus=1, ctrCount=4352, ctrIndex=4338, counts=500 50 0 0 0 0 0 0 0x0
ctrStatus=1, ctrCount=5376, ctrIndex=5364, counts=500 50 0 0 0 0 0 0 0x1
ctrStatus=1, ctrCount=6144, ctrIndex=6129, counts=500 50 0 0 0 0 0 0 0x0
ctrStatus=1, ctrCount=7168, ctrIndex=7155, counts=500 50 0 0 0 0 0 0 0x1
ctrStatus=1, ctrCount=7936, ctrIndex=7920, counts=500 50 0 0 0 0 0 0 0x0
ctrStatus=0, ctrCount=9000, ctrIndex=8991, counts=500 50 0 0 0 0 0 0 0x1

However, if the program is run again then the results are incorrect. The data are not in the correct position in the array, and the scan never stops, because ctrStatus never goes to 0 and crtCount never reaches 9000. It only reaches 8872.

TahoeU18:/corvette/home/epics/devel/measComp/iocBoot/iocUSBCTR> ../../bin/linux-x86_64-ub18/test_USB_CTR 01E538A2 2000 .05
Found 7 DAQ device(s)
Running on Linux
Connecting to device type=USB-CTR08 serial number=01E538A2
ctrStatus=1, ctrCount=768, ctrIndex=756, counts=0 0 0 0 0 0 0 500 0x32
ctrStatus=1, ctrCount=1536, ctrIndex=1521, counts=0 0 0 0 0 0 1 500 0x32
ctrStatus=1, ctrCount=2560, ctrIndex=2547, counts=0 0 0 0 0 0 0 500 0x32
ctrStatus=1, ctrCount=3328, ctrIndex=3312, counts=0 0 0 0 0 0 1 500 0x32
ctrStatus=1, ctrCount=4352, ctrIndex=4338, counts=0 0 0 0 0 0 0 500 0x32
ctrStatus=1, ctrCount=5120, ctrIndex=5103, counts=0 0 0 0 0 0 1 500 0x32
ctrStatus=1, ctrCount=6144, ctrIndex=6129, counts=0 0 0 0 0 0 0 500 0x32
ctrStatus=1, ctrCount=6912, ctrIndex=6903, counts=0 0 0 0 0 0 1 500 0x32
ctrStatus=1, ctrCount=7936, ctrIndex=7920, counts=0 0 0 0 0 0 0 500 0x32
ctrStatus=1, ctrCount=8872, ctrIndex=8856, counts=0 0 0 0 0 0 1 500 0x32
ctrStatus=1, ctrCount=8872, ctrIndex=8856, counts=0 0 0 0 0 0 1 500 0x32
ctrStatus=1, ctrCount=8872, ctrIndex=8856, counts=0 0 0 0 0 0 1 500 0x32
ctrStatus=1, ctrCount=8872, ctrIndex=8856, counts=0 0 0 0 0 0 1 500 0x32
ctrStatus=1, ctrCount=8872, ctrIndex=8856, counts=0 0 0 0 0 0 1 500 0x32
ctrStatus=1, ctrCount=8872, ctrIndex=8856, counts=0 0 0 0 0 0 1 500 0x32
ctrStatus=1, ctrCount=8872, ctrIndex=8856, counts=0 0 0 0 0 0 1 500 0x32
ctrStatus=1, ctrCount=8872, ctrIndex=8856, counts=0 0 0 0 0 0 1 500 0x32
ctrStatus=1, ctrCount=8872, ctrIndex=8856, counts=0 0 0 0 0 0 1 500 0x32

If I go back to 1000 Hz it fails the first time, but then works the second time and on subsequent runs at 1000 Hz.

Is there something I am neglecting to do in Linux that is causing this problem, or is there a problem with UL for Linux?

Problem with ulDIOGetInfo on USB-2408-2A0

I am trying to query the information about the digital I/O port with UL Linux. It seems to work on some devices (E-TC, E-1608, USB-CTR). However, on a USB-2408 I am having problems.

It works fine using UL for Windows. This is the relevant section of code in my initialization function:

  cbGetConfig(BOARDINFO, boardNum_, 0, BIDINUMDEVS,     &numIOPorts_);
  cbGetConfig(BOARDINFO, boardNum_, 0, BINUMTEMPCHANS,  &numTempChans_);
printf("MultiFunction::MultiFunction numIOPorts=%d\n", numIOPorts_);
  if (numIOPorts_ > MAX_IO_PORTS) numIOPorts_ = MAX_IO_PORTS;
  for (i=0; i<numIOPorts_; i++) {
    cbGetConfig(DIGITALINFO, boardNum_, i, DIDEVTYPE, &digitalIOPort_[i]);
    cbGetConfig(DIGITALINFO, boardNum_, i, DIINMASK,  &inMask);
    cbGetConfig(DIGITALINFO, boardNum_, i, DIOUTMASK, &outMask);
    cbGetConfig(DIGITALINFO, boardNum_, i, DINUMBITS, &numIOBits_[i]);
    digitalIOPortConfigurable_[i] = 0;
    digitalIOBitConfigurable_[i] = ((inMask & outMask) == 0);
printf("MultiFunction::MultiFunction port %d, port type=%d, inMask=0x%x, outMask=0x%x\n", i, digitalIOPort_[i], inMask, outMask);

This is the output when I run the program:

MultiFunction::MultiFunction numIOPorts=1
MultiFunction::MultiFunction port 0, port type=10, inMask=0xff, outMask=0xff

So it is correctly reporting that there is only 1 digital I/O device, it is type 10 (FIRSTPORTA), and that DIINMASK and DIOUTMASK are both 0xff.

This is my code for UL for Linux:

    biDInNumDevs_ = 0;
    error = ulDIOGetInfo(daqDeviceHandle_, DIO_INFO_NUM_PORTS, 0, &infoValue);
printf("mcBoard::mcBoard ulDIOGetInfo error=%d DIO_INFO_NUM_PORTS = %lld\n", error, infoValue);
    if (error == ERR_NO_ERROR) biDInNumDevs_ = infoValue;

    diDevType_ = 0;
    error = ulDIOGetInfo(daqDeviceHandle_, DIO_INFO_PORT_TYPE, 0, &infoValue);
printf("mcBoard::mcBoard ulDIOGetInfo error=%d DIO_INFO_PORT_TYPE = %lld\n", error, infoValue);
    if (error == ERR_NO_ERROR) diDevType_ = infoValue;

    diNumBits_ = 0;
    error = ulDIOGetInfo(daqDeviceHandle_, DIO_INFO_NUM_BITS, 0, &infoValue);
printf("mcBoard::mcBoard ulDIOGetInfo error=%d DIO_INFO_NUM_BITS = %lld\n", error, infoValue);
    if (error == ERR_NO_ERROR) diNumBits_ = infoValue;
    
    diInMask_ = 0;
    diOutMask_ = 0;
    error = ulDIOGetConfig(daqDeviceHandle_, DIO_CFG_PORT_DIRECTION_MASK, 0, &infoValue);
printf("mcBoard::mcBoard ulDIOGetConfig error=%d DIO_CFG_PORT_DIRECTION_MASK=0x%llx\n", error, infoValue);

This is the output when I run the program:

mcBoard::mcBoard ulDIOGetInfo error=0 DIO_INFO_NUM_PORTS = 3
mcBoard::mcBoard ulDIOGetInfo error=0 DIO_INFO_PORT_TYPE = 1
mcBoard::mcBoard ulDIOGetInfo error=0 DIO_INFO_NUM_BITS = 8
mcBoard::mcBoard ulDIOGetConfig error=24 DIO_CFG_PORT_DIRECTION_MASK=0x8

It seems to have a number of problems:

• It is reporting that there are 3 ports, not just 1
• If is reporting that the port type of the first port is 1 (AUXPORT), not 10 (FIRSTPORTA).
• When I try to read the DIO_CFG_PORT_DIRECTION_MASK I get error 24. I don't know why.

More generally, on Windows I use the DINMASK and DOUTMASK to determine if the I/O port has configurable bits. How does one determine that on UL for Linux?

Temperature measurement on USB-2408-2A0 effected by thermocouple grounding

On the E-TC and other temperature measurement devices I can ground the thermocouple tip and it does not affect the temperature reading.

However, on the USB-2408-2A0 if I ground the thermocouple tip it changes the reading dramatically. I see this both on Windows and Linux. On Windows cbTIn reports OPENCONNECTION.

This seems very wrong, the thermocouple reading should be floating, and independent of whether the thermocouple is grounded.

I realize this is not an issue with UL for Linux, but I am hoping someone can suggest what the problem is. Is there a way I could be connecting things wrong to the USB-2408-2A0 to cause this? Or is this a design issue with the device?

problem detecting USB-1208FS

Hi,

I just began using your code and uldaq is not detecting the USB-1208FS daq (which I see is supported) that is plugged into my computer. I can't seem to find the source of the problem.

My computer is a 2014 Macbook Pro running Mojave. (I was running high Sierra but I updated because I thought that might be the issue)

I believe that I installed uldaq correctly as I followed all of the steps on your installation guide and did not see any errors. I reinstalled to confirm.
I can confirm that my computer recognizes the device.
I also used this daq last week so I don't think that's the issue either.

When I run AIn, I get an error saying: "No DAQ device detected".

Sorry for the trouble, your code is very well documented and readable but I don't know what to do to get it working on my machine. I'd appreciate any ideas you might have for how to fix this.

Thanks!

Unclear wording in documentation

Problem

In the Python documentation the rate argument of AoDevice.a_out_scan is described as "rate (float) – Sample output rate in scans per second."

I found this confusing. I assumed it would describe how often the whole buffer is played back per second.

Proposed solution

I propose changing the description to: "Output scan rate in samples per second. For valid range see AoInfo.get_min_scan_rate and AoInfo.get_max_scan_rate. "

Also change return description to "Returns: The actual output scan rate in samples per second."

Advantages

This brings the units in line with the descriptions for AoInfo.get_min_scan_rate and AoInfo.get_max_scan_rate.

By googling I was not able to find a single reference to the unit "scans per second" in the context of outputting signals - only reading ("scanning") data.

That way it is also clear what values are valid - otherwise one is left wondering why the device will not output at a rate of 5 Hz, even if specified.

Other affected documents

The same issue appears in the C documentation.

Issue with hid_flush_input_pipe()

Dear Team,
I am using uldaq inside docker container.
When i stop and start the container i am seeing the following error

Did any of you face this issue?
After rebooting the host machine multiple times solves this issue. this issue even comes up when the device is physically unplugged too.
Is there a way we can solve this so that we don't need manual intervention to manually reboot machine multiple times?

Thanks.

Problems installing MCC uldaq on a Mac

I'm trying to install mccdaq/uldaq on an iMac (Intel) running Monterey (v 12.1).
I've followed the instructions at https://github.com/mccdaq/uldaq.
When I get to './configure && make' I get the following errors:

Making all in src
CXXLD libuldaq.la
/Library/Developer/CommandLineTools/usr/bin/ranlib: file: .libs/libuldaq.a(hid_linux.o) has no symbols
/Library/Developer/CommandLineTools/usr/bin/ranlib: file: .libs/libuldaq.a(UlCtrConfig.o) has no symbols
ranlib: object: .libs/libuldaq.a(CtrInfo.o) malformed object (unknown load command 1)
make[2]: *** [libuldaq.la] Error 1
make[1]: *** [all-recursive] Error 1
make: *** [all] Error 2

Ive been unable to resolve this by internet searches. Would be very grateful if anyone is able to help.
Many thanks. Alex.

CounterMeasurementType Issue

When measuring with a USB-1808 DAQ using a CMT_PERIOD, the daq is not measuring the number of tick between two active edges of the counter, but between one active edge of the counter and one of the gate.
When using CMT_PULSE_WIDTH, it does what is expected of CMT_PERIOD.

When using CMT_PERIOD, and any non default CounterMeasurementMode option, the function ulCConfigScan() returns an error.

TC-32 and TC-32 exp

Is there any other way that we can identify automatically to detect a single TC-32 or a TC-32 with the expansion board?

The code has the hard-coded numbers (32 and 64) inconsistently in some places. In our requirement, we only use 32 channels per model.

uldaq/src/net/ETc32.cpp

Line 21 in 1d84041

addMemRegion(MR_SETTINGS, 0, 32, MA_READ | MA_WRITE);

uldaq/src/net/ai/AiETc32.h

Line 60 in 1d84041

enum { MAX_UNIT_CHAN_COUNT = 32 };

uldaq/src/net/ai/AiETc32.cpp

Line 17 in 1d84041

mAiInfo.setNumChansByMode(AI_DIFFERENTIAL, 64); // including exp channels

uldaq/src/net/ai/AiETc32.cpp

Line 23 in 1d84041

mAiInfo.setChanTypes(0, 63, AI_TC);

Include AUR package in the description

I created an AUR package for this repository so that it is easy to install the library on Arch. This could be included in the install instructions.

configure is missing from git archive

Configure is in the tar.bz files that can be pulled from github but configure is not in the main branch of the git repository. So cloning the repository to get the source code produces a directory tree that cannot be build with ./configure && make && make install
problem.txt

USB-1208LS is not defined in the udev rules.

Any plans to support this device?

Question: generating pulses on multiple timers simulataneously

Hello,

I am using the Python library to interface with a USB-CTR04 board. The board has 4x timers and I would like to ouput a PWM signal on all of these simultaneously.

I tried to use pulse_out_start in a for loop, but it seems from a scope capture that it's not fast enough; there is a delay of about 5ms between the starting times of the different timers (see image below).

Any suggestions for how to go about this? Thanks!

Invalid linker flag in pkg-config file

uldaq/libuldaq.pc.in

Line 9 in 0b72c31

Libs: -L${libdir} -libuldaq

It should be -luldaq not -libuldaq

Set IEPE settings in EEPROM

The documentation says:

In Windows, you can use the Open Layers Control panel to configure the IEPE settings that are used at power up.
Note:The values that are set using ulAISetConfig and ulAISetConfigDbl are not retained in EEPROM; therefore, they are not used a power up. It is recommended that your program initialize these values when your program runs.

Apparently it is possible to set the settings via windows it would be nice if we could also do it via the ulday Linux library

missing configure file

The configure file is missing from the current release so ./configure does not work.

how to view the values ?

hi, i am python beginner.

I'm doing a project with the USB 204 board on my raspberry pi 3.

I made this python script:

import uldaq

interface_type = uldaq.InterfaceType.USB

devices = uldaq.get_daq_device_inventory(interface_type)

daq_device = uldaq.DaqDevice(devices[0])

ai_device = daq_device.get_ai_device()

descriptor = daq_device.get_descriptor()

daq_device.connect(connection_code=0)

print(' ---> ', descriptor.dev_string, ' Connected!! <---')

Starting_channel = 0
End_channel = 0
input_mode = uldaq.AiInputMode(2) # SINGLE_ENDED = 2
Range = uldaq.Range(5) # BIP10VOLTS = 5  -10 to +10 VOLTS
Flags = uldaq.AInFlag(0)
Samples= 3000
rate = 500000
scan_options = uldaq.ScanOption(1) 

data = uldaq.create_float_buffer(Starting_channel, Samples)

L = []

Value= ai_device.a_in_scan(Starting_channel, End_channel , input_mode, Range, Samples, rate, scan_options, Flags, data)

ai_device.scan_stop()
daq_device.disconnect()

L.append(str(data))


with open('Sinal.txt','w') as S:
    S.write(str(L))
S.close()

print(L)

I want to capture a signal like an oscilloscope, but I can't see the signal.
This is the script response:

 --->  USB-204  Connected!! <---
['<uldaq.buffer_management.c_double_Array_0 object at 0x75978800>']

OSError: libuldaq.so : cannot open shared object file: No such file or directory

I followed the extended installation procedure to include python uldaq library, and stumbled on this error while trying to launch a .py file (from provided examples).

File "usr/lib/python2.7/ctypes/init.py", line 366, in init
self._handle = _dlopen(self._name,mode)
OSError: libuldaq.so : cannot open shared object file: No such file or directory

configure unable to find libusb on M1 MacBook running MacOS 12

Different results on different computers

I have installed uldaq==1.2.2 in a python virtual environment. I ran the following script on two computers:

"""
Repetitive data logger for home monitoring system.

Now using 18-bit DAQ, so just storing data as float 32.

"""

import numpy as np

from uldaq import (get_daq_device_inventory, DaqDevice, InterfaceType,
                   AiInputMode, Range, AInFlag, AInScanFlag,
                   create_float_buffer,
                   ScanOption)

# Get a list of available DAQ devices
devices = get_daq_device_inventory(InterfaceType.USB)
# Create a DaqDevice Object and connect to the device
daq_device = DaqDevice(devices[0])
daq_device.connect()
# Get AiDevice and AiInfo objects for the analog input subsystem
ai_device = daq_device.get_ai_device()
ai_info = ai_device.get_info()

# Sample acquisition rate in Hz
rate = 200000

# Number samples per channel.
samples_per_channel = int(3/60*rate)

# Number of channels, must agree with specification of low_channel and
# high_channel below
num_channels = 1
low_channel = 0
high_channel = 0

print('Waiting to acquire.')

buffer = create_float_buffer(num_channels, samples_per_channel)


actual_scan_rate = ai_device.a_in_scan(
    low_channel=low_channel,
    high_channel=high_channel,
    input_mode=AiInputMode.DIFFERENTIAL,
    analog_range=Range.BIP5VOLTS,
    samples_per_channel=samples_per_channel,
    rate=rate,
    options=ScanOption.DEFAULTIO,
    flags=AInScanFlag.DEFAULT,
    data=buffer)

# Sleep until the scan is over.
print('Acquiring Scan Rate: {}'.format(actual_scan_rate))
ai_device.scan_wait(1,-1)

# Get data
data = np.array(buffer[:]).reshape(
    (samples_per_channel, num_channels)).transpose()

print(data)

daq_device.disconnect()
daq_device.release()

# Plot data
import matplotlib
matplotlib.use('TKagg')
import matplotlib.pyplot as plt

plt.figure(0)
plt.clf()
cax = np.arange(samples_per_channel)
t = 1 / actual_scan_rate * np.arange(samples_per_channel)
plt.plot(t, data[0,:])
plt.show()
plt.savefig('macbookpro_scan.png')

When I use a Macbook Pro, I get this result (this is the line to line voltage in my house):

However, when I run the same script on a Raspberry Pi, using exactly the same DAQ setup, I get a very different result:

Any ideas why this would be, or how to fix?

The link for building is broken

I think that the link for downloading and building is broken.

Add the python uldaq library on GitHub

The uldaq python package on PyPi (https://pypi.org/project/uldaq/) links to this repository and the measurement computing website. However, the python library’s code isn’t found anywhere, except inside the archives that can be downloaded from PyPi. Could there be a way to have that code in this repository, or a separate new one, so it could be possible to submit fixes or issues regarding the python specific code?

Ultimately, it should be great that the C part of the library could be bundled/compiled at the python package's setup, but any help here starts by having the package's code visible ;)

Thanks!

Build fails on armv6/armv7

#16 267.1 AiDevice.cpp: In member function 'virtual void ul::AiDevice::getCfg_CalDateStr(int, char*, unsigned int*)':
#16 267.1 AiDevice.cpp:715:23: error: cannot convert 'long int*' to 'const time_t*' {aka 'const long long int*'}
#16 267.1   715 |  timeinfo = localtime(&calDateSec);
#16 267.1       |                       ^~~~~~~~~~~
#16 267.1       |                       |
#16 267.1       |                       long int*
#16 267.1 In file included from /usr/include/pthread.h:31,
#16 267.1                  from /usr/include/c++/10.2.1/armv7-alpine-linux-musleabihf/bits/gthr-default.h:35,
#16 267.1                  from /usr/include/c++/10.2.1/armv7-alpine-linux-musleabihf/bits/gthr.h:148,
#16 267.1                  from /usr/include/c++/10.2.1/ext/atomicity.h:35,
#16 267.1                  from /usr/include/c++/10.2.1/bits/ios_base.h:39,
#16 267.1                  from /usr/include/c++/10.2.1/ios:42,
#16 267.1                  from /usr/include/c++/10.2.1/ostream:38,
#16 267.1                  from /usr/include/c++/10.2.1/iostream:39,
#16 267.1                  from ul_internal.h:12,
#16 267.1                  from AiDevice.h:10,
#16 267.1                  from AiDevice.cpp:7:
#16 267.1 /usr/include/time.h:58:23: note:   initializing argument 1 of 'tm* localtime(const time_t*)'
#16 267.1    58 | struct tm *localtime (const time_t *);
#16 267.1       |                       ^~~~~~~~~~~~~~
#16 270.4   CXX      DioConfig.lo
#16 270.7   CXX      CtrConfig.lo
#16 271.2   CXX      IoDevice.lo

configure && make error

When running ./configure && make I see the following two errors:

    In file included from **UlDaqDeviceManager.cpp:11:0:
    ./usb/UsbDaqDevice.h:136:84: error: 'libusb_hotplug_event'** has not been declared
      static int hotplugCallback(struct libusb_context* ctx, struct libusb_device* dev, libusb_hotplug_event event, void *user_data);
                                                                                        ^
    **./usb/UsbDaqDevice.h:149:9: error: 'libusb_hotplug_callback_handle'** does not name a type
      static libusb_hotplug_callback_handle mHotplugHandle;

Has anyone else experienced the same thing or have any suggestions? I tried the latest and oldest versions and get the same error.

Problem of running uldaq python example

I have following problem running uldaq python example on my M1 MacOS system:

MacBook-Pro-M1:examples local$ ./a_in.py
Traceback (most recent call last):
File "./a_in.py", line 30, in
from uldaq import (get_daq_device_inventory, DaqDevice, InterfaceType,
File "/usr/local/lib/python2.7/site-packages/uldaq/init.py", line 1, in
from .daq_device_discovery import get_daq_device_inventory
File "/usr/local/lib/python2.7/site-packages/uldaq/daq_device_discovery.py", line 9, in
from .ul_exception import ULException
File "/usr/local/lib/python2.7/site-packages/uldaq/ul_exception.py", line 6, in
from .ul_c_interface import lib
File "/usr/local/lib/python2.7/site-packages/uldaq/ul_c_interface.py", line 15, in
lib = CDLL('libuldaq.dylib')
File "/usr/local/Cellar/python@2/2.7.15_1/Frameworks/Python.framework/Versions/2.7/lib/python2.7/ctypes/init.py", line 366, in init
self._handle = _dlopen(self._name, mode)
OSError: dlopen(libuldaq.dylib, 0x0006): tried: 'libuldaq.dylib' (no such file), '/usr/local/lib/libuldaq.dylib' (mach-o file, but is an incompatible architecture (have 'arm64', need 'x86_64')), '/usr/lib/libuldaq.dylib' (no such file), '/Users/local/Downloads/libuldaq-1.2.1/uldaq-1.2.3/examples/libuldaq.dylib' (no such file)

fpga bitfiles should not be installed in /etc

/etc is for systemwide configuration files controled by the end user,
not for read-only data like bitfiles.

I've posted a suggested fix, moving them to /usr/share/uldaq/fpga,
which should be compatible with MacOS, and is similar to where the sigrok project puts them.

#15

Device not found / supported.

I recently bought a USB-1616HS-2. At the time I was told their was linux support, but in looking at the source code it appears that this has yet to be developed. Is there anything currently being developed, or is there a pathway that I could help out with?

Device not found

Hi,

I'm trying to use the python API with a USB-TEMP device. It works with the windows version (device shows up and I can read temperatures via Python) but the list returned by get_daq_device_inventory is empty when trying the same thing using Ubuntu 16.04 LTS.

The devices shows up using dmesg.

Any hints on what I'm doing wrong would be appreciated.

Edit:
I was able to communicate with the USB-TEMP following this guilde: https://www.mccdaq.com/TechTips/TechTip-9.aspx (using a raspberry pi)

Following this guide:
https://www.mccdaq.com/TechTips/TechTip-10.aspx
still does not work ("No DAQ devices found") on the Raspberry or the desktop Linux PC I tried it on.

error: ‘libusb_hotplug_event’ has not been declared

Am trying to compile on an Olimex Micro-A20, running Debian 7 and am getting an error:

make  all-recursive
make[1]: Entering directory `/root/libuldaq-1.0.0'
Making all in src
make[2]: Entering directory `/root/libuldaq-1.0.0/src'
  CXX      CtrInfo.lo
  CXX      DioPortInfo.lo
  CXX      UlDaqDeviceManager.lo
In file included from UlDaqDeviceManager.cpp:11:0:
./usb/UsbDaqDevice.h:132:84: error: ‘libusb_hotplug_event’ has not been declared
./usb/UsbDaqDevice.h:145:9: error: ‘libusb_hotplug_callback_handle’ does not name a type
make[2]: *** [UlDaqDeviceManager.lo] Error 1
make[2]: Leaving directory `/root/libuldaq-1.0.0/src'
make[1]: *** [all-recursive] Error 1
make[1]: Leaving directory `/root/libuldaq-1.0.0'
make: *** [all] Error 2

I have libusb-1.0-0-dev installed:

root@host:~/libuldaq-1.0.0# sudo apt-get install libusb-1.0-0-dev
Reading package lists... Done
Building dependency tree       
Reading state information... Done
libusb-1.0-0-dev is already the newest version.
0 upgraded, 0 newly installed, 0 to remove and 121 not upgraded.

Problems reading temperature on USB-2408 at 20 Hz sampling rate

I am having trouble with ulTIn on the USB-2408-2A0 with sampling times less than 60 Hz on for Linux. It works fine with cbTIn on UL for Windows.

I have written a test program to demonstrate the problem.

https://github.com/epics-modules/measComp/blob/UL_for_Linux_Direct/measCompApp/src/test_TIn_1.cpp

These are the comments at the beginning of the program that explain how to run it, and the problem I observe.

    This program reads the first temperature input on a device at 10 Hz.
    It prints the data for each point, and the mean and standard deviation for all readings.
    The program requires 3 arguments
    - The UnigueID of the device (serial number for USB, MAC address for Ethernet).
    - The Open Thermocouple Detect mode (0=disabled, 1=enabled)
    - The sampling rate in Hz
    - The number of readings

    The program runs on both Windows and Linux.
    It demonstates a problem with UL for Linux.  It works fine with sampling rate=60 Hz.
    However, at other sampling rates it occasionally returns spurious readings. This does not happen on Windows.

This is the output when running on Windows with sampleRate=60 Hz, OTD disabled, 20 readings. It works fine, the standard deviation of the readings is 0.004 degrees.

J:\epics\devel\measComp>bin\windows-x64-static\test_TIn_1.exe 1AAA83C 0 60 20
uniqueID=1AAA83C, ODTMode=Disabled, sampleRate=60, numPoints=20
Found 6 DAQ device(s)
Running on Windows
Connecting to device type=USB-2408-2AO serial number=1AAA83C
Reading: 0, T: 21.411213
Reading: 1, T: 21.406815
Reading: 2, T: 21.405659
Reading: 3, T: 21.413988
Reading: 4, T: 21.412600
Reading: 5, T: 21.411213
Reading: 6, T: 21.415146
Reading: 7, T: 21.409592
Reading: 8, T: 21.411674
Reading: 9, T: 21.407742
Reading: 10, T: 21.402418
Reading: 11, T: 21.407278
Reading: 12, T: 21.414221
Reading: 13, T: 21.407742
Reading: 14, T: 21.404734
Reading: 15, T: 21.411674
Reading: 16, T: 21.412832
Reading: 17, T: 21.410519
Reading: 18, T: 21.412832
Reading: 19, T: 21.415840
Mean=21.410287
Standard deviation=0.003580

This is the output when running on Windows with sampleRate=20Hz, OTD disabled, 20 readings. It works fine, the standard deviation of the readings is still 0.004 degrees.

J:\epics\devel\measComp>bin\windows-x64-static\test_TIn_1.exe 1AAA83C 0 20 20
uniqueID=1AAA83C, ODTMode=Disabled, sampleRate=20, numPoints=20
Found 6 DAQ device(s)
Running on Windows
Connecting to device type=USB-2408-2AO serial number=1AAA83C
Reading: 0, T: 21.398022
Reading: 1, T: 21.394089
Reading: 2, T: 21.397327
Reading: 3, T: 21.392469
Reading: 4, T: 21.393625
Reading: 5, T: 21.393394
Reading: 6, T: 21.397327
Reading: 7, T: 21.396402
Reading: 8, T: 21.392237
Reading: 9, T: 21.399643
Reading: 10, T: 21.401957
Reading: 11, T: 21.394089
Reading: 12, T: 21.401493
Reading: 13, T: 21.386452
Reading: 14, T: 21.390617
Reading: 15, T: 21.389460
Reading: 16, T: 21.389229
Reading: 17, T: 21.392931
Reading: 18, T: 21.393625
Reading: 19, T: 21.394089
Mean=21.394424
Standard deviation=0.003942

This is the output when running on Linux with sampleRate=60 Hz, OTD disabled, 20 readings. It works fine, the standard deviation of the readings is 0.006 degrees.

src> ../../bin/linux-x86_64-ub18/test_TIn_1 01AAA83C 0 60 20
uniqueID=01AAA83C, ODTMode=Disabled, sampleRate=60, numPoints=20
Found 7 DAQ device(s)
Running on Linux
Connecting to device type=USB-2408-2AO serial number=01AAA83C
Reading: 0, T: 21.717942
Reading: 1, T: 21.694114
Reading: 2, T: 21.693883
Reading: 3, T: 21.699435
Reading: 4, T: 21.696196
Reading: 5, T: 21.702211
Reading: 6, T: 21.703831
Reading: 7, T: 21.700129
Reading: 8, T: 21.697816
Reading: 9, T: 21.703831
Reading: 10, T: 21.690413
Reading: 11, T: 21.698047
Reading: 12, T: 21.691570
Reading: 13, T: 21.691570
Reading: 14, T: 21.701748
Reading: 15, T: 21.698047
Reading: 16, T: 21.694114
Reading: 17, T: 21.705219
Reading: 18, T: 21.698741
Reading: 19, T: 21.701517
Mean=21.699019
Standard deviation=0.006079

This is the output when running on Linux with sampleRate=20 Hz, OTD disabled, 20 readings. It does not work correctly. Most of the readings are OK, but 2 of the readings are -7.1 degrees, rather than 21 degrees.

src> ../../bin/linux-x86_64-ub18/test_TIn_1 01AAA83C 0 20 20
uniqueID=01AAA83C, ODTMode=Disabled, sampleRate=20, numPoints=20
Found 7 DAQ device(s)
Running on Linux
Connecting to device type=USB-2408-2AO serial number=01AAA83C
Reading: 0, T: 21.666584
Reading: 1, T: 21.667510
Reading: 2, T: 21.667741
Reading: 3, T: 21.662189
Reading: 4, T: -7.110869
Reading: 5, T: 21.667741
Reading: 6, T: 22.033967
Reading: 7, T: 21.662883
Reading: 8, T: -7.118032
Reading: 9, T: 21.664965
Reading: 10, T: 22.043911
Reading: 11, T: 21.667047
Reading: 12, T: 22.045530
Reading: 13, T: 21.666584
Reading: 14, T: 21.665890
Reading: 15, T: 22.040211
Reading: 16, T: 21.661726
Reading: 17, T: 21.663346
Reading: 18, T: 21.658719
Reading: 19, T: 22.038129
Mean=18.880789
Standard deviation=8.666549

There are some applications where I need to average for more than 1/60 second. This works on Windows but fails on Linux.

C compiler does not work on macOS

I'm trying to install uldaq on my MacBook Pro (running macOS Catalina, version 10.15.7).

It says that my C compiler does not work when I try to run ./configure && make inside the libuldaq-1.2.0 directory:

checking for a BSD-compatible install... /usr/local/bin/ginstall -c
checking whether build environment is sane... yes
checking for a thread-safe mkdir -p... /usr/local/bin/gmkdir -p
checking for gawk... gawk
checking whether make sets $(MAKE)... yes
checking whether make supports nested variables... yes
checking for style of include used by make... GNU
checking for gcc... x86_64-apple-darwin13.4.0-clang
checking whether the C compiler works... no
configure: error: in `/Users/jgarrett/Projects/libuldaq-1.2.0':
configure: error: C compiler cannot create executables
See `config.log' for more details

I do also have gcc installed with Homebrew. Is it possible to tell configure to use this gcc installation instead of Apple's clang?

ulFlashLed reports "no connection established" error

Hi there, I'm currently developing for the 1608FS-Plus, but I've come across some rather strange errors when using the uldaq library. In the past I've used wjasper's mcc drivers with the daq just to test it, and I managed to get the LED to flash on command. I'm trying to use the uldaq function ulFlashLed now, but the error ERR_NO_CONNECTION_ESTABLISHED is repeatedly returned. This is despite all the analog input functions returning input data properly. The error is returned regardless of whether I've got the daq connected directly to my raspberry pi or to the pi through a powered usb hub.

Open source repo for python API and packaging code

I see that a a while ago there was a request for open sourcing the python packaging for the uldaq python package. #13

Sure is a shame that this suggestion has not seen any follow through.

Here is an example of how this could be beneficial for both MCC and the community of uldaq users:

Right now the python library depends on the c library. But, the python packages do not include built c libraries in the wheel files. Python wheels have the ability to include c libraries compiled against older versions of glibc, producing a wheel file that does not require the end user to download, compile, and install the dependent c libraries. This simplifies installation for people who are ok with using the compiled libraries.

Motivated members of the community might be willing to contribute the knowledge and expertise to produce these manylinux wheels back to MCC if they had a github repo to facilitate the contribution. This would allow mcc and the community to benefit from this streamlined installation process. Win-win.

.

ulTIn does not return ERR_OPEN_CONNECTION for disconnected thermocouple channels on the USB-2408-2A0

On the USB-2408-2A0 on Windows cbTIn returns error=OPENCONNECTION for all channels that do not have thermocouples connected. On the USB-2408-2A0 Linux ulTIn is not returning ERR_OPEN_CONNECTION for such channels. ulTIn does correctly return ERR_OPEN_CONNECTION on the E-TC module, for example.

Test conditions for USB-2408-2A0:

• All 8 channels configured for thermocouple input and type K thermocouple.
• First 4 channels being read at 10 Hz.
• Type K thermocouples connected to channels 0 and 1, no connection to channels 2 and 3.

This is the piece of test code on Windows.

      status = cbTIn(boardNum_, addr, scale, &fVal, filter);
printf("cbTIn status=%d, addr=%d, scale=%d, fVal=%f, filter=%d\n", status, addr, scale, fVal, filter);

This is the output for a single cycle of reading all 3 channels:

cbTIn status=0, addr=0, scale=0, fVal=22.665619, filter=0
cbTIn status=0, addr=1, scale=0, fVal=22.171738, filter=0
cbTIn status=145, addr=2, scale=0, fVal=-9999.000000, filter=0
cbTIn status=145, addr=3, scale=0, fVal=-9999.000000, filter=0

Note that channels 2 and 3 both return status=145, which is OPENCONNECTION in cbw.h. This is the correct behavior.

This is the piece of test code on Linux:

    UlError error = ulTIn(daqDeviceHandle_, Chan, tempScale, flags, &data);
printf("ulTIn error=%d, Chan=%d, tempScale=%d, flags=%d, data=%f\n", error, Chan, tempScale, flags, data);

This is the output for a single cycle of reading all 3 channels:

ulTIn error=0, Chan=0, tempScale=1, flags=0, data=20.400458
ulTIn error=0, Chan=1, tempScale=1, flags=0, data=21.341698
ulTIn error=0, Chan=2, tempScale=1, flags=0, data=1914.551081
ulTIn error=0, Chan=3, tempScale=1, flags=0, data=-9999.000000

Note that error=0 on channels 2 and 3, while it should be ERR_OPEN_CONNECTION. The data is -9999 on channel 3, but it is some other large value on channel 2. This can cause confusion, cbTIn should be correctly reporting the open connection status. The hardware appears capable of this, since it works on Windows.

OSError: dlopen(libuldaq.dylib, 6): image not found

Hi,
I have problems to import uldaq.
My operating system is. macOs Big sur(intel) with python 2.7 (I cannot use python 3)

I tried to install it with pip install uldaq. But, it seams to not work properly when importing.

An example when I'm trying to import it with ipython:

USB-1608GX drops occasionally drops first sample when run at high frequencies in continuous mode.

When sampling multiple channels in continuous mode at more than 1kHz, I found that the data is frequently (but not always) offset by one channel. For example, if conducting a scan using

ul.a_in_scan(0, 3, AiInputMode.DIFFERENTIAL, Range.BIP10VOLTS, 2000, ScanOption.DEFAULTIO | ScanOption.CONTINUOUS, AInScanFlag.DEFAULT, data)

data[0] corresponds to channel 1 and data[3] corresponds to channel 0 most (~60%) of the time. Most of the time, data[0] corresponds to channel 0, and occasionally data[0] corresponds to channel 2.

Coverity badge in README is broken

usb-200 two channel synchronous sampling

Updates: It seems like it is impossible to use usb200 for synchronous sampling. However when I checked the synchronous DAQ USB-1608FS-Plus, I still did not find any configs related to synchronous sampling using python. Any info on that will be really appreciated!

Howdy! Is it possible to do two channel synchronous sampling using usb-200? Didn't find any relevant document yet. Thanks!!

libusb problem on M1 Mac

I cannot build the library on an M1 Mac- ./configure gives an error:

checking operating system... arm-apple-darwin21.4.0
 Mac OS X
checking for libusb_init in -lusb-1.0... no

  Library libusb-1.0 was not found on this system.
  Please install it and re-run ./configure

even though I have installed libusb using homebrew and it claims that it is a universal build.

config.log says:
configure:16180: checking for libusb_init in -lusb-1.0 configure:16205: gcc -o conftest -O3 conftest.c -libusb-1.0 -framework IOKit -framework CoreFoundation >&5 ld: library not found for -libusb-1.0 clang: error: linker command failed with exit code 1 (use -v to see invocation) configure:16205: $? = 1 configure: failed program was: | /* confdefs.h */

The build on my x86 iMac seemed to work fine.

No way to set SYNC pin mode to SLAVE/MASTER without AODevice

The only way to set the sync mode is via the AODevice, AOConfig. If you are using a device without an AO subsystem (Like the USB1608FS-PLUS), you CAN NOT set the sync pin even though the hardware supports it. This is a major logic bug. There needs to be a way to set the sync mode without needing an instance of the AODevice.

Channels in `a_in_load_queue()` must be in ascending order?

Is there a way to pass an arbitrary list of AiQueueElement to a_in_load_queue() where the channels are not necessarily in order?

Consider the following code. Tested with uldaq==1.2.2 and USB-201

from uldaq import (get_daq_device_inventory, DaqDevice, AInScanFlag,
                   AiInputMode, AiQueueElement, create_float_buffer,
                   ScanOption, InterfaceType, Range)

chan_list = [0, 1]
bufferSz = 5000
rate = 100
scan_options = ScanOption.DEFAULTIO | ScanOption.CONTINUOUS
flags = AInScanFlag.DEFAULT

devices = get_daq_device_inventory(InterfaceType.ANY)
daq_device = DaqDevice(devices[0])
ai_device = daq_device.get_ai_device()
daq_device.connect(connection_code=0)
ai_info = ai_device.get_info()
queue_list = []
for chan in chan_list:
    queue_element = AiQueueElement()
    queue_element.channel = chan
    queue_element.input_mode = AiInputMode.SINGLE_ENDED
    queue_element.range = Range.BIP10VOLTS
    queue_list.append(queue_element)

ai_device.a_in_load_queue(queue_list)
data = create_float_buffer(len(chan_list), bufferSz)
rate = ai_device.a_in_scan(0, 0, AiInputMode.SINGLE_ENDED, Range.UNI10VOLTS,
                           bufferSz,
                           rate, scan_options, flags, data)
status, transfer_status = ai_device.get_scan_status()

This code works fine,
but inverting the order of the channels
chan_list = [1, 0]
raises an Exception:

Traceback (most recent call last):
 File "(...)", line 26, in <module>
  ai_device.a_in_load_queue(queue_list)
 File "(...)/lib/python3.9/site-packages/uldaq/ai_device.py", line 150, in a_in_load_queue
   raise ULException(err)
uldaq.ul_exception.ULException: ULError.BAD_AI_CHAN_QUEUE: Invalid channel queue specified

Temperature measurement with USB-2408-2A0 is much noisier on Linux than Windows

I am observing much greater noise with ulTIn on Linux than with cbTIn on Windows on the same USB-2408-2A0. I suspect I have not configured something correctly on Linux, but I cannot figure out what that might be,

Test conditions for USB-2408-2A0:

• All 8 channels configured for thermocouple input and type K thermocouple.
• First channel only being read at 10 Hz.

This is a few seconds of the debug output on Windows:

cbTIn status=0, addr=0, scale=0, fVal=22.569202, filter=0
cbTIn status=0, addr=0, scale=0, fVal=22.576599, filter=0
cbTIn status=0, addr=0, scale=0, fVal=22.570589, filter=0
cbTIn status=0, addr=0, scale=0, fVal=22.566660, filter=0
cbTIn status=0, addr=0, scale=0, fVal=22.564810, filter=0
cbTIn status=0, addr=0, scale=0, fVal=22.568970, filter=0
cbTIn status=0, addr=0, scale=0, fVal=22.569202, filter=0
cbTIn status=0, addr=0, scale=0, fVal=22.574749, filter=0
cbTIn status=0, addr=0, scale=0, fVal=22.574057, filter=0
cbTIn status=0, addr=0, scale=0, fVal=22.571051, filter=0
cbTIn status=0, addr=0, scale=0, fVal=22.574518, filter=0
cbTIn status=0, addr=0, scale=0, fVal=22.568970, filter=0
cbTIn status=0, addr=0, scale=0, fVal=22.571976, filter=0
cbTIn status=0, addr=0, scale=0, fVal=22.573826, filter=0
cbTIn status=0, addr=0, scale=0, fVal=22.581223, filter=0
cbTIn status=0, addr=0, scale=0, fVal=22.566427, filter=0
cbTIn status=0, addr=0, scale=0, fVal=22.563654, filter=0
cbTIn status=0, addr=0, scale=0, fVal=22.573826, filter=0
cbTIn status=0, addr=0, scale=0, fVal=22.571976, filter=0
cbTIn status=0, addr=0, scale=0, fVal=22.570589, filter=0
cbTIn status=0, addr=0, scale=0, fVal=22.577291, filter=0
cbTIn status=0, addr=0, scale=0, fVal=22.567583, filter=0
cbTIn status=0, addr=0, scale=0, fVal=22.567583, filter=0
cbTIn status=0, addr=0, scale=0, fVal=22.565041, filter=0
cbTIn status=0, addr=0, scale=0, fVal=22.562037, filter=0
cbTIn status=0, addr=0, scale=0, fVal=22.566891, filter=0
cbTIn status=0, addr=0, scale=0, fVal=22.566891, filter=0

This is a plot of the temperature as a function of time for 30 seconds.

This is a few seconds of the debug output on Linux:

ulTIn error=0, Chan=0, tempScale=1, flags=0, data=24.546744
ulTIn error=0, Chan=0, tempScale=1, flags=0, data=24.773778
ulTIn error=0, Chan=0, tempScale=1, flags=0, data=25.378970
ulTIn error=0, Chan=0, tempScale=1, flags=0, data=24.855443
ulTIn error=0, Chan=0, tempScale=1, flags=0, data=24.203566
ulTIn error=0, Chan=0, tempScale=1, flags=0, data=24.312508
ulTIn error=0, Chan=0, tempScale=1, flags=0, data=24.378284
ulTIn error=0, Chan=0, tempScale=1, flags=0, data=25.130615
ulTIn error=0, Chan=0, tempScale=1, flags=0, data=24.437825
ulTIn error=0, Chan=0, tempScale=1, flags=0, data=23.575551
ulTIn error=0, Chan=0, tempScale=1, flags=0, data=24.365822
ulTIn error=0, Chan=0, tempScale=1, flags=0, data=24.017508
ulTIn error=0, Chan=0, tempScale=1, flags=0, data=24.164556
ulTIn error=0, Chan=0, tempScale=1, flags=0, data=23.748060
ulTIn error=0, Chan=0, tempScale=1, flags=0, data=24.428825
ulTIn error=0, Chan=0, tempScale=1, flags=0, data=24.152091
ulTIn error=0, Chan=0, tempScale=1, flags=0, data=23.941090
ulTIn error=0, Chan=0, tempScale=1, flags=0, data=23.825184
ulTIn error=0, Chan=0, tempScale=1, flags=0, data=23.756373
ulTIn error=0, Chan=0, tempScale=1, flags=0, data=23.513192
ulTIn error=0, Chan=0, tempScale=1, flags=0, data=23.657536
ulTIn error=0, Chan=0, tempScale=1, flags=0, data=24.079146

This is a plot of the temperature as a function of time for 30 seconds. The vertical scale is the same as the Windows plot above.

The Linux data clearly has both high frequency noise and low frequency drift. The hardware is identical, so it must be a software configuration difference. What could be causing this?

PMD-1208FS support

It seems uldaq cannot detect PMD-1208FS.
Is there any way to add this device?
The device is readable in windows with InstaCal.

./AOut Example of uldaq not finding Daq device

I followed instructions to install uldaq and libusb. When I run examples, they do not find my installed device. My installed device is usb-3101. See issue in image below.

Invalid Re-trigger Count

I am attempting to synchronize a MCC 1608FS-Plus with another device using the TRIG_IN terminal. I had a version where I started a continuous sample with a pulse (see here), but now I would like one scan per pulse, with the trigger rearming after each sample.

I am using the SO_RETRIGGER option, but I am running into the following problem. If I put 0 for the retriggerSampleCount, I get no data. If I put any positive number, I get an "Invalid re-trigger count" error. You can see my work here.

I'm not sure if this affects anything, but I notice that there is no mention of the SO_RETRIGGER option in /src/usb/ai/AiUsb1608fsPlus.cpp like there are in the files for other devices.

undefined reference to `ulGetDaqDeviceInventory'

hello~

I installed the uldaq on my computer (Ubuntu 18.04)

when I want to compile the .c file, the following errors occured...

gcc test.c -o test

/tmp/ccLwGb0k.o: In function `main':
test.c:(.text+0x66): undefined reference to `ulGetDaqDeviceInventory'
test.c:(.text+0x9f): undefined reference to `ulCreateDaqDevice'
test.c:(.text+0xca): undefined reference to `ulConnectDaqDevice'
test.c:(.text+0x10b): undefined reference to `ulAIn'
test.c:(.text+0x151): undefined reference to `ulDisconnectDaqDevice'
test.c:(.text+0x160): undefined reference to `ulReleaseDaqDevice'
collect2: error: ld returned 1 exit status

my question is
how to compile and execute an .exe file correctly?

Thanks!
Looking forward to receiving your replies...

230 series

The 230 series is not on the list of supported devices. Can it be added?