MATRIX VISION - mvBlueCOUGAR-X/-XD Technical Documentation
Connecting The Camera

To start the device please accomplish following steps:

  1. Connect the mvBlueCOUGAR with a
    • Cat 5e / Cat 6 or higher peer-to-peer-cable to a network (e.g. a switch) or PC directly
      With mvBlueCOUGAR-XD you can either connect both LAN connectors (RJ 45) using Link Aggregation or one LAN connector, which requires to use the connector LAN 1 only.
  2. Power the mvBlueCOUGAR via power supply.
    The mvBlueCOUGAR will boot immediately.
If you're using Power over Ethernet (PoE) connecting and powering are one step.
If both power possibilities are connected (local power supply and Power over Ethernet (PoE)), the camera will use the local power supply.
If you change from one supply to the other, the camera will reset and reboot.

After energizing mvBlueCOUGAR via power supply or Power over Ethernet (PoE) the camera will start to boot.

Depending on the configuration of the network or the mvBlueCOUGAR (more precisely: if DHCP is used or not), following IP addresses are assigned:

  • If the mvBlueCOUGAR is configured to use a static IP address, the mvBlueCOUGAR will use this one. In this case, the mvBlueCOUGAR will only be accessible, if the IP address is valid for the current network.
  • With DHCP, the mvBlueCOUGAR will get an IP address from the DHCP server (default setting).
  • Without DHCP, the mvBlueCOUGAR will start with a logical link address (LLA) / zero configuration class B IP address ("169.254.X.X", netmask
Please have a look at LLA in the Glossary when using Linux and LLA.
"Network misconfiguration"

The camera will not be reachable if you are using a wrong static IP address.

→ Please be sure that that the IP address
- does exist
  • is not used by anyone else in the same network
  • is a valid one
If you have two NICs in your PC, please be sure that they are using different subnets, otherwise the systems does not know which Ethernet interface is used to exchange the data.
Working example: PC Port1  PC Port2 Cam1  Cam2

You can change settings like the static IP address to your needs (please have a look at: mvIPConfigure).

Further the mvBlueCOUGAR starts the GigE Vision control server making the device actually discoverable using standard GigE Vision mechanism.

Boot sequence of mvBlueCOUGAR

Communicating With The Camera

You can communicate with the camera the following way

  1. Via wxPropView :
    Since driver version 2.11.3, starting wxPropView the first time, the so called Quick Setup Wizard will be launched.

    Read more about how to make optimal use of it in the mvIMPACT Acquire GUI manual:
    The current IP address can be found in the "Device" properties under "DeviceIPAddress".

Communicating With The Camera

When a GigE Vision device is not connected to the same subnet than the host an advanced discovery mechanism can be used, which is called "Unicast Device Discovery". This mechanism allows to find devices which are connected to a different subnet than the host if they are reachable over a specific gateway and the IP address of that device is known upfront.

Discovering devices in different subnets requires to know the IPv4 address of each device which shall be discovered upfront as a network packet must be sent to these devices.

This special discovery mechanism can be configured using the mvIMPACT Acquire API or the GUI tools coming as part of the mvIMPACT Acquire driver stack. Please have a look at the "Detecting Devices Residing In A Different Subnet" chapter of the: mvIPConfigure manual for a detailed description. More information can also be found here: Discovering Devices In Different Subnets

Setting Up The Camera

MATRIX VISION offers several GUI tools to work with the camera. Please have a look at the specific chapter.

About Settings

A setting contains all parameters that are needed to configure the device to a state it was in when the setting was created. Every image can be captured with a 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 and only place where all the necessary modifications can be applied to achieve the desired data acquisition mode. There is however an important difference in behaviour between different interface layouts. Please have a look at the "mvIMPACT Acquire SDK GUI Applications" chapter "wxPropView -> Device Configuration -> General Device Configuration -> Changing The Interface Layout To GenICam Or DeviceSpecific" 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 with the DeviceSpecific interface layout, each frame will be captured with the settings as present when requesting the image. Every parameter can be modified at any time. When requesting another image the settings valid at that moment will be used to fill this buffer with data
  • For the GenICam interface layout all device properties modified during a continuous acquisition will be applied at once so might affect this or the next image transmitted by the device. Depending on various parameters (the number of buffer already captured but not collected by the application, the way the device internally operates(e.g. has already captured a couple of images that await transmission), etc.) this will have impact on that captured images somewhere in the near future thus when a precise moment to change settings is needed, continuous acquisition must be stopped and then restarted after modifying the features. Certain features (typically those affecting the buffer layout/size) cannot be changed while a continuous acquisition is running in GenICam interface layout anyway.

Now, whenever a device is opened, the driver will execute following procedure:

wxPropView - Device setting start 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. On 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 using THIS device, 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. Storing a product specific setting with a different device belonging to the same family however will NOT delete device specific settings for other devices.
  • The very same thing will also happen when opening a device from any other application! mvPropView 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.
  • On 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!
  • 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 mvPropView 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. mvPropView 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.