Could you explain what challenge in machine vision inspired the development of Genicam twenty years ago?
Fritz Dierks: GenIcam was created, when there was a discussion about using GigE as an interface for cameras, because we had two problems. The technical problem was that it was common to use a fixed register layout for camera standards like iDC or 1394 FireWire cameras, but it was extremely inflexible. Nobody who uses a standard driver could use a custom feature and there was another problem with fixed register layouts because you couldn’t change implementation. Then there was a ‚political‘ problem because all major companies fought for their own register layout standard. At that point, I remember that Basler had a configuration tool for their cameras, which wouldn’t fix the registers. You had a configuration layer where you could design features by names, type and meaning to configure which registers you have to set and get in order to touch these features. I propose that this might be a way out of the problem. We don’t agree on all the details of the register layout, but we standardise names, types and meanings and also standardised an XML format, where you can put in the mapping between the features and the details of the camera. This could be specific for every camera and every vendor, so everybody would be free to add their own register layout. If I had known how much work that would be for me, I’m not sure I would have proposed it. But in the end, it worked and that was the birth of GenIcam.
What was the biggest hurdle in the beginning?
Dierks: Making people agree on a totally different way of dealing with camera features because everybody was aware how fixed register layout worked. GenIcam was a completely new idea and people were a bit reluctant to adopt it. We were in a desperate situation because the market expected the GigE vision standard to become live at 2006 and we were at the end of 2004. Furthermore we had the GenAPI mechanism, which is the XML file, and the first version of the standard implementation should be shown at Vision 2005. People said we need a list of standard feature names and types, but we didn’t have, because we were focused on getting the standard mechanism running. So there was an emergency meeting beginning of 2006 hosted by National Instruments. Within one week we agreed on the basic set of the new SNFC (Standard Feature Naming Convention), which is still there today. OptoMedias ultrakompaktes Mini SFF bringt zuverlässige, schnelle Glasfaserverbindungen in Industriekameras der nächsten Generation. ‣ weiterlesen
Fiber Mini SFF für GigE Vision
How does GenIcam balance standardisation with flexibility for manufacturers to offer their own unique features?
Michael Schmidt: Most devices for machine vision applications like cameras have a rather simple register interface. This was even more true twenty years ago. It´s like a register interface to an assembly language: It’s compact and efficient, but each processor model brings its own instruction. Today we have high level languages like C++ that allow you to describe your program in a processor independent way. The compiler translates your source code to machine code and takes care of many other things like type checking… GenAPI is a bit like the compiler. It provides a high level programming interface and translates it to the low level register interface nobody really wants to work with. You can write anything with a C++ compiler, but all programs that operate under a certain operating system (Linux or Windows), must agree on the same interface to open a main window. SFNC defines the features for standard functions and how they work. That makes it easier to write software that works with devices from multiple vendors. But you can still add features that are not standardised, e.g. your own version of exposure time control.
