HALCON 6.1 Frame Grabber Interface for BitFlow Boards

This document provides some information about the HALCON frame grabber interface HFGBitFlow.dll for the BitFlow boards Raven, RoadRunner, RoadRunner CL, R3, R3-CL, and R64. Note that this interface is the successor of both the HALCON Raven and RoadRunner interfaces. Registered customers can download the latest revision of this interface from the MVTec WWW server.

Revision: 2.8

• Intel compatible PC with Windows NT 4.0 (Service Pack 4), Windows 2000 or Windows XP.
• Successfully installed BitFlow driver BitFlow.sys (BitFlow SDK version 4.00 or higher). If you do not have this driver version, please contact BitFlow or the vendor from which you bought the frame grabber board.
• If using a RoadRunner, verify that the PLX chip is a 9080. If using a Raven, load LBC firmware with 'Host based QTabs'.
• BitFlow DLLs R2D.dll, RvD.dll, CiD.dll, and BFD.dll.
  These DLLs must be in your search path %PATH%. If you do not have these DLLs, please contact BitFlow or the vendor from which you bought the frame grabber board.
• HALCON frame grabber interface HFGBitFlow.dll or parHFGBitFlow.dll, respectively.
  If you have properly installed the interface, both DLLs should reside in bin\i586-nt4 within the HALCON base directory %HALCONROOT% you have chosen during the installation of HALCON.

• Multiple frame grabber boards.
• Multiple compatible cameras per board (port switching).
• Synchronous and asynchronous grabbing.
• External trigger (with software override of the camera configuration file).
• Up to 1000 frame buffers (e.g., for volatile and/or continuous grabbing).
• Completely asynchronous grabbing of up to 40 images (with or without external triggering; see parameter 'continuous_grabbing' and the corresponding section below).
• Support of multiple analog and digital cameras based on the BitFlow camera configuration files.
• (Partial) software control of the number of bits per pixel (with software override of the camera configuration file).
• Support of the digital output lines.
• Support of line scan cameras.
• Simultaneous grabbing from multiple synchronized cameras (see parameter 'num_simultaneous_cameras' in the corresponding section below).
• Writing and reading of LUTs.
• Dynamically changing the frame size of the grabbed image.
• Support of start/stop trigger mode (for line scan cameras connected to RoadRunner, RoadRunner CL or R64 boards).
• Serial communication with CameraLink cameras.

• Only one frame grabber instance per frame grabber board (however, multiple compatible cameras can be accessed using port switching or simultaneous grabbing).
• No subsampling or cropping of image parts through the HALCON interface. This feature is supported through the use of camera files.
• grab_region and grab_region_async not supported.
• No support for LUTs in combination with R64 boards.

Parameters for open_framegrabber():

	Name		'BitFlow'		The name of the HALCON frame grabber interface.
	HorizontalResolution		1, width		The desired image resolution. Use '1' for full resolution or the corresponding absolute value (depending on your camera). Default: 1.
	VerticalResolution		1, height		The desired image resolution. Use '1' for full resolution or the corresponding absolute value (depending on your camera). Default: 1.
	ImageWidth		0		The width of the desired image part ('0' stands for the complete image). Default: 0.
	ImageHeight		0		The height of the desired image part ('0' stands for the complete image). Default: 0.
	StartRow		0		The row coordinate of the upper left pixel within the desired image part ('0' obviously results in delivering the complete image). Default: 0.
	StartColumn		0		The column coordinate of the upper left pixel within the desired image part ('0' obviously results in delivering the complete image). Default: 0.
	Field		---		Ignored.
	BitsPerChannel		-1, 8, 10, 12		The number of bits per channel. By specifying the default '-1' the corresponding setting of the camera configuration file is used. Default: -1.
	ColorSpace		'gray', 'rgb'		The desired color space. If BitsPerChannel is set to -1, the value is ignored and overwritten by the settings of the camera configuration file. Default: 'gray'.
	Gain		---		Ignored.
	ExternalTrigger		'true', 'false'		Activate/deactivate external triggering. Note that this setting overrides the corresponding setup in the camera configuration file. Default: 'false'.
	CameraType		'file', 'default'		This parameter is used to specify the camera configuration file (e.g., 'BfSynth256E1.cam' (RoadRunner) or 'GenSynthetic-640Analog.rvc' (Raven) for a synthetic test image). If you specify 'default' the first camera you have set with SysReg is used.
	Device		'<BoardType>:<nr>', 'default'		The type ('Raven', 'RoadRunner' or 'R64') and the number ('0', '1', '2' ...) of the frame grabber board (passed as one string!), e.g., 'Raven:0', 'RoadRunner:1' or 'R64:0'. Note that R3 boards are treated in the way as RoadRunner boards. If you specify 'default' the interface automatically selects the first board.
	Port		number		The number attached to the desired camera via the BitFlow configuration program SysReg (starting with 0 for the first camera). Only evaluated in case the CameraType parameter has been set to 'default'. Default: 0.
	LineIn		---		Ignored.

