Interchangeability or Compatibility?
1. Machine Vision Standards
The emergence of machine vision standards has led to the industry agreeing on cooperation in an unprecedented way. In the last ten years, this has resulted in generic interfaces for the use of industrial cameras with standardized function names and a defined range of features, in the shape of GenICam, GigE Vision, and USB3 Vision. This should simplify and shorten the design-in phase for cameras in machine vision applications with the aim of cutting development costs. Interchangeability and complete plug & play functionality of devices are always emphasized as key features.
But are these the crucial factors for implementing an application? Is a totally generic solution for every application the right way? It really depends.
To create a successful application, manufacturer interchangeability can certainly be an important advantage. However, what is clear is that maintaining this advantage is linked to conditions that have to be met but are only defined when setting up an application.
By contrast, the development of machine vision components in compliance with the specifications in “vision standards” is important enough to be used in more applications than before. For manufacturers, the desired objective thus tends to be “increased compatibility”, which is achieved automatically by using the standard vision protocols.
Standardization by the organizations AIA (Global Association for Vision Information) and EMVA (European Machine Vision Association) represents an important step towards putting an end to the confusion of interfaces in the machine vision environment. Nevertheless, the standards allow the manufacturers sufficient scope for implementing additional, specific features outside the SFNC to enable providers to differentiate themselves (quality of implementation). If these manufacturer-specific feature sets are used, a change of manufacturer may not be possible without software adaptation.
In terms of the programming interface too, proprietary methods definitely provide a greater level of convenience and user-friendliness than GenICam by incorporating convenience functions that are not part of the vision standard. Manufacturers of industrial cameras know this and therefore often offer their own programming interfaces, albeit based on the standardized interfaces.
Does an application still remain compatible across manufacturers when these “proprietary standards” are used, or should the standard interfaces be used exclusively?
2. The standardized system in detail
To effectively implement the requirements and objectives for an application, important details of the generic system solution should also be known and used to the correct extent.
System architecture
Even if current machine vision standard cameras with GigE Vision or USB3 Vision interfaces “work” without a manufacturer-specific software package, the fundamental system architecture is necessarily retained and has to be present on a system.
The hardware level is based on established technologies and connection methods for transferring camera data, and communication protocols (e.g. USB, Gigabit Ethernet). Device software (drivers and user space libraries) use an API for communication between the camera’s transfer channel and the user application.
Figure 1 – Interface standardization results in numerous opportunities for applications to use machine vision standard cameras.
With GenICam as a basis, there has been standardization at several interfaces in the system architecture, which has created numerous clearly defined and documented starting points for the use of machine vision standard cameras.
Turning N into 1 and 1 into N
With GenICam (Generic Interface for Cameras) as the communication link between the user application and device software, the large number of manufacturer-specific programming interfaces is restricted to a single generally applicable one. GenICam abstracts access to all camera functions across manufacturers and transfer protocols. GenICam is a description language. The available functions are provided for use without knowing it themselves. This makes it an ideal basis for applications involving features that change with every camera model or can be expanded by firmware updates.
The introduction of protocols such as GigE Vision and USB3 Vision at a transfer level means that a rethink was necessary in terms of the camera firmware. Cameras with these standardized transfer protocols, which are defined by the members of the AIA, speak a standard language to the device software. This breaks up the strict association between camera firmware, transfer protocol, and device software. The camera is independent of a single manufacturer’s software.
Independence brings new opportunities
Vision-compatible cameras can now be operated with a manufacturer-independent “Generic Transport Layer” (GenTL). The GenAPI (Generic Application Programming Interface) enables the available camera features to be listed and configured by analyzing the standard-compliant XML file for the camera. The content of this file describes all the implemented camera features using a syntax defined in the GenAPI module of the GenICam specification: Function names, parameter lists, extended information, function description. Even tooltips that an application will display for the features are described in the XML file. You could say that the camera provides its own programming manual.
It makes no difference whether we are dealing with standard features defined in the GenICam SFNC (Standard Feature Naming Convention) or special “custom features” that are only available from one manufacturer, but are implemented in compliance with the standard.
Figure 2 – The GenAPI communicates device-specific register addresses using defined feature names.
Technically, the manufacturer-independent cooperation of hardware and software is defined by the standard and is viewed as “desirable”. However, only the camera is 100% independent. GenICam producers from some manufacturers appear to advise the user of which camera they would like to cooperate with. This can sometimes make interchangeability slightly nontransparent for users.
Independence automatically results in numerous new possibilities both for camera manufacturers and users, for example the separation of hardware and software releases. A new camera model or new camera firmware can be provided in a much shorter time as no adaptation, documentation, and publication of host software is necessary to operate the camera.
Likewise, updates for individual camera models independently of the host software or other models can be completed much more easily and quickly. Members of the EMVA organization are already working on an update specification to define how vision cameras can be updated with a manufacturer-specific update package using any standard-compliant software. An additional update module specification for the GenICam standard is expected later in the summer of 2017.
Independence automatically entails enhanced platform compatibility. With the standard transport protocols such as GigE Vision or USB3 Vision, the cameras can run on any platform and in any operating system for which there is standard-compliant manufacturer-independent software including transport layer. Even if it does not come from the same company.
This independence is thus the basis for “interchangeability”.
Not all GenTLs are the same
GenTLs are certainly not all the same. Simply the fact that they have a standardized interface both towards the camera and towards the user application (see white elements in Figure 1), and they are actually only intended to be responsible for identifying and addressing devices including image acquisition, does not necessarily make them compatible with all vision cameras.
A standardized GenTL is a very useful addition for a machine vision library such as HALCON, it is open to vision cameras from all manufacturers. The advantage of this is complete plug & play capability for all cameras without the need to install a manufacturer-specific 3rd party library. For this reason, MVTec developers have equipped HALCON with a dedicated cross-manufacturer compatible GenTL (see Figure 3), which can use any vision compatible camera without any special manufacturer software.
For camera manufacturers, using their own GenTL in spite of the standard specifications provides an opportunity to provide customers with a software component that interacts “optimally” with their own camera and is also covered by the manufacturer support. This is an important issue if a problem with the camera occurs in a machine vision application. Who is responsible if the application, MV library, GenTL, and camera each come from different manufacturers? This question never arises if all components are from the same manufacturer.
3. Camera uniformity?
Cameras that follow the standard communicate and transfer data using the same protocols and provide defined standard features. “If you know one, you know them all?” Absolutely not!
Where different driver software was previously needed to establish understanding between the camera and host, only one “language” is now required. Where each manufacturer used to do things their own way, today they all work together on the interface and implement camera functions to comply with defined specifications. Every user benefits from this trend. How can manufacturers still differentiate themselves? A standardized camera remains a complex product made up of numerous components that are crucial for success:
housing (stability, dimensions, material, weight, connectors, optics, accessories), electronics (EMC behavior, interference behavior, heat build-up, memory, performance, service life), software (sensor knowledge, feature implementation, modularity, maintenance, support), to name just a few. The overall package remains crucial for use in an application.
Complete software support to enable vision cameras to be commissioned quickly and easily, is already a selection criterion for people new to or switching to vision. IDS Imaging Development Systems GmbH has always offered its customers an all-round carefree package for its products. After installation, in addition to the IDS Vision Cockpit with graphical interface for convenient camera evaluation, a manufacturer-specific GenTL is also available to the user. This ensures full compatibility with all standard-compliant machine vision libraries on the market.
Despite the possible interchangeability of vision components, this kind of all-in-one package is a crucial advantage for a machine vision project because it includes complete manufacture support, from the camera hardware to the customer application.
4. Easy to get started?
The easiest way is to start with vision standard components using standard-compliant machine vision software such as HALCON, LabView, Cognex VisionPro. Many well-known machine vision software packages now come complete with their own GenTL provider, which demonstrates actual replacement of vision cameras without manufacturer-specific software. To integrate cameras using the manufacturer’s own GenTL, some of these machine vision software packages have a corresponding GenICam connector.
Figure 3 – HALCON has a direct GigE Vision interface thanks to its own GenTL producer. GenICam also enables connections to any other vision standard interface.
Machine vision software manufacturers are utilizing the full advantages of standardization. Users can immediately start integrating their camera with a machine vision system with no programming work. The user only comes into contact with the standard interfaces using the dynamic GUI for the relevant machine vision framework. Essentially, they represent a user-friendly, graphical, “proprietary” interface, which makes things as easy as possible for the user.
But not every 3rd party machine vision company supplies a corresponding GenTL provider. This blurs the plug & play promise somewhat.
Anyone who chooses the second method and develops their application from scratch can expect additional work. This shifts the focus onto the programming interface. In this case, other factors are important for implementing an application.
Generic programming using GenICam can be very laborious due to the very strict and complex principles. To correctly deal with every eventuality, each feature and each range of values must first be queried, before a camera parameter can be changed. Unfiltered access to each GenICam component is very atomic and requires an in-depth understanding of these principles. If you want to make fast progress for a specific device and are not so concerned with the complex options, you will want a simple, reduced summary as the API. Do these users have to choose the entirely “proprietary” approach and thus miss out on all the advantages that have been achieved with the vision standards?
5. Proprietary standards
Due to the defined interfaces, vision standard cameras can be used in more than just one way. The use of convenience functions, also known as auxiliary or comfort functions, is a design concept whose use is popular in proprietary programming interfaces to support the developers. They help to simplify code and make it clearer by selectively encapsulating atomic function calls. A “defined” objective can thus be achieved much more quickly and easily with a small number of function calls.
If this kind of “proprietary API” towards the camera behaves in compliance with the standard, it can even be an additional access option for a customer application.
Figure 4 – Proprietary interfaces extend the opportunities for using vision standard cameras.
As long as the manufacturer of a proprietary level does not integrate any filtering for their own devices, there is no reason why this approach should prevent use in cross-manufacturer applications.
Proprietary GUIs for machine vision libraries such as HALCON follow this exact approach. HALCON uses vision standards with its own user interface. Simplifying programming interfaces are thus still possible and enhance the benefits to the customer.
6. The application is crucial
The use of standard interfaces is an advantage for applications that involve different cameras and a different range of functions. Mixed operation of standard cameras with different transfer technologies, for example USB3 Vision or GigE Vision, is much easier due to the standardized communication using the GenICam interface. The application does not have to know anything about these device-specific features and thus remains compatible for all standard-compliant devices.
A totally dynamic GUI provides a connection and range of functions for vision cameras with no additional programming work. The actual work for the user or the machine vision operator can start immediately with adjusting the camera for the relevant application.
If an application also includes its own GenTL, no manufacturer-specific software has to be installed to integrate a new camera.
For manufacturers of machine vision cameras, the vision standards mean not only potential for interchangeability but also enhanced compatibility with any standard-compliant applications developed.
However there remains a stable proportion of customer applications on the market for which the USPs (universal selling propositions) of the vision standards are of secondary importance. These users are looking for rapid use of special cameras in conjunction with simple interfaces that offer comprehensive manufacturer support and, where necessary, can be flexibly adapted for their application.
Ultimately the decision always lies with the customer and their application as to which interfaces and devices from which manufacturers will be used to be successful and to offer the “best user experience in the vision market”.