Note: This section is only relevant for applications working with USB3 Vision™ or Balluff USB 2.0 devices!; Another important aspect when dealing with USB3 Vision™ devices is described here.

Checklist for Windows

Host Controller Driver

Also the USB host controller manufacturers provide driver updates for their cards/chips every now and then. Using the latest drivers is always recommended and might improve the overall performance of the system dramatically!

Checklist for Linux

udev rules

Most Linux system nowadays use the udev device manager, which is responsible for dynamically managing the /dev tree. In order to be able to use the Balluff mvBlueFOX3 (BVS CA-SF) "USB3 Vision" camera as non-root user, a special set of rules has to be handed to the udev device manager.

On older systems this could be done by directly editing the contents of a "/etc/udev/rules" file, however nowadays a "/etc/udev/rules.d" directory exists, which may contain several different files, each defining the behavior of a system device.

In the specific case of BVS CA-SF device or any "USB3 Vision" device actually, if the camera has been installed through the respective installation script ImpactAcquire-x86_64-linux-3.3.0.sh, a suitable set of rules has been installed automatically. However if for some reason these rules have to be created manually or must be changed at later time it should be done like this:

Create a file in the "/etc/udev/rules.d" directory with name 52-U3V.rules if this doesn't exist already. The content of the file should be something like this:

SUBSYSTEM!="usb|usb_device|plugdev", GOTO="u3v_rules_end"
ACTION!="add", GOTO="u3v_rules_end"

ATTRS{bDeviceClass}=="ef", ATTRS{bDeviceSubClass}=="02", ATTRS{bDeviceProtocol}=="01", 
        ENV{ID_USB_INTERFACES}=="*:ef0500:*", MODE="0664", GROUP="plugdev"

LABEL="u3v_rules_end"

OPTIONAL: Create another file in the "/etc/udev/rules.d" directory with name 52-mvbf3.rules . This step is only necessary if a BVS CA-SF in the "mvbootloader" state should be recognised by the system. This might happen if for any reason a camera has no valid firmware running e.g. due to a power failure during a firmware update. The content of the file should be something like this:
```
SUBSYSTEM!="usb|usb_device|plugdev", GOTO="mvbf_rules_end"
ACTION!="add", GOTO="mvbf_rules_end"

ATTRS{idVendor}=="164c", ATTRS{idProduct}=="5531", MODE="0664", GROUP="plugdev"

LABEL="mvbf_rules_end"
```

Note: The above 52-U3V.rules file provides the necessary access privileges not only for BVS CA-SF cameras, but also for any "USB3 Vision"-compliant device of other vendors.

As soon as this file is into place, each time the camera is plugged to the system it acquires the set of rights that allows the user to use it without having root privileges.

Increasing Kernel memory

On most modern Linux systems, support for USB3 functionality has been moved from separate kernel modules to the kernel itself (usbcore). On such systems, the kernel memory which is allocated for the use with USB is predefined and set to a relatively small value (e.g. 16 MB on a typical 64-bit Ubuntu system). This value is usually enough for reading from an external HDD, operating a mouse or a keyboard or similar applications, but in the case of machine vision applications, with Megapixel sensors and ultra-fast transfer speeds it is way too low since this memory is needed as a temporary buffer for image data and especially with high resolution sensors not even a single image might fit into this memory segment then.

Note: You may inquire the value (in Megabytes) on your system by typing:
cat /sys/module/usbcore/parameters/usbfs_memory_mb

We recommend to increase this value to at least 256 MB or even more depending on your application (number of cameras, number of image buffers needed per camera etc.). For example, a 5 Mpix camera, capturing RGB data with a default request/image buffer count of 10, needs about 5M * 3 * 10 ~= 150MB of the usbfs memory alone. Always bear in mind though, that Impact Acquire is probably not the only system component using usbcore memory, so you should always reserve several MB more than the number you get from the above calculation. As a general rule of thumb, for a single-camera application with a medium resolution and a default request setting of 10, a value of 256 MB should be adequate.

Note: If systemd is supported on the system, the installation script will ask if a systemd service should be created which modifies the value on each boot. Once this option is used, which is highly recommended, the following Kernel memory chapters will no longer be relevant and can be skipped.

Increasing Kernel memory at boot time

To change the value of the usbfs_memory_mb system parameter, one has to invoke the kernel at boot time with an argument that sets the parameter to the desired value. Trying to modify this parameter after the system has booted (e.g. with modprobe ), will have no effect since usbcore is a system module integrated in the Linux kernel, and not a separate kernel module which can be loaded and unloaded on demand.

Passing parameters to the kernel at boot time is usually done by typing: systemModuleName.parameter=value . Therefore to reserve 256MB of USB memory we need:

usbcore.usbfs_memory_mb=256

How this can be done depends on the system bootloader. For systems using the GRUB2 bootloader the "/etc/default/grub" ( or in some distributions "/etc/default/grub/c.cfg" ) file has to be modified.

Attention: Always modify configuration files with extreme caution, since the slightest syntax error may render the file invalid, or even the system no longer bootable!

After opening this file, the GRUB_CMDLINE_LINUX_DEFAULT entry must be located. It usually has the following value:

GRUB_CMDLINE_LINUX_DEFAULT="quiet splash"

In order to invoke the Kernel with the usbfs_memory_mb parameter, it should be modified like:

GRUB_CMDLINE_LINUX_DEFAULT="quiet splash usbcore.usbfs_memory_mb=256"

As a final step, GRUB has to be updated by executing the update-grub script:

sudo update-grub

If all went well, after rebooting the system, the kernel will utilize the requested amount of memory for the usbcore subsystem. See Increasing Kernel memory again for how to check this!

Note

On systems with GRUB Legacy support the bootloader settings are controlled by other files ( e.g. "/boot/grub/menu/c.lst" etc.). In this case it is recommended to upgrade your bootloader to GRUB2 :

sudo apt-get install grub2

If, for some reason, this is not an option, then the menu.lst itself could be directly modified as an absolutely last resort. Always keep in mind that it is strongly recommended not to tamper directly with files in the /boot/grub directory! The smallest typing error can render the system no longer bootable!

Increasing Kernel memory at runtime

If just a temporary change of the usbfs_memory_mb parameter is needed or there is no way to pass the parameter at boot time to the kernel, it will be sufficient to modify the usbfs.usbfs_memory_mb value at runtime. The following command will be sufficient to change the usbfs_memory_mb value to 256 MB until the system is restarted:

sudo sh -c 'echo 256 > /sys/module/usbcore/parameters/usbfs_memory_mb'

Note: root permissions will be necessary to change the parameter at runtime.

Disabling The Auto-Suspend Mode

Usually the Linux kernel suspends USB devices when they are not in use for a certain time. In some cases this might cause unsuspected behaviour of USB devices. To avoid this kind of issues it is a good idea to disable the USB autosupend mode.

sudo sh -c 'echo -1 > /sys/module/usbcore/parameters/autosuspend'