Balluff - BVS CA-BN Technical Documentation
Linux

Requirements

Additional packages will be needed to use all features of Impact Acquire.

Compiler etc. for building applications:

  • build-essential (meta package)
  • gcc 5.5.0 environment or newer
  • cmake 3.10 or newer

Additional packages (mandatory) for running applications:

  • OpenMP runtime

wxWidget release 3.0 or 3.2 packages, e.g.

  • libwxbase3.0-0v5
  • libwxbase3.0-dev
  • libwxgtk3.0-gtk3-0v5
  • libwxgtk3.0-gtk3-dev
  • libwxgtk-webview3.0-gtk3-0v5
  • libwxgtk-webview3.0-gtk3-dev
  • wx3.0-headers
  • libgtk2.0-dev

In order to compile the kernel module which is required to use BVS CA-BN (mvBlueNAOS) PCIe device kernel module the following kernel headers will be required:

  • linux-headers-[version_of_the_used_kernel]
Note
On the kernel header packages might have different names on different platforms like Raspberry Pi or NVIDIA Jetson platforms:
  • nvidia-l4t-kernel-headers
  • raspberrypi-kernel-headers
The names of the packages mentioned above are Debian / Ubuntu specific. Other distributions (e.g. SuSE, Arch, Redhat, ...) will use different names.

The installation script will ask if the packages should be downloaded during the installation process. If some of the packages are not installed some features might not be available. If the e.g. wxWidgets related packages are missing on the target system then all GUI application coming as part of the Impact Acquire installation won't be available.

Installation

To use a (camera) device in Linux (capture images from it and change its settings), a software stack is needed, consisting of several libraries and several configuration files. These files are required during runtime.

To develop applications that can use the device, an API containing header files, makefiles, samples, and a few libraries is needed. These files are required at compile time.

Both file collections are distributed in a single package which is available in the Download section of the Balluff website. This package is distributed as a single installer script (e.g. ImpactAcquire-x86_64-linux-3.5.0.sh). The script contains everyhing needed to install ImpactAcquire.

The following table shows the supported platforms and the corresponding installation script name:

ArchitecturePackage
ARM64ImpactAcquire-arm64-linux-3.5.0.sh
x86_64ImpactAcquire-x86_64-linux-3.5.0.sh

The following example explains the installation process for the x86_64 package. The installation process for other packages will work almost identically except that different names are used, as mentioned in the previous table.

  • Please start a console and change into the directory where the installation script is located e.g. /home/username/Downloads :
    cd /home/username/Downloads 
    Note
    If root permissions are needed, the script will ask for the permissions. There is no need to call it with root permissions.
  • You might need to enable the execute flag with:
    chmod a+x ImpactAcquire-x86_64-linux-3.5.0.sh
  • Run the install script:
    ./ImpactAcquire-x86_64-linux-3.5.0.sh

During installation, the script will ask if it should build all tools and samples.

Note
The installation script has been developed for Ubuntu/Debian, SUSE Linux and Red Hat Linux based distributions. On other distributions some features of the installation script may or may not work. Get in touch with us if you encounter any problems!

The installation script checks for package dependencies described above and installs them with the respective standard package manager (e.g. apt-get) if necessary. So an Internet connection is recommended.

Note
  • Nothing is written to the directory containing the script during execution, so no write access to the directory is needed in order to execute the script.
  • In case one or more of the packages the Impact Acquire framework depends on are not yet installed on your system, the script tries to install the missing packages. Therefore, when something is missing, Internet access is required during the installation.

Installation Options

The script supports various arguments for customizing the installation, the desired functionality and the installation process itself. All arguments are optional:

