VISA USB-RAW on cRIO-9030

[Levente.Raj]

Dear Community,

I would like to use my PhidgetSpatial Precision 3/3/3 1044_0 http://www.phidgets.com/products.php?category=1&product_id=1044_0 sensor on my cRIO-9030 as a raw USB device.

I have already used it on my Windows desktop trough VISA USB:RAW. It had a Windows driver but the device is using simple USB Interrupt pipe so I've replaced the original driver with a NI-VISA driver using the NI-VISA Driver Wizard (see attachment).

My problem is that if I connect the sensor to my cRIO than it won't display in the Devices and Interfaces section in MAX. I've done some reasearch in the Linux OS of my cRIO. The device is listed when I issue the lsusb command: Bus 001 Device 011: ID 06c2:0033 Phidgets Inc. (formerly GLAB).

dmesg gives the following:

[  227.696213] usb 1-3.3: new full-speed USB device number 11 using xhci_hcd

[  227.799332] hid-generic 0003:06C2:0033.0003: device has no listeners, quitting

It seems that a HID driver loads if the device is connected, but immediately terminates because there is no listeners.

The device is connected however. Looking in the /sys/bus/usb/devices/1-3.3/1-3.3:1.0 folder ls gives tge following:

0003:06C2:0033.0004   bInterfaceClass	bInterfaceProtocol	bNumEndpoints	ep_81	subsystem	uevent
bAlternateSetting	bInterfaceNumber	bInterfaceSubClass	driver	modalias	supports_autosuspend

And the objects are accessible, they can be read.

Unfortunately the sensor has a HID USB Device Class (03h) identifier.

As far as I understand generic hid driver is a built-in kernel module so I can't just unload it because it is part of the kernel.

My question is can I somehow tel the kernel to use NI-VISA for my sensor like I did on Windows?

Thank you for your answer.

Levente Raj

[mbrue101]

Running into a very similar problem and was hoping to hear if you had found a resolution.

Thanks!

Mike

[Jolt]

Old thread but description is close to my issue. I have a HID-based sensor that I got working well on Windows using the NI VISA wizard and USB RAW interrupt transfers. With the custom driver in Windows the device shows up in MAX on my local machine. 

On the NI Linux RT target I cannot seem to get it to show up or otherwise be available from MAX or LV.

The device does show up through a terminal and "lsusb". "dmesg" suggests it is using "ci_hdrc" but I don't know enough about what that is to know if that is OK.

Any thoughts from those posted above or anyone else?

[BradM]

Hi Jolt,

The ci_hdrc is the USB controller that the HID device is being plugged into. This just indicates that the system sees that you've plugged some USB device into the host controller on the RT target.

I do not know if the VISA support on NI Linux RT supports raw USB, that's probably a more appropriate question for the Instrument Control board, https://forums.ni.com/t5/Instrument-Control-GPIB-Serial/bd-p/140

[Jolt]

Right, now I see. When I do better looking at dmesg I see that the system has loaded "usbhid". This is also observed in "lsmod".

I did, however, get a little close to my goal...

Following some instructions found in other forum and KB locations I tried removing the module.

From a terminal type: "rmmod usbhid"

Now the device shows up in MAX! My interface code that worked on Windows (direct VISA commands) works exactly as expected when deployed to the RT system. 

This is good, but.... everything is reversed when the device is unplugged and re-plugged into the USB port or if the controller is power cycled 

So, when the usbhid module is "removed" the device works as needed but I have only achieved this manually and temporarily. 

I have started looking at blacklisting the module more permanently or running a system command from the RT code to remove the module at runtime but so far nothing has worked. Probably a topic for another thread...

[BradM]

---

@Jolt wrote:

Right, now I see. When I do better looking at dmesg I see that the system has loaded "usbhid". This is also observed in "lsmod".

I did, however, get a little close to my goal...

Following some instructions found in other forum and KB locations I tried removing the module.

From a terminal type: "rmmod usbhid"

Now the device shows up in MAX! My interface code that worked on Windows (direct VISA commands) works exactly as expected when deployed to the RT system. 

Awesome, great to hear!

This is good, but.... everything is reversed when the device is unplugged and re-plugged into the USB port or if the controller is power cycled 

So, when the usbhid module is "removed" the device works as needed but I have only achieved this manually and temporarily. 

I have started looking at blacklisting the module more permanently or running a system command from the RT code to remove the module at runtime but so far nothing has worked. Probably a topic for another thread...

---

Sure, we could do another thread, but this sort of thing is what this forum is for (working with the underlying Linux system. And, yes, you can absolutely setup a blacklist to prevent the module from loading (I've done this before for some other reason)

[bstreiff]

You might be able to accomplish it with a udev rule and the "unbind" functionality:

You'd need to create a new file in /etc/udev/rules.d (maybe something like "phidgetspatial.rules"), with something akin to:

SUBSYSTEM=="usb", ATTRS{idVendor}=="06c2", ATTRS{idProduct}=="0033", RUN="/bin/sh -c 'echo -n $id:1.0 > /sys/bus/usb/drivers/usbhid/unbind'"

[Jolt]

Thanks Brad!

Do you have an pointers or resources to point me at regarding blacklisting? What I found so far does not seem to be directly applicable to the NI Linux structures (but I could be missing something as I learn more about the OS).

Edit: was editing this post as Brandon's came in. I'll try some of his suggestions later today...

[BradM]

I prefer setting a modprobe.d config file (specifically, using the install command to prevent the module from being loaded, just a normal blacklist will still load the module if some other, dependant module is loaded)

---

@Joltadmin@crispus-attux:~# lsmod                                                    
Module                  Size  Used by                                           
ipv6                  334709  18                                                
g_ether                 2870  0                                                 
u_ether                 9864  1 g_ether                                         
libcomposite           38505  1 g_ether                                         
ci_hdrc                30715  0                                                 
udc_core               27461  3 u_ether,libcomposite,ci_hdrc                    
phy_generic             4530  0  
admin@crispus-attux:~# cat /etc/modprobe.d/blacklist.conf                       
install ci_hdrc_usb2 /bin/false      

---

Here, placing a file at /etc/modprobe.d/*.conf (needs to end with .conf) and providing the commands used to load the appropriate driver (and using /bin/false, which simply returns a non-zero return code, indicating failure) causes the kernel to not load the module and to know that it failed to load the module, preventing the module from being loaded by a dependant modules (e.g. if A depends on B, and you don't want B loaded, simply blacklisting B will still result in B being loaded when A is loaded, providing instructions on how to load B will cause it to never load)

[Jolt]

I think that did it. The specific module I wanted to blacklist was "usbhid"

Using:

~/# echo "install usbhid /bin/true" > /etc/modprobe.d/usbhid.conf

Reboot

Everything seems to work! I can un-plug and re-plug the sensor and still connect to it from LV. 

Sincere thanks for the help!