labjack/labjack-ljm-python

WSL support?

Closed this issue · 3 comments

jmarkow commented

Now attempting to use this library with the Windows Subsytem for Linux (specifically Ubuntu 20.04 LTS). Everything installs fine, and I'm able to get access to the Labjack over USB via https://learn.microsoft.com/en-us/windows/wsl/connect-usb .

I'm trying to run this example program as a sanity check

https://github.com/labjack/labjack-ljm-python/blob/master/Examples/More/Stream/periodic_stream_out.py

Running it results in the following error. If WSL is unsupported or out of scope feel free to close this issue, but it would be nice to support if possible.

Beginning...

Error calling ljm.open(deviceType=0, connectionType=0, identifier=ANY)
Traceback (most recent call last):
  File "/home/jmarkow/dev/labjack_test.py", line 116, in <module>
    main()
  File "/home/jmarkow/dev/labjack_test.py", line 95, in main
    handle = openLJMDevice(ljm.constants.dtANY, ljm.constants.ctANY, "ANY")
  File "/home/jmarkow/dev/labjack_test.py", line 52, in openLJMDevice
    handle = ljm.open(deviceType, connectionType, identifier)
  File "/home/jmarkow/miniconda3/envs/dearpygui-test/lib/python3.10/site-packages/labjack/ljm/ljm.py", line 382, in open
    raise LJMError(error)
labjack.ljm.ljm.LJMError: LJM library error code 1230 LJME_DEVICE_CURRENTLY_CLAIMED_BY_ANOTHER_PROCESS
sjarman28 commented

If you can avoid using WSL, I would suggest doing so. It does not currently seem very friendly for USB devices.

It seems that WSL does not load udev rules by default, and that could cause an error like you are seeing since our udev rules are necessary for non-root access to the USB device. There are two likely options:

  1. run your scripts using sudo (not a great solution)
  2. Ensure udev is started, reload rules if necessary (potentially not a great solution, but maybe better overall)

To achieve the second option, you might be able to just run the following command (may need sudo):
service udev start

I got an error that "udev does not support containers, not started". This seems to be a lie, and you can probably edit the udev init script (/etc/init.d/udev) to get around it. That would be editing a file you typically should not touch, so do it at your own risk. I just had to comment out the following lines in the script like so:

#if ! ps --no-headers --format args ax | egrep -q '^\['; then
#    log_warning_msg "udev does not support containers, not started"
#    exit 0
#fi

If udev was already started but for some reason our udev rules have not been applied, you could try one of the following command sets to reload the rules (may need sudo):

service udev restart

or

udevadm control --reload-rules
udevadm trigger
jmarkow commented

Thanks for the fast reply. I didn't mod the udev rules so that could be the culprit. The issue is on a work machine so I'll have to check tomorrow morning. Will ping then with results. BTW I'm using WSL 2.

If for some reason this doesn't work we can easily fall back and avoid WSL.

jmarkow commented

That seems to have fixed it, I think we're good for now. If we run into further complications we can run without WSL. Needed to run sudo service udev start . Got a warning about it not being recommended and it waited 60 seconds before executing. Afterwards I was good to go.