|
Impact Acquire SDK C++
|
This chapter will explain what has to be done to build installation packages for the target platform that include all files needed to operate the device without the need to ship the full Balluff Impact Acquire setup.
The latest official drivers can always be found here: https://www.balluff.com/en-de/downloads/software
Most of the driver packages are distributed as MSI (Microsoft Windows Installer™) packages. Some however will be distributed as EXE files. These packages contain so called bootstrappers - a special package format to distribute multiple files as a single installation. The internal underlying technology is also MSI.
If your installation also uses the MSI technology this is the easiest way to distribute all the related driver files! All merge modules (*.msm-files) that belong to a certain version of Impact Acquire can be downloaded from the Balluff website (https://www.balluff.com) as a compressed archive.
After extraction these merge modules then can be included into your setup project as needed and you are done.
32-bit merge modules contain 32-bit code only while 64-bit merge modules contain everything that will allow running both 32-bit and 64-bit applications. The names of the merge modules belonging to Impact Acquire will use the following extensions:
So to run 32-bit applications on a 32-bit version of Windows ONLY the 32-bit *.msm files shall be used and to run either 32- or 64-bit applications (or both 32- AND 64-bit applications) ONLY the 64-bit *.x64.msm files shall be used. The only exceptions from this rule are third party merge modules (e.g. the OpenMP-runtime) where this is stated differently in the list of merge modules below. As an example what is inside a merge module let us consider the mvIMPACT_AcquireBaseLibs file:
mvIMPACT_AcquireBaseLibs.msm contains the 32-bit version of mvDeviceManager.dll and mvPropHandling.dll mvIMPACT_AcquireBaseLibs.x64.msm contains the 32-bit AND the 64-bit version of mvDeviceManager.dll and mvPropHandling.dll. Both versions of the 2 libraries will be installed into the appropriate target directoriesSometimes user interaction during an installation is not desired. The MSI engine therefore supports a set of command line options that can be used to run setups in special ways.
Probably the most common way to run an unattended setup will be an installation without any GUI display or user interaction. This can be achieved like this:
or (with an automatic reboot of the system at the end of the installation):
For a complete list of option type
in a command shell an hit the ENTER key.
This SDK currently is built using Microsoft Visual Studio® 2019. When building a custom installation therefore the required Microsoft Visual Studio® runtime libraries must be installed on the target machine. The recommended way of doing that is by installing the corresponding redistributables:
This following section contains merge modules will be needed by any custom installer that shall support Impact Acquire compliant devices:
| Impact Acquire driver framework | |
|---|---|
| Name of the 32-bit merge module | mvIMPACT_AcquireBaseLibs.msm |
| Name of the 64-bit merge module | mvIMPACT_AcquireBaseLibs.x64.msm |
| Requirement | Must be installed. In order to work with GenICam compliant devices some environment variables must be set (see Environment Variables below). |
| Impact Acquire .NET Framework runtime | |
|---|---|
| Name of the merge module | mvIMPACT_Acquire.NET.msm |
| Requirement | Only needed if the target application has been written using the .NET Framework API of Impact Acquire. Refer to Building, Linking And Running Applications Using Impact Acquire about the differences between the .NET Framework and the .NET Standard API. |
| Impact Acquire .NET Standard runtime | |
|---|---|
| Name of the merge module | mvIMPACT_Acquire.NET.Standard.msm |
| Requirement | Only needed if the target application has been written using the .NET Standard API of Impact Acquire. Refer to Building, Linking And Running Applications Using Impact Acquire about the differences between the .NET Framework and the .NET Standard API. |
| Impact Acquire Java runtime | |
|---|---|
| Name of the 32-bit merge module | mvIMPACT_AcquireJava.msm |
| Name of the 64-bit merge module | mvIMPACT_AcquireJava.x64.msm |
| Requirement | Only needed if the target application has been written using the Java API of Impact Acquire. |
| Impact Acquire Python runtime | |
|---|---|
| Name of the merge module | mvIMPACT_AcquirePython.msm |
| Requirement | Only needed if the target application has been written using the Python API of Impact Acquire. |
| Impact Acquire tools prerequisites | |
|---|---|
| Name of the 32-bit merge module | mvIMPACT_AcquireExecutablesPrerequisites.msm |
| Name of the 64-bit merge module | mvIMPACT_AcquireExecutablesPrerequisites.x64.msm |
| Requirement | Only needed if mvIMPACT_AcquireTools is installed. Contains additional libraries that are needed by some of the tools. In particular this merge module contains the mvDisplay.dll which might be needed by a customers applications as well. |
| Impact Acquire tools | |
|---|---|
| Name of the 32-bit merge module | mvIMPACT_AcquireTools.msm |
| Name of the 64-bit merge module | mvIMPACT_AcquireTools.x64.msm |
| Requirement | Only needed if tools like ImpactControlCenter or DeviceConfigure shall be available |
This merge module has configuration options: Define a property CREATE_DESKTOP_SHORTCUTS in your installation and pass the value of this property to the merge module if you want desktop icons to be created for the tools. Define a property FILTER_INSTALL_PARAMS and feed it with a string containing arbitrary command line parameters to be sent to GigEConfigure when starting the system the next time. See Installation Options further down in this chapter for additional details.
| DirectShow support for Impact Acquire compliant devices | |
|---|---|
| Name of the 32-bit merge module | mvDirectShow_acquireDriver.msm |
| Name of the 64-bit merge module | mvDirectShow_acquireDriver.x64.msm |
| Requirement | Only needed if the application requires a DirectShow interface |
| VisionPro support for Impact Acquire compliant devices | |
|---|---|
| Name of the 32-bit merge module | mvIMPACT_Acquire_Cognex_Adapter.msm |
| Name of the 64-bit merge module | mvIMPACT_Acquire_Cognex_Adapter.x64.msm |
| Requirement | Only needed if the device shall be operated using VisionPro |
| NeuroCheck 6 support for Impact Acquire compliant devices | |
|---|---|
| Name of the 32-bit merge module | mvIMPACT_Acquire_NeuroCheck6_Adapter.msm |
| Name of the 64-bit merge module | mvIMPACT_Acquire_NeuroCheck6_Adapter.x64.msm |
| Requirement | Only needed if the device shall be operated using NeuroCheck 6. Files will only be installed if an existing NeuroCheck 6 installation can be detected in at least one of the ProgramFiles folders |
| NeuroCheck 6.1 support for Impact Acquire compliant devices | |
|---|---|
| Name of the 32-bit merge module | mvIMPACT_Acquire_NeuroCheck6_1_Adapter.msm |
| Name of the 64-bit merge module | mvIMPACT_Acquire_NeuroCheck6_1_Adapter.x64.msm |
| Requirement | Only needed if the device shall be operated using NeuroCheck 6.1. Files will only be installed if an existing NeuroCheck 6.1 installation can be detected in at least one of the ProgramFiles folders |
| User mode driver | |
|---|---|
| Name of the 32-bit merge module | mvGenTL-AcquireDriver.msm |
| Name of the 64-bit merge module | mvGenTL-AcquireDriver.x64.msm |
| Requirement | Must be installed. To use the user mode driver as a GenTL Producer you must create or append the corresponding environment variables (see Environment Variables below). |
| GenICam runtime | |
|---|---|
| Name of the 32-bit merge module | GenICamRuntime.msm |
| Name of the 64-bit merge module | GenICamRuntime.x64.msm |
| Requirement | Must be installed. The GenICam runtime needed to operate any device the complies with the GenICam standard that shall be used through the mvGenTL-Acquire driver package. |
When the original installer of the mvGenTL_Acquire driver package is used, the user will be prompted to restart the system at the end of the installation. During reboot then the GigE Vision™ Filter Driver is installed by GigEConfigure.exe. When all the appropriate merge modules have been integrated into the setup, this will also happen in custom installations. Sometimes user interaction during the installation is or is not desired and/or GUI based tools shall not be displayed. This can be achieved by changing a public property of the installer's internal data base.
An installation of the driver without any user interaction can be achieved like this from the command line:
This will install the driver, reboot the system and install the filter driver and will display the GigEConfigure tool to the user and will display some status information during the installation. Please note that you have to call the install engine from an administrator shell in order to get this working properly. Valid values for the FILTER_INSTALL_PARAMS property are all valid command line options for the GigEConfigure tool.
Apart from that there are some other public properties, which can be tailored to suit the needs of the application:
GEV_SUPPORT (Valid values: yes, no)GEV_NDIS_DRIVER_INSTALL (Valid values: yes, no)PCIE_SUPPORT (Valid values: yes, no)U3V_SUPPORT (Valid values: yes, no)These properties control whether the corresponding kernel drivers will be installed on the target system or not. The default for each property is displayed in bold.
So e.g. to install the GEV driver only you can call the MSI engine like this:
To copy all the GEV driver and tools related files to the target system only without actually installing the filter driver you can call the MSI engine like this:
GEV_SUPPORT to no will superimpose the GEV_NDIS_DRIVER_INSTALL property so combining GEV_SUPPORT=no and GEV_NDIS_DRIVER_INSTALL=yes does not make any sense!When only the U3V driver shall be support in silent mode call msiexec like this:
Configuring the filter driver installation tool then is not necessary, as it is only needed for GEV support.
| Kernel mode driver | |
|---|---|
| Name of the 32-bit merge module | mvGigECaptureDriver.msm |
| Name of the 64-bit merge module | mvGigECaptureDriver.x64.msm |
| Requirement | Should be installed for optimal performance. Needs additional work (Filter driver must be installed either by using the GigEConfigure tool or another appropriate method). See Non-MSI based section about installing the GEV driver for details. |
| GigE Vision specific tools | |
|---|---|
| Name of the 32-bit merge module | mvGigETools.msm |
| Name of the 64-bit merge module | mvGigETools.x64.msm |
| Requirement | Should be installed for optimal performance. Contains tools that can be used to install/remove/enable/disable the filter driver and to set up GigE Vision compliant devices. In order to automatically install the driver some environment variables must be set (see Environment Variables below). |
This merge module has a configuration option: Define a property CREATE_DESKTOP_SHORTCUTS in your installation an pass the value of this property to the merge module if you want desktop icons to be created for the tools.
| Technical manuals for GigE Vision devices | |
|---|---|
| Name of the 32-bit merge module | mvBlueCOUGARDocumentation.msm |
| Name of the 64-bit merge module | mvBlueCOUGARDocumentation.x64.msm |
| Requirement | Only needed if technical manuals for mvBlueCOUGAR devices shall be available |
| Kernel mode driver | |
|---|---|
| Name of the 32-bit merge module | mvUSB3VisionKernelDriver.msm |
| Name of the 64-bit merge module | mvUSB3VisionKernelDriver.x64.msm |
| Requirement | Must be installed for USB3 Vision support. |
| Technical manuals for USB3 Vision devices | |
|---|---|
| Name of the 32-bit merge module | mvBlueFOX3Documentation.msm |
| Name of the 64-bit merge module | mvBlueFOX3Documentation.x64.msm |
| Requirement | Only needed if technical manuals for mvBlueFOX3 devices shall be available |
| Kernel mode driver and GenTL Producer | |
|---|---|
| Name of the 32-bit merge module | So far a 32-bit version of this device driver doesn't exist! |
| Name of the 64-bit merge module | mvBlueNAOSDriver.x64.msm |
| Requirement | Must be installed to work with BVS CA-BN (mvBlueNAOS) devices. |
| Technical manuals for BVS CA-BN (mvBlueNAOS) devices | |
|---|---|
| Name of the 32-bit merge module | mvBlueNAOSDocumentation.msm |
| Name of the 64-bit merge module | mvBlueNAOSDocumentation.x64.msm |
| Requirement | Only needed if technical manuals for BVS CA-BN (mvBlueNAOS) devices shall be available. Please note that right now a 32-bit driver for mvBlueNAOS (Labs) devices doesn't exist! |
| Kernel mode driver | |
|---|---|
| Name of the 32-bit merge module | mvBlueFOXKernelDriver.msm |
| Name of the 64-bit merge module | mvBlueFOXKernelDriver.x64.msm |
| Requirement | Must be installed. |
| User mode driver | |
|---|---|
| Name of the 32-bit merge module | mvBlueFOXDriver.msm |
| Name of the 64-bit merge module | mvBlueFOXDriver.x64.msm |
| Requirement | Must be installed |
| Technical manuals for mvBlueFOX devices | |
|---|---|
| Name of the 32-bit merge module | mvBlueFOXDocumentation.msm |
| Name of the 64-bit merge module | mvBlueFOXDocumentation.x64.msm |
| Requirement | Only needed if technical manuals for mvBlueFOX devices shall be available |
| User mode driver | |
|---|---|
| Name of the 32-bit merge module | mvVirtualDeviceDriver.msm |
| Name of the 64-bit merge module | mvVirtualDeviceDriver.x64.msm |
| Requirement | Must be installed |
| Technical manuals for mvVirtualDevice devices | |
|---|---|
| Name of the 32-bit merge module | mvVirtualDeviceDocumentation.msm |
| Name of the 64-bit merge module | mvVirtualDeviceDocumentation.x64.msm |
| Requirement | Only needed if technical manuals for mvVirtualDevice devices shall be available |
If other installation frameworks such as Inno Setup or NSIS (Nullsoft Scriptable Install System) are used then sometimes using merge modules (*.msm files) is not an option as it is not supported by the installation framework. In such cases there are 3 ways to go:
How to launch an installation from another installation with no user interaction has been already discussed in chapter Unattended Setups. However when the Impact Acquire installers are embedded into another installation simply running these installers might no always result in only the desired files being installed but also the header files, documentation and other features unwanted on a defined target system.
So only installing the files needed by an application does require to modify one or more of the following properties when launching the Impact Acquire installation:
ADDLOCAL (The value of the ADDLOCAL property is a list of features that are delimited by commas, and are to be installed locally)REMOVE (The value of the REMOVE property is a list of features delimited by commas that are to be removed. These refers to features which are already installed on the target system, thus this property can be used to remove one or more features of a certain package)INSTALLLEVEL (The INSTALLLEVEL property is the initial level at which features are selected "ON" for installation by default)For details refer to the documentation about these properties in the MSDN (http://msdn.microsoft.com).
So one way to go would be to switch off ALL features by setting the INSTALLLEVEL property to 0 and then add all those features needed by the application by providing a list of these features to the ADDLOCAL property:
When e.g. running the mvBlueFOX installer with the following command line
results in the following features being pre-selected:
To obtain the names of the features to be installed any tool that can analyze an MSI-files database can be used. The following screenshot was taken by Orca, which is a tool for authoring MSI files that can be downloaded from Microsoft™ free of charge.
On the other hand to remove one or more features belonging to a known installer on the target system can be accomplished using the REMOVE property. So to e.g. remove the .NET support and the technical manual for mvBlueFOX devices the following command line can be used:
To operate a Balluff imaging or image capture device with the Impact Acquire API some common files are needed for every device on the target system:
As the user mode part of this SDK internally make use of Open MP (http://openmp.org/) on Windows a matching version of the Open MP runtime must be installed on the target system as well. Current versions of the libraries are linked against the Microsoft Visual Studio® 2019 version of the Open MP runtime. The corresponding merge modules or redistributables can be obtained from Microsoft. See here as well: Prerequisites
libexpat.dll is no longer shipped with the installation package, as it is no longer needed by any of the modules belonging to the Impact Acquire interface. This might force you to modify your installer.All these files can be either be copied somewhere in the systems path or into the applications directory.
With these files the device can be used and configured from an application. Some features however require some additional installation work:
In general any version of Windows requires you to install properly signed kernel/device drivers. Unfortunately the signature requirements did change over the years and therefore different Windows version require differently signed drivers. The actual kernel driver is always the same in almost every scenario however the signature attached to the file is NOT and therefore the full file is different. When working with the *.msm-files for the driver installation the merge modules internal logic will detect the version of Windows the installation is running on and will then install the matching version of the device driver. Internally this is achieved by putting EVERY version of the kernel driver into the merge module and then only the correct version gets installed. When not using the merge modules this has to be implemented as well. If just a single version of Windows is targeted the easiest approach is to install the Impact Acquire package on that system and get the related driver files from the full installation. Which files are needed for which device is described further down in this chapter. Right now Impact Acquire usually comes with drivers for the following versions of Windows:
| Windows version | Used Signature |
|---|---|
| Vista, 7, 8, 8.1, 10(smaller than release 1607) and Server 2008 | SHA256 |
| Windows 10 greater or equal version 1607 and Windows 11 | SHA256 EV |
See Windows as well!
In case an application makes use of the mvDisplay.dll library this must be deployed on the target system as well. The same restrictions, path information, etc. as in the previous section apply.
In order to allow the application to load and store settings in the registry these keys must be created during the installation:
HKEY_LOCAL_MACHINE/Software/Balluff/SettingsHKEY_CURRENT_USER/Software/Balluff/SettingsIf the keys are missing settings can still be loaded and stored in the platform independent XML format by using the appropriate functions discussed in the chapters describing the software interface.
If your application shall be able to generate log output the following directory must be created on the target system:
"%PUBLIC%/Documents/Balluff/Impact Acquire/Logs" Apart from that these files must be installed into "%PUBLIC%/Documents/Balluff/Impact Acquire/Logs":
The first file is discussed in detail in the logging chapter of this manual, the latter files are only needed if the standard Balluff Impact Acquire log-file style shall be used(XML with stylesheet transformation). To find out how to embed your own log-file stylesheet please refer to the chapter about the logging mechanism. Here it also explained how to create plain XML log files and XML files that can be viewed using mvLogFileViewer.html.
If your application shall be able to work with camera description files and does NOT modify the property mvIMPACT::acquire::Device::customDataDirectory before initialising the device the following directory must be created on the target system:
"%PUBLIC%/Documents/Balluff/Impact Acquire/CameraFiles" All camera description files that shall be used by the application must be installed into the folder CameraFiles in order to be recognized by the driver.
In case an application makes use of the Impact Acquire .NET interface the corresponding libraries must be deployed on the target system as well. Were and what version of these libraries must be shipped is explained in the Building, Linking And Running Applications Using Impact Acquire chapter of the .NET API manual.
Depending on the used functionalities the following libraries might be necessary:
In case an application makes use of the Impact Acquire .NET Standard interface the corresponding libraries must be deployed on the target system as well. Were and what version of these libraries must be shipped is explained in the Building, Linking And Running Applications Using Impact Acquire chapter of the .NET API manual.
Depending on the used functionalities the following libraries are necessary:
In case an application makes use of the Java to Impact Acquire native interface the mvIMPACT_Acquire.java.dll library must be deployed on the target system as well. The same restrictions, path information, etc. as in the Common Files Needed For All Device Drivers section apply.
Distributing the Impact Acquire Python API requires some additional work as the Python interface has to be compiled for the specific target platform first. The same restrictions, path information, etc. as in the Common Files Needed For All Device Drivers section apply.
Please refer to the to Impact Acquire SDK Python -> Building And Running Applications Using Impact Acquire -> Building -> Windows for more details.
The resulting package will be located at %MVIMPACT_ACQUIRE_DIR%\LanguageBindings\Python\Output. Depending on the Python version which should be used the resulting directory might be named according to the Python version it has been built for:
lib.win32-2.7 for Python 2.7lib.win32-3.7 for Python 3.7The mvVirtualDevice driver as well as the load/save image API of Impact Acquire make use of the FreeImage project.
The load/save video stream API makes use of the FFmpeg project. In order to use these features have a good look at the legal notice section and the video stream related API documentation. All details can be found there.
| Library | 32-bit system - 32-bit library | 32-bit system - 64-bit library | 64-bit system - 32-bit library | 64-bit system - 64-bit library |
|---|---|---|---|---|
| mvDeviceManager.dll | "%windir%\system32" | - | "%windir%\SysWOW64" | "%windir%\system32" |
| mvPropHandling.dll | "%windir%\system32" | - | "%windir%\SysWOW64" | "%windir%\system32" |
| mvDisplay.dll | "%windir%\system32" | - | "%windir%\SysWOW64" | "%windir%\system32" |
| mvGenTLConsumer.dll | "%windir%\system32" | - | "%windir%\SysWOW64" | "%windir%\system32" |
| mvGenTLProducer.cti | "%MVIMPACT_ACQUIRE_DIR%\bin" | - | "%MVIMPACT_ACQUIRE_DIR%\bin" | "%MVIMPACT_ACQUIRE_DIR%\bin\x64" |
| mvGenTLProducer.PCIe.cti | - | - | - | "%MVIMPACT_ACQUIRE_DIR%\bin\x64" |
| BVS_CA-BN.[some letter].[0-3].dll | - | - | - | "%windir%\system32" |
| mvIMPACT_Acquire.jar | "%MVIMPACT_ACQUIRE_DIR%\bin" | - | "%MVIMPACT_ACQUIRE_DIR%\bin" | "%MVIMPACT_ACQUIRE_DIR%\bin\x64" |
| mv.impact.acquire.dll (.NET) | "%MVIMPACT_ACQUIRE_DIR%\bin\.NET" | |||
| mv.impact.acquire.display.dll (.NET) | "%MVIMPACT_ACQUIRE_DIR%\bin\.NET" | |||
| mv.impact.acquire.display.extensions.dll (.NET) | "%MVIMPACT_ACQUIRE_DIR%\bin\.NET" | |||
| mv.impact.acquire.examples.helper.dll (.NET) | "%MVIMPACT_ACQUIRE_DIR%\bin\.NET" | |||
| mv.impact.acquire.dll (.NET Standard) | "%MVIMPACT_ACQUIRE_DIR%\bin\netstandard2.0" | |||
| mv.impact.acquire.display.dll (.NET Standard) | "%MVIMPACT_ACQUIRE_DIR%\bin\netstandard2.0" | |||
| mv.impact.acquire.display.extensions.dll (.NET Standard) | "%MVIMPACT_ACQUIRE_DIR%\bin\netstandard2.0" | |||
| mv.impact.acquire.examples.helper.dll (.NET Standard) | "%MVIMPACT_ACQUIRE_DIR%\bin\netstandard2.0" | |||
| mvIMPACT_Acquire.java.dll | "%MVIMPACT_ACQUIRE_DIR%\bin" | - | "%MVIMPACT_ACQUIRE_DIR%\bin" | "%MVIMPACT_ACQUIRE_DIR%\bin\x64" |
| mvBlueFOX.dll | "%windir%\system32" | - | "%windir%\SysWOW64" | "%windir%\system32" |
| mvVirtualDevice.dll | "%windir%\system32" | - | "%windir%\SysWOW64" | "%windir%\system32" |
| mvBlueFOX.dll | "%windir%\system32" | - | "%windir%\SysWOW64" | "%windir%\system32" |
| mvVirtualDevice.dll | "%windir%\system32" | - | "%windir%\SysWOW64" | "%windir%\system32" |
For all GenICam based devices the following files will be necessary:
In case of mvUSB3Vision or GigE Vision™ devices:
In case of BVS CA-BN (mvBlueNAOS) devices:
mvGenTLProducer.PCIe.cti resides in.If the GigE Vision™ capture filter kernel mode driver shall be used the following files must be shipped as well:
For 32-bit support:
For 64-bit support:
mvGigECapture.sys that is installed on the target system will differ from Windows version to Windows version. Currently Windows 2000 will need a different version of this file than newer versions of Windows. To obtain the correct file needed for the target platform the original installer must be installed on the system in question. Thus to build an installer for Windows 2000 the *.sys-file must be obtained from a Windows 2000 system. When working with the merge modules this will be done automatically.If the GigE Vision™ capture filter kernel mode driver shall be used the following files must be shipped as well:
For 32-bit support:
For 64-bit support:
To actually install the filter driver on the system there are 3 ways to go: Either the tool GigEConfigure or the built-in mechanism of Windows to install a filter driver can be used.
Using GigEConfigure there are 2 possibilities:
Using the built-in mechanism of Windows works like this:
First navigate to any of the network connections available to the system and open the properties dialog of that connection.
Here click on Install...
In the next Windows select Service and click on Add....
Now click on Have Disk....
Click on Browse... and navigate to the folder containing the GigE Vision™ capture filter kernel mode driver files mentioned above.
Select the file mvGigECapture.inf and click on Open
Click on OK
Afterwards the filter driver will installed and active on EVERY network connection of the system. If that is not desired, it can be enable and disabled from the properties dialog of the network connection that shall be modified by checking or unchecking the box in from of the Balluff Impact Acquire filter driver entry.
The third approach is a possibility provided by the functionality of the mvGenTLProducer.cti which allows to install the filter driver using the Impact Acquire API. At first there are some values which have to be written to the Registry of Windows to specify the GigE Vision™ support and the path to the GigE Vision™ filter driver which shall be installed
The entry HKEY_LOCAL_MACHINE/SOFTWARE/Balluff/Settings has to be generated and afterwards the keys from the following table have to be created.
| Name | Type | Value |
|---|---|---|
GEV_SUPPORT | DWORD | 1 |
GEV_DRIVER_SOURCE_PATH | String | MVIMPACT_ACQUIRE_DIR%\KernelDrivers\mvGigECaptureDriver(x64)(SHA256.EV)\mvGigECapture2.inf |
GEV_DRIVER_SOURCE_PATH might differ depending on the source of the kernel driver files. See General Considerations When Shipping Kernel Drivers as well. Afterwards some small application needs to load the required TLIMV_InstallDriverFromRegistry function from mvGenTLProducer.cti. The following code shows how this would work:HKEY_LOCAL_MACHINE entries, the application utilizing this functionality needs to be called with administrator permissions. Of course this cannot only be done using a C/C++ application as shown here but also by any other mechanism that can write to the Registry and can call a DLL function that doesn't require parameters. So this can also be done from within a WiX installation package or some C# application for example.For USB3 Vision™ device support the following files correctly signed for the target platform must be shipped as well:
For 32-bit support:
For 64-bit support:
Experienced users are encouraged to use the Microsoft Driver install Framework for applications to deploy this driver on the target system (http://msdn.microsoft.com/en-us/library/ms790295.aspx). This is the recommended way for installing device drivers.
For mvBlueNAOS device support the following files correctly signed for the target platform must be shipped as well:
For 32-bit support:
For 64-bit support:
Experienced users are encouraged to use the Microsoft Driver install Framework for applications to deploy this driver on the target system (http://msdn.microsoft.com/en-us/library/ms790295.aspx). This is the recommended way for installing device drivers.
Apart from that, the GenICam runtime this driver has been linked with must be installed on the target system. The runtime modules are contained in the merge modules belonging to this driver package.
The driver will try to locate the GenICam runtime in %MVIMPACT_ACQUIRE_DIR%/Toolkits/GenICam_v<major>_<minor> thus if you plan to distribute the runtime in a different way you need to setup you environment accordingly as described by the GenICam standard.
The files belonging to the kernel driver correctly signed for the target platform:
amvBlueFOX2.inf is NOT a mistake. The reason for this strange file name is that Windows 2000 by default uses the first *.inf-file in an alphabetical search that matches the detected device. As previous versions of this driver package contained 2 versions of the kernel driver, the 'older' versions *.INF-files name was mvBlueFOX.inf and in order to install the newer version of the kernel driver as a default driver the new *.inf-file must be found before the old one as Windows does not list all available drivers but only the first one detected.The kernel driver files should be installed BEFORE connecting the device to the target system the first time as then Windows automatically detects the driver.
*.cat files can't just be copied into some system specific directory. Please refer to the corresponding documentation by Microsoft.
In addition to this a Windows driver framework co-installer is needed. This file must be copied into the Windows system (system32) folder. Both the 32-bit and the 64-bit version of the driver need 'WdfCoinstaller01009.dll' for the driver installation. If the co-installer is not present on the target system they must be copied as well.
Experienced users are encouraged to use the Microsoft Driver install Framework for applications to deploy this driver on the target system (http://msdn.microsoft.com/en-us/library/ms790295.aspx). This is the recommended way for installing device drivers.
These files alone will correctly install the mvBlueFOX as a recognized device on the target system. However to access the device from any kind of application the base libraries for the Impact Acquire interface will be needed as well.
mvVirtualDevice is able to connect to the FreeImage library for loading JPEG, PNG and TIFF images from hard disk. See FreeImage Support for details. The driver will try to load the FreeImage libraries from %MVIMPACT_ACQUIRE_DIR%/Toolkits//FreeImage3160/bin/Release/FreeImage/<platform> so this is where the library needs to be to make this work.
When not re-distributing the original Impact Acquire installation packages an application might need certain environment variables in order to run properly. As not every possible setup needs any of the variables described here, they will not be created by default, but must be added as needed to a custom client installer. This chapter briefly explains all environment variables that are important when deploying a Impact Acquire based application.
The MVIMPACT_ACQUIRE_DIR variable is needed by some applications in order to locate certain files. E.g. GigEConfigure will use this variable to locate the GigE Vision™ capture driver when the tool is used to install the driver. Also the mvDeviceManager library needs it in order to set up some process local environment variables relative to it. Thus without this variable GenICam compliant devices (mvBlueCOUGAR, mvBlueFOX3) cannot be operated. The variable must point to the root folder of the Impact Acquire related modules.
The MVIMPACT_ACQUIRE_DATA_DIR variable is needed in order to setup the cache path for GenICam XML files. The folder pointed to should provide read AND write access for the user. The required folder structure below this folder should look like this:
MVIMPACT_ACQUIRE_DATA_DIR
|- GenICam <-- Here pre-processed GenICam files will be stored by the runtime. This will speed up initialisation time of devices
The GENICAM_GENTL32_PATH variable is needed for reasons described in the GenICam GenTL specification (see GenICam downloads on the EMVA homepage (http://www.emva.org) to get a copy of the latest version OR use the one provided together with the installation archive you have installed the driver on your development system from). An application should always check whether this variable already exists as other applications might register it as well. Therefore every application shall only APPEND data to existing variables and shall only remove the part that was added without necessarily deleting the full variable. The variable shall contain the path to the folder containing 32-bit versions of *.cti (see above) files (typically located in the bin folder of the folder pointed to by MVIMPACT_ACQUIRE_DIR.
The GENICAM_GENTL64_PATH variable is needed for the very same reasons as the GENICAM_GENTL32_PATH variable when working with 64-bit applications and has the same requirements.
For Linux most of the stuff mentioned in Non-MSI Based Setup Routines applies as well even though instead of *.dll files the corresponding *.so files have to be deployed on the target machine. Apart from that everything related to kernel drivers usually doesn't apply here with the exception of BVS CA-BN (mvBlueNAOS) device drivers which come with their own kernel driver. If for any reason the original installation packages shall not be used the corresponding install scripts coming with that packages can be used to reverse engineer what needs to be done. As stated previously this the NOT recommended!
For installation on a Linux-i686 system the files with the -i86 suffix must be extracted. On a Linux-x64_86 system the corresponding packages with the -x64.tgz suffix must be used.
These variables must be added to the environment, e.g. by placing these lines in the .profile or .bashrc file.
In case you are developing applications using the GenICam SDK add the GenICam include path to your pre-processor options, e.g:
Finally
must somehow end up in the systems library search path thus you might want to add a file to
containing the following line:
OR you can use a different mechanism.
The Impact Acquire runtime libraries (*.so) from the installation archive for your target machine (*.tgz) are sufficient for including the Impact Acquire driver into your own embedded Linux distribution. The following chapter will demonstrate how to achieve this via the Yocto Project.
The Yocto Project is an open-source framework that helps users to create a custom Linux distribution. To use Balluff imaging devices on your embedded system, you will need to create Bitbake recipes to package the Impact Acquire libraries which are already compiled by us for your target system, create Bitbake recipes to cross-compile and package your machine vision applications using the Impact Acquire API, and install these packages into your own Linux image. In this example, we will guide you through:
The Yocto Project uses a layer module (i.e. meta-layers) to logically modulate and separate metadata in a build. Therefore, it's a good pratice to create a meta-layer for the Impact Acquire driver packages and programs on top of your Linux distribution or on top of a BSP (Board Support Package) provided by your hardware manufacturer. Once the Yocto build environment and the base Linux distribution have been set, create a meta-layer in the source directory:
Once the Impact Acquire meta-layer has been created, open the conf/bblayers.conf file in the build directory and add the following line:
Now it's time to install the Impact Acquire common runtime libraries and device-specific runtime libraries.
There are some libraries that are needed by every Impact Acquire driver:
Therefore, if multiple device drivers are going to be installed on the target machine, it's better to install these common libraries by a separate Bitbake recipe.
Since these runtime libraries are shipped in both the GenICam GenTL specific and the mvBlueFOX specific mvIMAPCT Acquire installation archives, you first need to download the latest *.tgz archive for your target machine from the Balluff website (https://www.balluff.com/en-de/downloads/software). In this demonstration, the mvGenTL_Acquire-ARM64_gnu-3.0.0.tgz for an arm64 platform will be used.
Once the installation archive has been downloaded, navigate to the source directory, copy the *.tgz file to the recipe directory and create a Bitbake recipe for installing the common runtime libraries:
The demo Bitbake recipe mvimpact-acquire-base_3.0.0 looks like this:
md5sum [file_name] to check the current MD5 checksum of the file and update it in your recipe.After the recipe has been created, run bitbake to build it:
The Impact Acquire PCIe kernel module is needed in order to use BVS CA-BN (mvBlueNAOS) devices. Before compiling the out-of-tree kernel module, run the configuration of the virtual kernel from the build directory to create a workspace directory containing the kernel source:
The source code of Impact Acquire PCIe kernel module is provided by the mvGenTL installation archive (version >= 2.44.0), therefore you first need to download the mvGenTL_Acquire-ARM64_gnu-3.0.0.tgz from the Balluff website (https://www.balluff.com/en-de/downloads/software). Assume the target platform is arm64. Skip this step if the same *.tgz has been downloaded during the previous step Install Common Impact Acquire Libraries.
Now navigate to the source directory and create a Bitbake recipe for installing the Impact Acquire kernel module:
The demo Bitbake recipe mvpci-mod_3.0.0 looks like this:
md5sum [file_name] to check the current MD5 checksum of the file and update it in your recipe.After the recipe has been created, run bitbake to build it:
Apart from the common Impact Acquire runtime libraries, you need to install the GenICam GenTL specific libraries from the mvGenTL installation archive in order to use USB3 Vision™ devices, GigE Vision™ devices or BVS CA-BN (mvBlueNAOS) devices. Therefore, download the mvGenTL_Acquire-ARM64_gnu-3.0.0.tgz from the Balluff website (https://www.balluff.com/en-de/downloads/software). Assume the target platform is arm64. Skip this step if the same *.tgz has been downloaded during the previous step Install Common Impact Acquire Libraries.
Create a Bitbake recipe for installing GenICam GenTL specific Impact Acquire libraries:
The demo Bitbake recipe mvimpact-acquire-gentl_3.0.0 looks like this:
md5sum [file_name] to check the current MD5 checksum of the file and update it in your recipe.After the recipe has been created, run bitbake to build it:
Apart from the common Impact Acquire runtime libraries, you need to install the mvBlueFOX specific libraries from the mvBlueFOX installation archive in order to use mvBlueFOX devices. Therefore, download the mvBlueFOX-ARM64_gnu-3.0.0.tgz from the Balluff website (https://www.balluff.com/en-de/downloads/software). Assume the target platform is arm64. Skip this step if the same *.tgz has been downloaded during the previous step Install Common Impact Acquire Libraries.
Create a Bitbake recipe for installing mvBlueFOX specific Impact Acquire libraries:
The demo Bitbake recipe mvimpact-acquire-mvbluefox_3.0.0 looks like this:
md5sum [file_name] to check the current MD5 checksum of the file and update it in your recipe.After the recipe has been created, run bitbake to build it:
Apart from the common Impact Acquire runtime libraries, you need to install the mvVirtualDevice specific libraries from either the mvGenTL or the mvBlueFOX installation archive in order to use mvVirtualDevice. In this example, the mvGenTL_Acquire-ARM64_gnu-3.0.0.tgz will be downloaded and used. Assume the target platform is arm64. Skip this step if the same *.tgz has been downloaded during the previous step Install Common Impact Acquire Libraries or Install GenICam GenTL Specific Impact Acquire Libraries.
Create a Bitbake recipe for installing mvVirtualDevice specific Impact Acquire libraries:
The demo Bitbake recipe mvimpact-acquire-virtualdevice_3.0.0 looks like this:
md5sum [file_name] to check the current MD5 checksum of the file and update it in your recipe.After the recipe has been created, run bitbake to build it:
After the required Impact Acquire library packages have been successfully built, we can then use Bitbake to cross-compile programs with the Impact Acquire API. Since mvIMAPCT Acquire installation archieves already provide sample programs with CMake files and Bitbake supports CMake, we can use CMake to cross-compile these programs.
First, create a Bitbake recipe for cross-compiling the sample programs:
In this demo recipe we will use mvGenTL_Acquire-ARM64_gnu-3.0.0.tgz as the source file (you can also use mvBlueFOX-ARM64_gnu-3.0.0.tgz if needed). All source code is located under mvGenTL_Acquire-ARM64_gnu-3.0.0.tgz/mvIMPACT_Acquire-ARM64-3.0.0/apps.
Here is how the demo recipe mvimpact-acquire-examples_3.0.0.bb looks like:
md5sum [file_name] to check the current MD5 checksum of the file and update it in your recipe.After the recipe has been created, run bitbake to build it:
CMAKE_FIND_ROOT_PATH_MODE_INCLUDE variable to BOTH in the cmake.bbclass file.Before building the custom Linux image with the Impact Acquire API, we need to install the successfully built Impact Acquire packages to the custom Linux image. In the following demonstration, all packages from above will be installed. You can also just install the ones that you need.
After that, bitbake the image to build it for your target system.
Impact Acquire is available as a dmg (Apple disk image) for macOS 12 (Monterey) on ARM architectures like the Mac mini. This disk image contains files for working with Balluff GigEVision™ devices, but does not contain a full installer. These files can be used if you also have a file-based installation.
Files below the following folders might be interesting for deployment
lib runtime Contents of the following folders might only be interesting if packaging with parts of our provided software:
apps bin CMake common doc DriverBase FirmwareUpdates mvDeviceManager mvIMPACT_CPP mvPropHandling Toolkits For the libraries, libexpat is necessary which is available on homebrew. Additionally, for using the GUI-based tools, wxWidgets 3.x might have to be installed.
For using mvGenTL_Acquire within your software, you may already have set the install path of the used Impact Acquire libraries. This is also necessary on the target system, so you may have to adapt your installation scripts.
To improve performance, some system parameters may have to be adapted on the target system. For some of them, you may need to have administrator privileges.
sysctl, some more optimizations could be made: 