Parameters for set_framegrabber_param():

	'continuous_grabbing'		'enable', 'disable'		Activate or deactivate 'continuous grabbing'. For details, please see the corresponding section below. Default: 'disable'.
	'do_comm_close'		---		Closes the comm port.
	'do_comm_flush'		---		Discards any bytes that are available in the input buffer of the comm port.
	'do_comm_open'		---		Opens and initializes the comm port for use on the board. The comm port will always be opened with 9600 baud, 8 data bits, no parity, and 1 stop bit. The default timeout is 1 second.
	'do_comm_param'		string		Sets the parameters for serial communication, seperated by colons. The following parameters can be specified: timeout: timeout in milliseconds. baud_rate: baud rate. Valid baud rates are 9600, 19200, 38400, 57600, 115200, 230400. parity: parity to be used. N=No parity, E=Even parity, O=Odd parity. data_bits: size of the data. 5=5 bit data, 6 = 6 bit data, 7 = 7 bit data, 8 = 8 bit data. stop_bits: number of stop bits. 1 = 1 stop bit, 15 = 1.5 stop bits, 2 = 2 stop bits Example: set_framegrabber_param(FGHandle, 'comm_param', 'baud_rate 9600:data_bits 8:parity N')
	'do_comm_write'		message		Writes message to comm port. Note that message can either be a string value or a tuple of integers. The latter case also allows the writing of NUL characters. Examples: set_framegrabber_param(FGHandle, 'do_comm_write', 'TR=2\r\n'), set_framegrabber_param(FGHandle, 'do_comm_write', [0,127,128])
	'grab_timeout'		milliseconds		Specify the desired timeout (milliseconds passed as an integer) for aborting a pending grab (the default value is specified in the camera configuration file).
	'hardware_exception_thread'		'enable', 'disable'		Start/stop hardware exception thread to reset acquisition in continuous grab mode when there is a hardware exception. Default: 'disable'.
	'image_height'		height		Dynamically change the current image height of the grabbed image. This feature is limited to use with only free run camera files (see also the comments to CiAqFrameSize in the BitFlow SDK Reference).
	'image_width'		width		Dynamically change the current image width of the grabbed image. This value has to be a multiple of 4 and is limitied to use with only free run camera files (see also the comments to CiAqFrameSize in the BitFlow SDK Reference).
	'num_buffers'		2 - 1000		Specify the number of frame buffers used by the interface. Default: 2.
	'num_simultaneous_cameras'		number		This parameter sets the number of cameras from which the board grabs images simultaneously (see corresponding section below). Default: 1.
	'out:X'		'high', 'low'		Specify the desired state of one of the digital output lines (with X = 0, 1, or 2 for a RoadRunner board; X = 0, 1, 2, 3, 4, or 5 for a Raven or RoadRunner CL board; X = 0, 1, 2, 3, 4, 5 or 6 for a R64 board). The default depends on the board settings.
	'overflow_thread'		'enable', 'disable'		Start/stop overflow thread to reset acquisition in continuous grab mode when there is an overflow exception. Default: 'disable'.
	'overwrite_method'		'abort', 'holdoff', 'ignore'		Specify how the interface should handle siutuations where the external trigger is received faster than the images are read by the application in continuous grabbing mode (see also the corresponding section below). Default: 'holdoff'.
	'port'		number		Switch to the camera with the specified number (attached via the BitFlow configuration program SysReg - starting with 0 for the first camera). Using this port switching you can access multiple cameras with one frame grabber board (see below).
	'read_buf_size'		0 ... 32768		Sets the number of bytes to read from the read buffer of an open comm port. This will most likely be set before each read, unless the message from the camera is always the same size. Default: 0.
	'resnap'		'true', 'false'		Specify whether to reset the DMA engine and to try a second snap in case of an overflow. Note that in continuous mode you can use the parameter 'overflow_thread' to reset acquisition when there is an overflow exception. Default: 'false'.
	'show_internal_errors'		'true', 'false'		Specify whether the frame grabber interface should pop up an alert box in case of an error or not. If you use your own error management, we recommend to switch off the internal error display. In this mode only the error code is returned by the frame grabber operators, but the interface itself is "silent" (important for inline applications etc.). Otherwise, the user has to click on one of the buttons in the error dialog. On the other side, activated internal error display will result in more detailed and specific error messages for trouble shooting. The two behaviors can also be reached by using the HALCON operator set_system('do_low_error','true') or set_system('do_low_error','false'), respectively. Default: 'true'.
	'trigger_timeout'		milliseconds		Specify the desired timeout (milliseconds passed as an integer) for aborting a pending grab when waiting for an external trigger (a default of 60 seconds is set during open_framegrabber()).
	'volatile'		'enable', 'disable'		Grayscale only. In the volatile mode the two frame grabber interface buffers are used directly to store HALCON images. This is the fastest mode avoiding to copy raw images in memory. However, be aware that older images are overwritten again and again as a side-effect. Thus, you can only process one image while you grab another image. Older images are invalid! Default: 'disable'.

