General

The Impact Acquire framework uses a property based concept to access parameters of internal structures or to configure the framework's behaviour. Features offered by the device will simply be added to other properties already present in the drivers feature tree. The following list displays the general layout of features in the GenICam™ interface layout (see 'GenICam' vs. 'DeviceSpecific' Interface Layout for details on different interface layouts):

|
|- 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 'Image acquisition → 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 behaviour of the driver
|
|- Info // various features providing information about the device, driver versions etc.
|
|
other features

For most of the features offered by a device there will be ready to use wrapper objects that come with the SDK so there will be no need to look up the feature at runtime. Depending on the selected interface layout either objects belonging to the DeviceSpecific interface or to the GenICam™ interface can be used. To see which SDK objects belong to which interface layout all the objects have been put into groups in the Modules section of this documentation. To find out which device supports which interface layout please refer to Which Interface Is Supported By Which Device? .

For the GenICam™ interface layout there will be convenient access objects for ALL the feature defined in the GenICam™ Standard Feature Naming Convention (SFNC) as well as ALL the custom features defined by Balluff. So to access e.g. SFNC compliant features belonging the AcquisitionControl category this object can be used:

mv.impact.acquire.GenICam.AcquisitionControl.

The exposure time then can be modified like this:

// Set property exposureTime using GenICam
mv.impact.acquire.GenICam.AcquisitionControl ac = new mv.impact.acquire.GenICam.AcquisitionControl( pDev /* this device pointer can be obtained from the mv.impact.acquire.DeviceManager class */);
Console.WriteLine( "exposureTime (current): {0}\n", ac.exposureTime.read() );
ac.exposureTime.write( 10000 );
Console.WriteLine( "exposureTime (new): {0}\n", ac.exposureTime.read() );

All objects, which grant access to device driver interface properties, will require the pointer to the mv.impact.acquire.Device acquired from a mv.impact.acquire.DeviceManager object again.

Note: It is not necessary to call mv.impact.acquire.Device.open before creating objects requiring a pointer to a device object, but each constructor accepting such a pointer will need the device to be opened, so the first object constructed from a pointer to a closed mv.impact.acquire.Device object will try to initialize the device, which is why the first constructor call might take some time.; If for some reason the device can't be initialized, an exception might be thrown by any of those constructors.

A selection of objects the user can create to modify or read mv.impact.acquire.Property are listed in the following sections:

Runtime Feature Extraction

If an application shall be capable of dealing with every feature of every device and not all these devices are known at compile time, a code generator can not be used as it can only create code for devices which are accessible when creating the code. In this case, features must be extracted dynamically from the drivers feature tree. To do this SDK offers a set of functions that can be used to search and use features or to iterate over a tree of features. These objects and functions will be explained in the following sections.

Note: The GUI tool ImpactControlCenter can be of great help when writing code that shall extract certain features from the driver for using them inside an application. To find out how please have a look at the chapter "Changing the view of the property grid to assist writing code that shall locate driver features" in the technical manual of the device.; Most of the code presented in this section is also part of the SDK even though it is not part of the actual Impact Acquire driver framework. It has been added as a set of helper functions in a separate source file to the example applications. The source code can be found in the installation folder under apps/Common/exampleHelper_C*. An application can either add the full source file to its Makefile or extract and re-use source code as needed from here. All the example applications written in C do this as well.