Instrument Control (GPIB, Serial, VISA, IVI)

cancel
Showing results for 
Search instead for 
Did you mean: 

USB unstable in Linux

Hi,

I'm trying to comunicate with a Tek2004b scope using VISA-USB on Linux. I've tried it with Red Hat AS 4 (Worked with standard install procedure) and Fedore Core 6 (Used modified install procedure, as outlined elsewhere in forums), both had the same problem. I can only communicate with the scope over one session. Meaning, I can viOpen(), run any number of commands, all working beautifully, then viClose(). Afterwards, the device becomes unresponsive, all read/writes timeout. I have to either unplug and replug the usb cable or restart the PC.

A good example is the interactive control. VisaIC finds the scope, but when you try to open it using VisaIC, the scope doesn't respond to any read/writes. This is because, when VisaIC starts up, it checks out each device and then closes the sessions. This causes my scope to become unresponsive and further read/writes won't work.

Has anyone seen this problem before? It seems like it might be fixed if I can somehow "soft unplug" the scope, so have the PC rediscover it. That would be a workable solution, but I can't physically unplug the cable everytime because I'm going to operate the pc remotely. Is there anyway to "flush" the usb?

Red Hat AS 4 kernel is 2.6.9-34, Fedore Core 6 kernel is 2.9.18, using devfs on both (so all usb device info is in /proc/bus/usb).

Thanks a lot,
Jeff
0 Kudos
Message 1 of 8
(4,510 Views)

Hi,

When using the ViClose(), are you closing the instrument session or the VISA session?  I have attached an image that illustrates how to open a session using C source code.  At the end of the code there are two resources that are closed, the instrument and the defaultRM.  I think what might be happening is the defaultRM is being closed and not the instrument.  If the defaultRM is being closed you will not be able to open a new instrument session before reinitializing your device. 

I searched several resources to find a way you could reconnect to your USB device using the OS but unfortunately I could not find a way to accomplish it. 

Regards,

Andy L.
Applications Engineer
National Instruments
0 Kudos
Message 2 of 8
(4,474 Views)
Thanks for getting back.

I don't think this is the case. The code works fine in Windows, so unless something different should be done in Linux... I've included my open and close code so you can check.

I've also looked around for a way to reinitialize a usb device. I tried "umount /proc/bus/usb; mount -t usbfs none /proc/bus/usb" but that doesn't seem to do it.

I tried commenting out the viClose(rm); line in my Close() function, but this didn't seem to change anything. I've also tried simply killing my program, so that neither the instrument or RM are closed, but this doesn't seem to do much.

Jeff

int VisaInstrument::Close()
{
    if (DeviceState==VIS_CLOSED)
    {
        return VIR_SUCCESS;
    }
    else if (DeviceState==VIS_OPENBUSY)
    {
        return VIR_BUSY;
    }
    else
    {
        viClose(vi);
        viClose(rm);
        DeviceState=VIS_CLOSED;
        return VIR_SUCCESS;
    }
}


int VisaInstrument::Open(string Device, int TO)
{
    if (DeviceState!=VIS_CLOSED)
    {
        return VIR_ALREADYOPENED;
    }
   
    status=viOpenDefaultRM(&rm);
   
    if (status<VI_SUCCESS)
    {
        return VIR_OPENFAILURE;
    }
    status=viOpen(rm,(ViChar*)Device.c_str(),VI_NULL,VI_NULL,&vi);
    if (status<VI_SUCCESS)
    {
        viClose(rm);
        return VIR_OPENFAILURE;
    }
   
    status=viSetAttribute(vi,VI_ATTR_TMO_VALUE,TO);
    if (status<VI_SUCCESS)
    {
        viClose(vi);
        viClose(rm);
        return VIR_OPENFAILURE;
    }

    DeviceState=VIS_OPENFREE;
    TimeOut=TO;
   
    return VIR_SUCCESS;
}

0 Kudos
Message 3 of 8
(4,466 Views)

Hi,

Here are 3 things to try after the device becomes un-responsive that might help regain device functionality without having to reboot the machine.

NOTE: most of these commands require root permissions, so either run them as root, or use sudo to run with root permission.


            A. Try to un-mount and then re-mount the USB device:

                        From the console / terminal:

                                    unmount <mount point>

                                    mount <mount point>

 

            B. Restart the userspace device system:

                        Run the following command from the console / terminal:

                                    /etc/init.d/udev restart

 

            C. Unload and reload the USB drivers:

                        1. Use the "lsmod" command to locate the usb drivers

                        2. Use the rmmod command to unload the drivers.

                                    For example:

                                        rmmod usb-storage

                                        rmmod usb-ohci

                                        rmmod usbstorage

                        3. Then use the modprobe command to reload all the modules:

                                modprobe usb-storage

0 Kudos
Message 4 of 8
(4,440 Views)
So I've thuroughly tried all these options as well, to no avail.

Remounting /proc/bus/usb doesn't work.

In Fedora, I believe the proper way to restart udev is /sbin/start_udev (Although I could be wrong here) This doesn't work.

Finally, unloading the drivers (Which should be done with a /sbin/start_udev right?) doesn't work either. My usb drivers are uhci_hcd.

Also, combining all these doesn't work either. (Meaning unmount, rmmod drivers, and start_udev).

The problem might lie in the ni- driver set. Is there a way I could reinitialize them without a reboot? I don't seem to be able to rmmod them, since they are always in use, and if I try to force, (-f), it tells me the resource is temporarily unavailable.

Using udevmonitor while running start_udev seems to show that start_udev simple removes and then adds all devices. Is it possible that something is called in a "DeviceInsertion" event that is not called during an "Add" event? Does one imply the other?

The scope works perfectly using windows, so there really seems to be something funny with the linux implementation.

Thanks,
Jeff
0 Kudos
Message 5 of 8
(4,275 Views)
Hi Jeff,
 
I don't know of a way to reinitialize  the drivers without a reboot on Linux.  What build of Fedora and the Kernel are you using?  The supported Linux Distributions for National Instruments Drivers and Software is located here
 
Regards,
Andy L.
Applications Engineer
National Instruments
0 Kudos
Message 6 of 8
(4,247 Views)
I'm seeing the problem in both Red Hat AS 4 kernel is 2.6.9-34, Fedore Core 6 kernel is 2.9.18. NI-Visa installs out of the box on AS 4 and seems to work just fine. For Fedora, there are methods discussed in these forums on how to get it working.

Jeff
0 Kudos
Message 7 of 8
(4,229 Views)
Hi Jeff,
 
What NI software do you have installed on your Red Hat machine?  Make sure you have the most up-to-date version of NI-KAL installed on your machine, you can download this driver here: http://joule.ni.com/nidu/cds/view/p/id/850/lang/en
 
Unfortunately both Red Hat AS (WS is supported) 4 and Fedore are not supported by NI products, and so VISA is not guaranteed to work.  Have you been able to communicate with your scope with an earlier kernel version, have you encountered this behaviour with other usb devices? 
 
Ted
Ted H
Applications Engineering
National Instruments
0 Kudos
Message 8 of 8
(4,208 Views)