Table of Contents
Windows
System requirements
Currently supported Windows versions are:
- Microsoft Windows 7 (32-bit, 64-bit)
- Microsoft Windows 8.1 (32-bit, 64-bit)
- Microsoft Windows 10 (32-bit, 64-bit)
- Microsoft Windows 11
Other Windows version can be used at the user's own risk.
All necessary drivers for Windows are contained in the "mvSDK for intelligent cameras" DVD. For newer driver versions we recommend to visit the MATRIX VISION website at www.matrix-vision.de, section "Products -> Cameras -> your interface -> your product -> Downloads".
Hardware
MATRIX VISION successfully tested several network interface cards, which are summarized in the following document: http://www.matrix-vision.com/tl_files/mv11/support/Manuals/mvBlueCOUGAR-X_-_Recommended_NICs_en.pdf.
Additional hardware requirements for mvBlueCOUGAR-XD
The mvBlueCOUGAR-XD is a high-performance camera containing latest top-notch technology which requires
- a high data throughput on the host system,
for example, when processing large amount of image data and
- high CPU resources if processing color images on the host PC.
This means that you will need
- the latest PC architectures, preferably multi core Intel CPUs and chipsets
- sufficient RAM (4 GB in 32-bit OS; 8 GB in 64-bit OS), and
- appropriate and recommended network cards with PCI-E x1 or x4 interface and with the latest "Link Aggregate Group" (LAG) capable drivers.
Please ask your system vendor for further advice and consult our technical documentation.
Beside the host system requirements, you have to fine-tune
- the network settings,
- the camera settings, and
- the host system settings (e.g. disabling the sleep mode)
to achieve the specified frame rates possible from the camera's perspective.
Installing the mvGenTL-Acquire driver
By double clicking on
- mvGenTL_Acquire-x86-n.n.n.msi (for 32-bit systems) or
- mvGenTL_Acquire-x86_64-n.n.n.msi (for 64-bit systems), the installer will start automatically:
- Now, follow the instructions of installation program and use default settings:
- Since
- mvIMPACT Acquire 2.25.0
wxPropView is able to check if there are new driver version available on a weekly basis. Deactivate the check box if wxPropView should not check for updates. You can activate the checking in wxPropView via the help menu.
- After confirmation, the installation will start and copy the data. At the end, MATRIX VISION's GigE Vision capture filter driver will be installed. A "Windows Security" dialog will appear.
- Click on Install (This however requires the system to be rebooted, thus the installer will ask the user to reboot the system.).
- After the system has been restarted, the filter driver installation will start automatically. Click "Ok".
- Afterwards, please ignore the compatibility testing of Windows and click on "Continue anyway" twice.
- After the installation of the GigE Vision capture filter driver you will see following dialog. Click "Ok".
- Now, the driver installation will be finished.
You will find all tools like
either on desktop as single icons or in Windows menu under "MATRIX VISION -> mvIMPACT Acquire".
During installation, you can select the features you want to install. It is also possible to select "Firmware updates": In this case, the installer will copy the update file "mvBlueCOUGAR_Update.tgz" into the MATRIX VISION driver installation directory:
[Path: e.g. C:\Program Files\]MATRIX VISION\mvIMPACT acquire\FirmwareUpdates\mvBlueCOUGAR\
Afterwards, you can use mvDeviceConfigure to update the firmware. The latest firmware image is available on the web - please check for updates. The current firmware version can be read out using wxPropView (Device section on top) or via "cat /etc/FIRMWARE" when working locally.
Optimizing the network configuration
This chapter explains, how to achieve optimal performance by setting up the NIC (network interface card) and the devices network controller in the best possible way with respect to the limitations imposed by the surrounding network. To check, if the camera is available via the network, you can use the tool mvIPConfigure.
- Attention
- Only network experts should change settings in this section.
In the system settings of the camera, you can set up the overall network behaviour of the device in the "Transport Layer Control" section e.g. by assigning a persistent IP address, a persistent default gateway and a persistent subnet mask in "Transport Layer Control" section according to your needs. However IP configuration related settings should be done by using the tool mvIPConfigure as this will provide a more convenient access to these parameters.
Network performance related parameters however can be controlled from the "Driver -> GenTL" section as well:
By default 1500 is used as MTU ("Driver -> GenTL -> Interfaces -> Interface0 -> mv Gev Interface MTU"). You can change this according to your network. As a general rule of thumb it can be said, that the higher the MTU, the better the overall performance, as less network packets are needed to transmit a full image, which results in less overhead that arises from the handling of each arriving network packet in the device driver etc. However every component involved in the data transmission (that includes every switch, router and other network component, that is installed in between the device and the system receiving the packets) must support the MTU or packet size, as otherwise the first component not supporting the packet size will silently discard all packets, that are larger than the component can handle.
40 The mvBlueLYNX-M7 supports a maximum MTU of 9K.
- Note
- If you modify the interface MTU of the device, it will take up to 5 seconds until these settings are saved in the non-volatile memory. During this time do not remove the power supply! Afterwards you have to reboot the device for the changed settings to take effect.
Adjusting the network controller
If you have interplay problems between mvBlueCOUGARand a network controller (NIC) please check following settings in the driver settings:
- Note
- There is no need to set the transfer packet size manually. Whenever the device is initialised, the driver will determine the maximum possible packet size for the current network settings automatically.
- The screenshots below are examples for how a dialog for a feature described here might look like. Not every NIC/NIC driver will support every feature discussed here and different drivers might use different names for the features presented. The hints are just meant to give an idea for what to look for.
- Is the NIC a "1000MBit Full Duplex Controller" and is this mode activated (via properties of network settings)?
-
Is the driver of the NIC up-to-date?
Some manufacturers have optimized their drivers referring to higher data throughput. - Is the "GigE Vision Capture driver" installed as described in Install GigE Vision capture filter ?
-
Does the MTU of the NIC correspond the setting of the mvBlueLYNX-M7 (default 1500) ?
Using a peer-to-peer connection leads to a better performance and normally you can use values higher than 1500. Here, values between 4k and 12k make sense, whereas some network controllers only allow maximum of 9k which is enough for sensors up to 4 megapixels.
Figure 9: Setting "Jumbo Packet" using an Intel PRO/1000 network interface
-
Is the NIC parameter "Interrupt Moderation" switched on?
Figure 10: Setting "Interrupt Moderation" using an Intel PRO/1000 network interface
-
Some multi-port network cards might also offer to configure the number of "RSS (Receive Side Scaling) Queues". When dealing with high data rates, increasing the number of queues might also improve the overall stability of the system in terms of the possibility of packet losses etc.
Figure 11: Setting "RSS Queues" using an Intel Ethernet Adapter I340-T4
-
Is the amount of the "Receive Descriptors" (RxDesc) of the NIC set to the maximum (generally 2048)?
This amount depends on the MTU. You can get a feeling about values with following formula:- Note
- The formula is per camera and per network port.
RxDesc >= 1.1 * PixelPerImg * BytesPerPixel --------------------------------- MTU"Example 1: 1500 at 1.3MPixel"
RxDesc >= 1.1 * 1.3M * 1 -------------- 1500 >= 950"Example 2: 8k at 1.3MPixel"
RxDesc >= 1.1 * 1.3M * 1 -------------- 8192 >= 175- Note
Both examples are showing the RxDesc values based on packages per image per second. Now, if you increase the images per second you will see that you reach the amount of "Receive Descriptors" very soon. Usually, the default values of the system are between 64 and 256 and as a general rule too low. Also each use of a "Receive Descriptor" will result in a certain amount of CPU time needed, which is why larger packets result in a better overall performance.
If you are using small MTU values or if there is only a small value of "Receive Descriptors" possible, you have to enable "Interrupt Throttling". Interrupt throttling enables the NIC to combine packets thus lowering the amount of interrupts.
The "Receive Descriptors" a.k.a. "Receive Buffers" (Intel PRO/1000 network interface) can be found under "Performance Options":
Figure 12: "Performance Options"
40
Figure 13: Setting "Receive Buffers"
Linux
System requirements
- Kernel 2.6.x .. Kernel 4.x.x.
- Note
- The Linux driver is compliant to x86, x86_64, ARMv7(soft- and hardfloat) and ARMv8 (AArch64) based systems.
A summary with the recommended network interface cards is available for downloading: http://www.matrix-vision.com/tl_files/mv11/support/Manuals/mvBlueCOUGAR-X_-_Recommended_NICs_en.pdf
- Note
- For more information about Linux Shell commands, please have a look at: List of the most important shell commands.
Before installation of GigE environment on a Linux system (e.g. Ubuntu 8.04 or SuSE 10.3), the system has to provide at least following packages:
- libwxbase3.0-0
- libwxbase3.0-dev
- libwxgtk3.0-0
- libwxgtk3.0-dev
- wx3.0-headers
- build-essential (meta package)
- libgtk2.0-dev
- gcc 4.1 environment or newer
Additional hardware requirements for mvBlueCOUGAR-XD
The mvBlueCOUGAR-XD is a high-performance camera containing latest top-notch technology which requires
- a high data throughput on the host system,
for example, when processing large amount of image data and
- high CPU resources if processing color images on the host PC.
This means that you will need
- the latest PC architectures, preferably multi core Intel CPUs and chipsets
- sufficient RAM (4 GB in 32-bit OS; 8 GB in 64-bit OS), and
- appropriate and recommended network cards with PCI-E x1 or x4 interface and with the latest "Link Aggregate Group" (LAG) capable drivers.
Please ask your system vendor for further advice and consult our technical documentation.
Beside the host system requirements, you have to fine-tune
- the network settings,
- the camera settings, and
- the host system settings (e.g. disabling the sleep mode)
to achieve the specified frame rates possible from the camera's perspective.
Installing the mvGenTL-Acquire driver
Please follow these steps:
- Insert standard mvIMPACT CD-ROM or DVD-ROM (at least CD2008B) into host PC's CD drive.
- Change into the directory ".../mvimpactacquire/Driver/" and
- Copy mvGenTL_Acquire-x86-n.n.n.zip to your system and
-
Unpack the archive.
After unpacking, you will get two files: "install_mvGenTL_Acquire.sh" and "mvGenTL_Acquire-x86-n.n.n.tgz" -
Copy both files to a local directory (e.g.
"/home/..."). - Open a Shell change to root user and
-
Start installer script: e.g.:
sudo ./install_mvGenTL_Acquire.sh
Now, all necessary files are copied.
After some seconds you will be asked, if tools and samples should be built:Do you want the tools and samples to be built (default is 'yes')?
-
Type in
'yes'.
Only source and development files are copied and you would have to build the tools (including mvDeviceConfigure and wxPropView) later manually.
Now, the installer script will try to build all tools, drivers and samples. Depending on processing power of host PC this can take a while. If no errors are reported, the host PC is ready to work with the camera.
All needed files are now available in user's home directory under mvimpact-acquire:
mvimpact-acquire Tools and samples can be found under apps.
To see if a device is accessible from a host system change to the subdirectory "~/mvimpact-acquire/apps/mvDeviceConfigure/x86". An executable mvDeviceConfigure should reside in this folder. You can start this as a standard user or as root.
For setting up camera tool wxPropView is useful. You can find it in subdirectory "~/mvimpact-acquire/apps/mvPropView/x86". wxPropView can also be started as simple user, but we suggest to use root used with this program for a better performance. wxPropView can display only one sensor of the two at the same time. There's one special demo program for demonstrating how to capture from both sensors simultaneously. This demo is called SynchronousCaptureMultipleInputsFLTK.
It can be that this sample wasn't build automatically while installation because the following libraries are not installed on the current system. Be sure to have these libraries installed:
- libfltk
- libfltk-dev
- openGL development files
Now you can build demo program with "make x86" in directory "~/mvimpact-acquire/apps/SynchronousCaptureMultipleInputsFLTK".
- Note
- For more information about Linux Shell commands, please have a look at: List of the most important shell commands.
To use the mvBlueCOUGAR camera (grab images from it and change its settings), a driver is needed, consisting of a few libraries and a dozen or so configuration files. These files are run time required.
To develop applications that can use the mvBlueCOUGAR camera, a source tree is needed, containing header files, makefiles, samples, and a few libraries. These files are compile time required.
Both file collections are distributed in a single package:
mvGenTL_Acquire-x86-n.n.n.tgz
The package can also be found on the "mvSDK for intelligent cameras" DVD \drv\Linux. If you want to (re-)install driver, you have to do following steps:
- Note
- These installation guide is only valid in the VMware and has to be adapted for installations outside VMware.
- Please start the mvBlueCOUGAR-SDK development environment.
-
After booting of the VMware, please insert the "mvSDK for intelligent cameras" DVD.
The dialog "A new medium has been detected" appears. -
Please confirm with "Ok" ("Open in New Window").
A Dolphin dialog appears. - Please close this window.
-
Please start a console and change into the directory
workspace
mvbc@mvSDK: cd /home/mvbc/workspace
-
Unpack the driver archive from the DVD:
mvbc@mvSDK:~/workspace$ tar -xvzf /media/cdrom/drv/Linux/mvIMPACT_ppc_6xx_Linux.tar.gz
-
Copy the install script and the hardware driver to the workspace:
mvbc@mvSDK:~/workspace$ cp /media/cdrom/drv/Linux/install_mvBlueCOUGAR.sh . && cp /media/cdrom/drv/Linux/mvGenTL_Acquire-x86-2.3.2.tgz -t ./
-
Run the install script:
mvbc@mvSDK:~/workspace$ ./install_mvGenTL_Acquire.sh
- Note
- During installation, the script will ask, if it should build all tools and samples.
You may need to enable the execute flag with
chmod a+x install_mvGenTL_Acquire.sh.
The installation script checks the different packages and installs them with the respective standard packages manager (apt-get, yast) if necessary.
- Note
- The installation script (
"install_mvGenTL_Acquire.sh") and the archive (mvGenTL_Acquire-x86-n.n.n.tgz") must reside in the same directory. Nothing is written to this directory during script execution, so no write access to the directory is needed in order to execute the script.
You need Internet access in case one or more of the packages on which the GenICam™ libs depend are not yet installed on your system. In this case, the script will install these packages, and for that, Internet access is required.
The script takes two arguments, both of which are optional:
- target directory name
- version
The target directory name specifies where to place the driver. 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 "/.".
- Note
- This directory is only used for the files that are required at
runtime.
The files required at compile time are always installed in $HOME/mvimpact-acquire-n.n.n. The script also creates a convenient softlink to this directory:
mvimpact-acquire -> mvIMPACT_acquire-2.3.2
If this argument is not specified, or is ".", the driver will be placed in the current working directory.
The version argument is entirely optional. If no version is specified, the most recent mvGenTL_Acquire-x86-n.n.n.tgz found in the current directory will be installed
For more information and if you want to install only the mvBlueCOUGAR remote driver on Linux. Please have a look at Installing the mvBlueCOUGAR Remote Driver.
Optimizing the network configuration
This chapter explains, how to achieve optimal performance by setting up the NIC (network interface card) and the devices network controller in the best possible way with respect to the limitations imposed by the surrounding network. To check, if the camera is available via the network, you can use the tool mvIPConfigure.
- Attention
- Only network experts should change settings in this section.
In the system settings of the camera, you can set up the overall network behaviour of the device in the "TransportLayer" section e.g. by assigning a persistent IP address, a persistent default gateway and a persistent subnet mask in "TransportLayer" section according to your needs. However IP configuration related settings should be done by using the tool mvIPConfigure as this will provide a more convenient access to these parameters.
Network performance related parameters however can be controlled from the "TransportLayer" section as well:
By default 1500 is used as MTU ("DeviceInterfaceMTU"). You can change this according to your network. As a general rule of thumb it can be said, that the higher the MTU, the better the overall performance, as less network packets are needed to transmit a full image, which results in less overhead that arises from the handling of each arriving network packet in the device driver etc. However every component involved in the data transmission (that includes every switch, router and other network component, that is installed in between the device and the system receiving the packets) must support the MTU or packet size, as otherwise the first component not supporting the packet size will silently discard all packets, that are larger than the component can handle.
The mvBlueLYNX-M7 supports a maximum MTU of 9K.
- Note
- If you modify the interface MTU of the device, it will take up to 5 seconds until these settings are saved in the non-volatile memory. During this time do not remove the power supply! Afterwards you have to reboot the device for the changed settings to take effect.
Adjusting the network controller
If you have interplay problems between mvBlueCOUGARand a network controller (NIC) please check following settings in the driver settings:
- Note
- There is no need to set the transfer packet size manually. Whenever the device is initialised, the driver will determine the maximum possible packet size for the current network settings automatically.
-
Is the amount of the "Receive Buffers" of the NIC set to the maximum? If you want to set the "Receive Buffers", you have to
-
create a new file 62-buffers-performance.conf in
"/etc/sysctl.d/"(/etc/sysctl.d/62-buffers-performance.conf) and -
add the following lines to this file:
net.core.wmem_max=16777216 net.core.wmem_max=16777216 net.core.rmem_max=16777216 net.core.udp_mem=10240 87380 16777216 net.core.netdev_max_backlog=10000
-
Afterwards, reboot the system or enter
"sudo sysctl -p".
- See also
- For more information about Linux network tuning, please have a look at http://www.cyberciti.biz/faq/linux-tcp-tuning/.
-
create a new file 62-buffers-performance.conf in
Connecting the camera
To start the device please accomplish following steps:
-
Connect the mvBlueLYNX-M7
There are three different ways to connect the camera to a host PC:
- Direct connection (peer-to-peer)
- Direct connection (over switch)
- Connection over intranet
For alternative 1 there is no special peer-to-peer cable necessary. The network controller recognizes the used cable alternative. Please check if you are using at least a Standard CAT5 e cable.
Depending on the configuration of the network or the mvBlueLYNX-M7, following IP addresses are assigned:
- If the mvBlueLYNX-M7 is configured to use a static IP address, the mvBlueLYNX-M7 will use this one. The IP addresses have to be in the same subgroup. E.g., host PC: 192.168.0.1 and camera 192.168.0.10.
- With DHCP, the mvBlueLYNX-M7 will get an IP address from the DHCP server (default setting of mvBlueLYNX-M7).
- Without DHCP, the mvBlueLYNX-M7 will start with a logical link address (LLA) / zero configuration class B IP address ("169.254.X.X", netmask 255.255.0.0).
- Note
- The zero configuration needs some time until the IP addresses are assigned (up to 1 minute).
- Please have a look at LLA in the Glossary when using Linux and LLA.
- Note
- If you want to netboot the mvBlueLYNX-M7, please have a look at DHCP and netboot information.
You can change settings like the static IP address to your needs (please have a look at: mvIPConfigure).
- See also
- \ŗef mvBC_subsection_quickstart_device_setting
-
Power the mvBlueLYNX-M7
with power cable KSM7 Power to a suitable power supply, which provides 12 up to 48V DC.
Camera will start booting immediately (see Connecting the camera).
Communicating with the camera
There are three ways to connect to the camera:
-
Via wxPropView :
Since driver version 2.11.3, starting wxPropView the first time, the Quick Setup Wizard , a tiny and powerful configuration tool, will be started.
If Quick Setup Wizard was disabled, wxPropView will start without wizard and you will see the serial number of the mvBlueLYNX-M7in the box "Serial No". After clicking "Use" the program connects to the mvBlueLYNX-M7. With "Acquire" you can see live images from the camera.- Note
- The current IP address can be found in the "Device" properties under "DeviceIPAddress".
-
Via SSH :
To connect to the camera via SSH, you need the IP address. You can get the IP address as described in 1. using wxPropView or mvIPConfigure (which is faster). Open your SSH client like PuTTY (on Windows systems, otherwise start a Shell window) and connect to the camera like this (if IP address is 169.254.67.186; user: root using "root" as password):mvbl@mvBlueLYNX-M7-TEST:~$ ssh root@192.168.1.153
You will see something like this:
The authenticity of host '192.168.1.153 (192.168.1.153)' can't be established. RSA key fingerprint is ba:ad:7e:bf:c9:91:f2:1b:86:d8:55:23:b1:1e:54:ad. Are you sure you want to continue connecting (yes/no)? yes Warning: Permanently added '192.168.1.153' (RSA) to the list of known hosts. \ ********************** MATRIX Vision mvBL-M7 \ ********************** root@192.168.1.153's password: mvBL-M7>
-
Via RS232 interface:
For setting up the serial communication open any terminal program that you like. With Windows you can use the standard terminal program HyperTerminal and create a new communication with the following values:- Bits per second: 115200
- Data bits: 8
- Parity: none
- Stop bits: 1
- Flow control: none
Now you should see the Linux prompt of the camera in the terminal program. Neither user nor password is needed.
- Note
- Perhaps you have to press
[ENTER] so that the display is refreshed.
Setting up the camera
Besides wxPropView, there are further tools to set up the device:
With wxPropView it is possible to change e.g. the
- image properties or
- IP address.
With mvGigEConfigure it is possible to install the
- GigE capture filter of the network controller.
With mvIPConfigure it is possible to configure the
- network behavior of GigE devices.
mvDeviceConfigure is the program e.g.
- to set the device ID or
- to update firmware or
- to upload a GenICam XML file or
- to disable CPU sleep states.
For further information about the programs, please follow the link to the detailed description.
Settings behaviour during startup
Settings contain all the parameters that are needed to prepare and program the device for the image capture. Every image can be captured with completely different set of parameters. In almost every case, these parameters are accessible via a property offered by the device driver. A setting e.g. might contain
- The gain to be applied to the analog to digital conversion process for analog video sources or
- The AOI to be captured from the incoming image data.
So for the user a setting is the one an only place where all the necessary modifications can be applied to achieve the desired form of data acquisition. There is however an important difference in behaviour between different interface layouts. See here to find out how to modify the interface layout or check in the API documentation for the interfaceLayout property of the class Device. When working in DeviceSpecific interface layout, each frame will be captured with the settings as present when requesting the image. For GenICam interface layouts all device properties modified during a continuous acquisition will have immediate impact on the next frame transmitted by the device thus here when a precise moment to change settings is needed, continuous acquisition must be stopped and then restarted after modifying the features.
Now, whenever a device is opened, the driver will execute following procedure:
- Please note that each setting location step in the figure from above internally contains two search steps. First the framework will try to locate a setting with user scope and if this can't be located, the same setting will be searched with global (system-wide) scope. Under Windows this e.g. will access either the HKEY_CURRENT_USER or (in the second step) the HKEY_LOCAL_MACHINE branch in the Registry.
- Whenever storing a product specific setting, the device specific setting of the device used for storing will be deleted (if existing). E.g. you have a device "VD000001" which belongs to the product group "VirtualDevice" with a setting exclusively for "VD000001". As soon as you store a product specific setting, the (device specific) setting for "VD000001" will be deleted. Otherwise a product specific setting would never be loaded as a device specific setting will always be found first.
- The very same thing will also happen when opening a device from any other application! wxPropView does not behave in a special way but only acts as an arbitrary user application.
- Whenever storing a device family specific setting, the device specific or product specific setting of the device used for storing will be deleted (if existing). See above to find out why.
- Under Windows the driver will not look for a matching XML file during start-up automatically as the native storage location for settings is the Windows Registry. This must be loaded explicitly by the user by using the appropriate API function offered by the SDK. However, under Linux XML files are the only setting formats understood by the driver framework thus here the driver will also look for them at start-up. The device specific setting will be an XML file with the serial number of the device as the file name, the product specific setting will be an XML file with the product string as the filename, the device family specific setting will be an XML file with the device family name as the file name. All other XML files containing settings will be ignored!
- Only the data contained in the lists displayed as
"Image Setting","Digital I/O", and"Device Specific Data"under wxPropView will be stored in these settings!
- Restoring of settings previously stored works in a similar way. After a device has been opened the settings will be loaded automatically as described above.
- A detailed description of the individual properties offered by a device will not be provided here but can be found in the C++ API reference, where descriptions for all properties relevant for the user (grouped together in classes sorted by topic) can be found. As wxPropView doesn't introduce new functionality but simply evaluates the list of features offered by the device driver and lists them any modification made using the GUI controls just calls the underlying function needed to write to the selected component. wxPropView also doesn't know about the type of component or e.g. the list of allowed values for a property. This again is information delivered by the driver and therefore can be queried by the user as well without the need to have special inside information. One version of the tool will always be delivered in source so it can be used as a reference to find out how to get the desired information from the device driver.
Relationship between driver, firmware, FPGA file and user settings
To operate a GenICam based device like mvBlueCOUGAR-X apart from the physical hardware itself 2 pieces of software are needed:
- A firmware running on the device. This firmware consists of
- A GenICam compliant XML file exposing the features in a generic and standard compliant way
- A FPGA file
- The actual micro-code making the device operational
- A device driver (this is the mvGenTLConsumer.dll and the mvGenTLProducer.cti on Windows and the libmvGenTLConsumer.so and the libmvGenTLProducer.so on Linux when using mvIMPACT Acquire, but can be any other GigE Vision compliant driver package from a third party vendor) running of the host system (provides control over the device from an application running on the host system).
The physical GenICam compliant device has a firmware programmed into the device's non-volatile memory, thus allowing the device to boot to a fully functional state without the need of any additional software running on the host. The firmware version that will be used when operating the device does NOT depend on the driver version that is used to communicate with the device. This will allow any piece of compliant third party software to operate the device without the need to have special knowledge about the firmware structure. This shall be illustrated by the following figure:
- Note
- As it can be seen in the image the firmware file is NOT part of the device driver but comes as a separate archive. It is important to notice that a firmware file that may be present on the host system will NOT be used automatically but only when the user or an application explicitly updates the firmware on the device and will only become active after power-cycling the device.
Typical names for a firmware update archive (* in the figure above) are:
- mvBlueCOUGAR-P_Update.tgz for devices belonging to the mvBlueCOUGAR-P family
- mvBlueCOUGAR-Sxxxy_Update.fpg for devices belonging to the mvBlueCOUGAR-S family, where xxx stands for the device model and y will either be C (color) or G (grey) thus e.g. mvBlueCOUGAR-S123C_Update.fpg
- mvBlueCOUGAR-X_Update.mvu for devices belonging to the mvBlueCOUGAR-X family
- mvBlueLYNX-M7_Update.tgz for devices belonging to the mvBlueLYNX-M7 family
Only during a firmware update the firmware file that has been selected from the file system of the host system will be downloaded permanently into the device's non-volatile memory.
- Warning
- Each firmware archive might contain more than one specific firmware version per device thus in order to select the one that is appropriate for the device appropriate tools such as mvDeviceConfigure should be used.
So assume a device with a certain firmware version is connected to a host system.
During an explicit firmware update, the firmware file will be downloaded onto the device. In order to become active the device must be power-cycled:
This can either be done by unplugging the device and then by plugging it back in or (for devices supporting this feature) by resetting/rebooting the device by a certain software command (DeviceControl/DeviceReset). When using mvDeviceConfigure to update devices the latter mechanism will be used by the tool thus it is NOT necessary to unplug the device.
When the device has completed rebooting the new firmware version will become active:
- The current firmware version of the device can be obtained either by using one of the applications which are part of the SDK such as mvDeviceConfigure or by reading the value of the property Device/FirmwareVersion or DeviceControl/DeviceFirmwareVersion using the API
- The current FPGA file version used by the device can be obtained by reading the value of the property DeviceControl/mvDeviceFPGAVersion
- Note
- The FPGA file is a part of the firmware and cannot be updated independently thus reading its version just provides some additional information.
Using wxPropView the same information is available as indicated by the following figure:
Apart from the device driver and firmware relationship there are certain places where a device configuration can be stored when dealing with GenICam compliant devices:
- There may be User Setswhich are stored in the device's non-volatile memory. User Sets contain all the features, which affect the device's behaviour such as transfer pixel format, exposure time etc. User Sets are bound to major GenICam XML file releases, thus these settings will be lost whenever a firmware contains a different major version of a devices GenICam XML file
- mvIMPACT Acquire settings which contain the state of all the features also stored in a User Set as well as other features added by the device driver. These settings will be stored on the host system either as a XML file or (under Windows only) in the Registry
Both methods can be used to pre-configure a device. Using the first method, the state of the features will travel with the physical device, using the mvIMPACT Acquire settings, feature states can be copied from host to host as a file.
DHCP and netboot information
The mvBlueCOUGAR-P(by default) tries to netboot before the local boot method.
If you've already setup a netboot server (including DHCP) which serves the needed boot files via TFTP boot server the mvBlueCOUGAR-Pcan boot the whole system from a remote server, including root file system and Kernel.
In this case, the boot process would work like this:
- The DHCP server provides an IP address for the device.
- The mvBlueCOUGAR-Pasks for the needed netboot files.
- If no netboot files are available, the boot process continues with local boot method but with a IP from the DHCP server.
MATRIX VISION offers a preconfigured DHCP and TFTP boot server inside the Virtual Machine (VMware).
- See also
- For more information about DHCP: http://en.wikipedia.org/wiki/Dynamic_Host_Configuration_Protocol
- For more information about TFTP: http://en.wikipedia.org/wiki/Trivial_File_Transfer_Protocol
- Connecting the camera
How to setup netboot
In order to use netboot you need the following (if you want to install this on a separate PC):
- A TFTP server - we preinstall "tftpd-hpa" inside the Virtual Machine (VMware) (Ubuntu 8.04 main repository).
-
A DHCP server - please have a look on our preinstalled configuration files e.g.
"/etc/dhcp3/dhcpd.conf"inside the Virtual Machine (VMware).
- Attention
- By default, our DHCP server only provides IP addresses to mvBlueCOUGAR-P and mvBlueLYNX-M7 devices. We do this to avoid problems in case you activate the DHCP in your company network! So please be careful, if you want to adapt the DHCP server!
The advantage using DHCP addresses is the quick startup without waiting for a logical link address (LLA) / zero configuration address.
Needed files
You can find the netboot files (Kernel and root fs) inside the Virtual Machine (VMware) here:
/var/lib/tftpboot
- mvbc-p-2.6.26.boot (mvBlueCOUGAR-P Kernel file)
- mvbc-p.dtb (mvBlueCOUGAR-P hardware description required by latest PowerPC Kernels)
- mvblm7-2.6.26.boot (mvBlueLYNX-M7 Kernel file)
- mvblm7.dtb (mvBlueLYNX-M7 hardware description required by latest PowerPC Kernels)
- uInitrd.mvbcp (mvBlueCOUGAR-P root file system)
- uInitrd.mvbc-p-rfs -> uInitrd.mvbcp (symbolic link to the mvBlueCOUGAR-P root file system)
- uInitrd.mvblm7 (mvBlueLYNX-M7 root file system)
- uInitrd.mvBL-M7-rfs -> uInitrd.mvblm7 (symbolic link to the mvBlueLYNX-M7 root file system)
In this directory you have both versions, for the mvBlueLYNX-M7 and mvBlueCOUGAR-P.