Parameters for get_framegrabber_param():

Additional parameters supported by get_framegrabber_param only. Note that all parameters supported by set_framegrabber_param except the ones with prefix 'do_' can also be accessed by get_framegrabber_param.

	'do_comm_read_int'		[int1,...,intN]		Reads the N number of bytes set by read_buf_size from an open comm port. This command will return when the read_buf_size of bytes are available or when the serial timeout period has passed. Upon success, read_buf_size number of bytes will be returned as a tuple of N integer values. In an error case, no data is returned. Note that this parameter allows also the reading of NUL characters.
	'do_comm_read_str'		camera_response		Reads the number of bytes set by read_buf_size from an open comm port. This command will return when the read_buf_size of bytes are available or when the serial timeout period has passed. Upon success, read_buf_size number of bytes will be returned as a string. In an error case, no data is returned.
	'hardware_exception_count'		num		Query the number of hardware exceptions that have occured.
	'in:X'		'high', 'low'		Query the desired state of one of the digital input lines (with X = 0 for a RoadRunner, X = 1 or 2 for a RoadRunner CL, X = 0, 1, 2, or 3 for a Raven and X = 0, 1, 2, 3 or 4 for a R64 board).
	'overflow_count'		num		Query the number of overflows that have occured.
	'revision'		revision		The revision number of the HALCON BitFlow interface.

It is possible to connect more than one camera to a BitFlow board. You will need specific camera configuration files to do this, which have to be installed in your system with the BitFlow configuration program SysReg (please contact BitFlow for details). SysReg attaches a number to each camera (starting with 0). This number is used as port parameter in the HALCON interface. To access a specific camera, you have to specify the corresponding port. This setting can be changed dynamically using the operator set_framegrabber_param() (port switching). However, in this case the used cameras must be compatible, that is of the same type or with similar features (if in doubt please contact your local vendor or BitFlow).

With this mechanism you can access multiple cameras with one frame grabber handle. Note that a pending asynchronous job is aborted when changing the port. Therefore, it does not make much sense to use grab_image_async() in combination with port switching. Please note further the simple HDevelop example program bitflow_2ports.dev you will find in %HALCONROOT%\examples\hdevelop\Image\Framegrabber.

The continuous grabbing mode is used for completely asynchronous grabbing with or without external triggering: If you activate this mode via set_framegrabber_param(FGHandle,'continuous_grabbing','enable') images will be acquired (with each trigger if triggering is enabled) and stored in N buffers in a cyclic way without any additional explicit software trigger like grab_image(). Thus, your HALCON application can process other data without loosing a frame. This is, for example, very useful for the acquisition of images under specific lighting conditions which are triggered by a sequence controller with a fixed timing. In continuous grabbing mode both grab_image() and grab_image_async() simply will return the next frame (or wait if it has not been acquired so far). Note that with the standard asynchronous grabbing there can only be one grab job pending. Thus, you can only acquire one frame in parallel to processing, e.g., the previous frame. Now you can acquire N frames in parallel with N between 2 and 40 (as specified with the parameter 'num_buffers'). Note that you have to specify the desired number of buffers via set_framegrabber_param('num_buffers') before enabling the continuous grabbing mode!

In this continuous grabbing mode you might encounter situations where the images are acquired at a faster rate than they are read by your application. Thus, the N buffers will fill up and finally you will encounter a buffer that was not read so far, but should be overwritten by the next frame. You can decide what to do in this situation via the parameter 'overwrite_method':