ArgumentFunctionNotes
-h
--help
Display the help.
-p
--path
Define a custom installation directory.The target directory name specifies where to place the software package. If the directory does not yet exist, it will be created. The path can be either absolute or relative; i.e. the name may but need not start with / .
If no path is specified, the package will be installed to /opt/ImpactAcquire.
-a=
--add=
<tech1>[,<tech2>]..
Install features supporting the given technologies.See table below for possible values for the 'tech' parameter.
-e=
--exclude=
<tech1>[,<tech2>],..
Do not install features supporting the given technologies.
-py
--python_support
Compile the Python wrapper and install the required dependencies. Once a version number is passed to this parameter, the installation script will try to install this particular version, if possible.e.g. --python_support=3.9
-r
--remove
Remove the previously installed version for ALL devices, if found.Defaults to no or yes if a 2.x.x installation is found on the system.
-x
--extract
Extract the embedded files as a tgz archive, testing the checksum, but do not install anything.
-u
--unattended
Unattended installation with default settings.By using this parameter the EULA will be accepted automatically.
-m
--minimal
Minimal installation. No tools or samples will be built, and no automatic configuration and/or optimizations will be done.
-rt
--runtime
Minimal installation. No tools or samples will be built.

Possible values for the 'tech' parameter when using '-a', '–add', '-e' and '–exclude':

Value for <tech>DescriptionWill be installed by default?
gev GigE Vision™.yes
u3v USB3 Vision™.
pcie BVS CA-BN (mvBlueNAOS) PCIe camera.
usb2 BVS CA-MLC/BVS CA-IGC (mvBlueFOX) USB2 camera.
vdev Virtual Device.no

UEFI SecureBoot with Linux on x86_64 platforms

UEFI SecureBoot is available on most modern x86 hardware and is used to ensure that only validated operating system binaries can be used. If you are using the BVS CA-BN camera on an ARM-based system please ignore the following section.

SecureBoot requires the Linux kernel and all loadable kernel modules to be signed using a digital signature saved on the system. Since the Balluff BVS CA-BN PCIe camera makes use of a kernel module which has been individually built for the system, this kernel module must also be signed in order to be loadable.

If you do not need UEFI SecureBoot protection it is advisable to turn it off in the BIOS settings for your PC. For details please see the BIOS documentation for your PC. In this case you can ignore the following section, since the Balluff kernel module will not need to be signed.

However, if you are unable to turn off SecureBoot or would like to continue using it then the kernel module will need to be signed after it has been built. The install script will try to do this using appropriate digital keys it finds on the system. In some cases you may need to install extra software on the PC and reinstall Impact Acquire using the install script or you may want to use your own digital keys to sign the kernel module.

In all cases you will have to register the key used with each PC individually, unless this has already been done with a key pair for which you have the private key (see below).

The following section describes how to install and use keys supplied by Debian-based distributions such as Ubuntu. Other Linux distributions may have similar packages that contain keys - please refer to your distribution's documentation.

Using keys supplied by Debian / Ubuntu

The Balluff Impact Acquire install script attempts to use keys found in the directory "/var/lib/shim-signed/mok". If this directory or the keys "MOK.priv" and "MOK.der" do not exist on your system please try installing this package: "shim-signed"

Afterwards, reinstall Impact Acquire using the install script. The tool called "kmodsign" and the keys "MOK.priv" and "MOK.der" will be used automatically after building the kernel module.

Using your own keys or signing by hand

Alternatively you can sign the kernel module yourself, by hand, using your own keys or those supplied by "shim-signed". An example of signing a kernel-module is shown below. Substitute your own keys and their locations, if required.

cd /lib/modules/$(uname -r)/kernel/misc
sudo kmodsign sha512 /var/lib/shim-signed/mok/MOK.priv /var/lib/shim-signed/mok/MOK.der mvpci.ko

Registering validation keys with the system

Debian and Ubuntu use a tool called "mokutil" to import a key for registration on a system. This action is only needed once per key on each PC.

The command to use looks like this (substitute your own key and its location, if required):

sudo mokutil --import /var/lib/shim-signed/mok/MOK.der

You will be asked to provide a one-time password. Choose anything you like, but take note of what you have chosen!

The next time your PC is restarted and before the Linux kernel boots a program called "MokManager" will be started. You will be presented with a blue box asking if you want to administer the keys on the system. Choose the option to do this and then follow the instructions on the screen to register your key. You will be asked to provide your one-off password that you used with "mokutil"!

Once the key has been successfully registered the kernel will boot and it will be possible to load any kernel modules that have been signed using this key.

References