Note: This section is also tightly coupled with everything described here: Notes About Impact Acquire Version 1.11.32 Or Higher And/Or Using mvBlueCOUGAR-X With Firmware 1.2.0 Or Higher.

The dilGeneric interface layout has been declared deprecated since version 1.11.37 of Impact Acquire and was removed from the interface in version 2.6.0. It has been replaced by a new interface layout dilGenICam. New applications should NOT be written using the dilGeneric interface layout, existing ones should be ported. Porting an application from one interface layout to the other in most cases will require less than one hour and will improve interoperability of the driver framework with different hardware platforms especially third party GigE Vision™ devices. When the generic interface was designed the idea was to have a look and feel which as closely matches the typical Impact Acquire interface layout in terms of where properties are located in the drivers property tree.

As a result of that e.g. all the digital I/O related features where created inside the IOSubSystem category as Impact Acquire does. A GigE Vision™ device typically refers to digital I/O as Lines and these are located in the GenICam™ SFNC compliant category DigitalIOControl. However, in earlier version of the GenICam™ SNFC documentation there have been no standard names for standard categories which resulted in different manufacturers using different names for essentially the same thing. This now made it quite difficult to locate the category for digital I/Os in a devices XML description file. Simply looking for one or more of the standard I/O features and then check for the category these features reside would have been an option, but then again there have been devices having 2 or more categories with almost identical names(e.g. one for the SFNC compliant I/O stuff and one with the additional I/O features added during the device design).

To sum it up: Analyzing the devices XML file and then make certain assumptions on which features fits where in Impact Acquire's property hierarchy turned out not to be such a brilliant idea and required constant modifications in the driver framework. This was a problem for both customers and developers at Balluff. In order not to break existing applications the current dilGeneric interface layout was left untouched and a new one (dilGenICam) was introduced. In terms of timing and overall behavior both interface layouts are identical. Internally they even share large portions of the code. The only difference, which can be seen from the outside is the location of the properties that are created from the GenICam™ XML files. Thus, code that locates and binds certain properties and methods might need to be changed in terms of the starting locations of the search calls.

In dilGeneric the layout did more or less (if locating the standard categories succeeded) look like this:

|
|- ImagingSubsystem
|    |
|    |- Setting
|         |
|         |- Setting Base // In GenICam interface layout only one capture setting is supported to understand how to use several settings have a look at the example section or the 'Working with settings' chapter
|         |    |
|         |    |- Camera // features extracted from the devices XML file
|         |         |
|         |         |- ImageFormatControl (see SFNC)
|         |         |- AcquisitionAndTriggerControl (see SFNC)
|         |         |- etc. // everything else, that is not part of the SFNC. This will be created 'as is', thus with the structure defined in the description file of the device
|
|- IOSubSystem
|    |- LineSelector
|    |- etc. // all other Digital I/O related features
|
|- System
|    |
|    |- GenTL // features extracted from the GenICam GenTL producers XML files
|    |     |
|    |     |-Stream0
|    |     |-Stream1
|    |     |-...
|    |     |-Stream(n-1)
|    |
|    |- TransportLayer
|    |- CodeGeneration
|    |- FileAccessControl
|    |- etc. // various other features the influence the overall behavior of the driver
|
|- Info // various features providing information about the device, driver versions etc.
|
|
other features

while in dilGenICam now no assumptions are made and everything extracted from GenICam™ XML files ends up below the Camera category of the imaging sub-system:

|
|- ImagingSubsystem
|    |
|    |- Setting
|         |
|         |- Setting Base // In GenICam interface layout only one capture setting is supported to understand how to use several settings have a look at the example section or the 'Working with settings' chapter
|         |    |
|         |    |- Camera
|         |         |
|         |         |- GenICam // features extracted from the devices XML file
|         |         |     |
|         |         |     |- ImageFormatControl (see SFNC)
|         |         |     |- AcquisitionAndTriggerControl (see SFNC)
|         |         |     |- etc. // everything else, that is not part of the SFNC. This will be created 'as is', thus with the structure defined in the description file of the device
|         |         |
|         |         |- GenTL // features extracted from the GenICam GenTL producers XML files
|         |               |
|         |               |- Device
|         |               |- DataStream
|         |               |- etc.
|
|- System
|    |
|    |- CodeGeneration
|    |- etc. // various other features the influence the overall behavior of the driver
|
|- Info // various features providing information about the device, driver versions etc.
|
|
other features