Balluff - BVS CA-SF Technical Documentation
Relationship Between Driver, Firmware And SDK

To operate a GenICam based device 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 and the on Linux when using Impact Acquire, but can be any other USB3 Vision / 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:

Figure 8: The firmware is not a part of the device driver
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.

The name of the firmware update archive (* in the figure above) is:

  • mvBlueFOX3_Update.mvu

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.

Wrong firmware

Each firmware archive might contain multiple firmware files (e.g. for different device types or device hardware revisions). Installing an unsuitable firmware version can damage the device.

→ In order to make sure suitable firmware versions for a specific device are installed appropriate tools such as DeviceConfigure 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:

Figure 9: Firmware file will be downloaded during a firmware update...

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 DeviceConfigure 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:

Figure 10: ... after re-powering the device it will be 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 DeviceConfigure 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
The FPGA file is a part of the firmware and cannot be updated independently thus reading its version just provides some additional information.

Using ImpactControlCenter the same information is available as indicated by the following figure:

Figure 11: ImpactControlCenter - FPGA and Firmware version numbers

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 Sets which 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
  • Impact 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 (on 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 Impact Acquire settings, feature states can be copied from host to host as a file.