Balluff - BVS CA-BN Technical Documentation
|
Additional packages will be needed to use all features of Impact Acquire.
Compiler etc. for building applications:
Additional packages (mandatory) for running applications:
wxWidget release 3.0 or 3.2 packages, e.g.
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:
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.
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:
Architecture | Package |
ARM64 | ImpactAcquire-arm64-linux-3.5.0.sh |
x86_64 | ImpactAcquire-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.
/home/username/Downloads
: cd /home/username/Downloads
chmod a+x ImpactAcquire-x86_64-linux-3.5.0.sh
./ImpactAcquire-x86_64-linux-3.5.0.sh
During installation, the script will ask if it should build all tools and samples.
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.
The script supports various arguments for customizing the installation, the desired functionality and the installation process itself. All arguments are optional:
Argument | Function | Notes |
-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> | Description | Will 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 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.
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.
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.
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):
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.