• 'abort': Before overwriting any frame, abort the acquisition. This is the most safe method. The main user will be able to process any good buffers still in the system before an error is returned.
• 'holdoff': Hold off acquisition until a buffer is free. This will result in loosing one or more frames, but allows the processing and acquisition to continue.
• 'ignore': Ignore the problem and overwrite the buffer. Thus, some of the older frames that already have been acquired (but not processed so far) will be lost.

It is possible to grab images simultaneously from multiple (up to 4) synchronized cameras. To do so, you will need a special camera file that sets up the board to transfer the n images to memory as one big image with the individual images stacked atop each other. For example, if you want to grab two images of size 640x480 simultaneously, your camera file must be set up to transfer an image of size 640x960 to memory, where the image of the first camera is contained in the first 480 lines of the large image and the image of the second camera is contained in the second 480 lines of the large image. In your application, you need to call set_framegrabber_param(FGHandle,'num_simultaneous_cameras', n), where n is the number of simultaneous cameras, e.g., 2 in the above example. With this, the HALCON interface will return a multi-channel image with each grab, e.g., a two-channel image in the above example. The individual images can be obtained by calling decompose2(), decompose3(), or decompose4(), depending on how many images are grabbed simultaneously.

Note that simultaneous grabbing is not supported in 24 bit per pixel mode.

• Revision 2.8 (November 24, 2004):
  
  • The serial communication with CameraLink cameras now supports the reading and writing of NUL characters. Thus, the parameter 'do_comm_write' accepts also a tuple of integer values. Furthermore, the parameter 'do_comm_read' has been split into the two new parameters 'do_comm_read_str' and 'do_comm_read_int' to allow the reading of strings as well as the reading of integer tuples.
  • The maximum number of used frame buffers has been increased to 1000.
• Revision 2.7 (August 30, 2004):
  
  • New parameters 'overflow_thread', 'hardware_exception_thread', 'overflow_count', and 'hardware_exception_count' to reset acquisition in continuous grab mode when there is a hardware or overflow exception.
  • New parameters 'do_comm_param', 'do_comm_open', 'do_comm_close', 'do_comm_write', 'do_comm_read', 'do_comm_flush', and 'read_buf_size' to control the serial communication with CameraLink cameras.
• Revision 2.6 (July 25, 2003):
  
  • Adaptation to the new BitFlow SDK 4.00 with support of the new R64 boards.
• Revision 2.5 (November 19, 2002):
  
  • New parameter 'in:X' to query the state of the digital input lines (GPIN).
• Revision 2.4 (July 4, 2002):
  
  • Adaptation to the new BitFlow SDK 3.00 with support of the new R3 and R3-CL boards.
  • New parameter 'resnap' to enable a second grab in case of an overflow.
• Revision 2.3 (August 30, 2001):
  
  • HALCON 6.1 version of the interface (included in HALCON 6.1 CD).
  • Bugfix in open_framegrabberi together with multi processor machines.
  • Bugfix forces correct LUT setting with model 11 RoadRunner boards.
• Revision 2.2 (June 8, 2001):
  
  • Adaptation to the new BitFlow SDK 2.50. Older revisions are no longer supported!
  • Support of start/stop trigger mode (for line scan cameras connected to RoadRunner or RoadRunner CL boards).
  • Dynamically changing the frame size of the grabbed image via set_framegrabber_param().
  • Default value of parameter 'overwrite_method' changed from 'abort' to 'holdoff'.
• Revision 2.1 (November 24, 2000):
  
  • Bugfix in overriding the BitsPerChannel parameter during open_framegrabber
  • Automatic enabling of GPOUT when set_framegrabber_param('out:X') is called (regardless of the settings in the camera file).
• Revision 2.0 (November 14, 2000):
  
  • Adaptation to the HALCON 6.0 frame grabber interface.
• Revision 1.2 (November 10, 2000):
  
  • Bugfix in masking the LUT when using a 10 bit camera.
  • Bugfix in continuous mode together with external triggering.
  • Bugfix in cleaning up after an unsuccessful call of open_framegrabber
  • Bugfix in switching between connected cameras.
• Revision 1.1 (October 27, 2000):
  
  • Adaptation to the new BitFlow SDK 2.10. Older revisions are no longer supported!
  • In contrast to the old HALCON RoadRunner and HALCON Raven interfaces the special long frame mode is no longer necessary. Therefore, the parameters 'long_frames', 'long_frame_size', and 'qtab_part' are no longer supported.