Matrox Corona-II

Chapter 1: Matrox Corona-II

This chapter discusses features of MIL that are particular to the Matrox Corona-II board and ways that optimize the board's performance. Board-specific information regarding specific functions is integrated into the functions' reference topics. Refer to the milcor_II.txt file in the \Matrox Imaging\MIL\doc (or user-specified) folder for any additions/modifications to the board specific notes in this chapter or in the MIL Reference.

  • Matrox Corona-II-specific features
    • Acquisition features
    • Display features
    • Other features
  • Using Matrox Corona-II with MIL
  • Cameras that can be connected to Matrox Corona-II
  • Using the encoder
  • User-defined signals for Matrox Corona-II
    • Controlling and inquiring about user-defined signals
  • Matrox Corona-II board flow diagrams


Matrox Corona-II-specific features

Next

Acquisition features

Matrox Corona-II is a PCI frame grabber that is capable of switching between two component RGB, or up to six monochrome standard or non-standard area scan video sources. In addition, when using the optional companion digital-input board, Matrox Corona-II can acquire either RS-422 or LVDS digital video, depending on which companion board is purchased. When grabbing monochrome analog data, Matrox Corona-II can acquire 8 or 10-bit monochrome data. Matrox Corona-II has an integrated RGB-to-YUV color space converter that converts 24-bit RGB video data to YUV16. Matrox Corona-II has a configurable lookup table (LUT). For analog and digital data, the LUT can be configured as triple 256 x 8-bit or a dual 1024 x 16-bit LUT. This allows you to map up to 3 x 8-bit or 2 x 10-bit input through the LUT. For all other inputs (12-, 14-, or 16-bit digital data), the LUT is not available.

Display features

With its MGA G400 graphics controller and 32-Mbyte frame buffer (display memory), Matrox Corona-II can deliver a true color (32-bit) image display with a 32-bit color overlay, for a completely true-color display at up to 1280x1024 resolution; the maximum refresh rate is 75 Hz, depending on your monitor. Matrox Corona-II can configure the overlay frame buffer (display memory used for the Windows desktop) in 8-bit monochrome format or 32-bit RGB format (BGR32 packed), thereby supporting either of these display resolution formats. In addition, Matrox Corona-II features non-destructive graphics overlay, and support for video-in-a-window with arbitrary video scaling (up or down). Since the display section is controlled by the MGA G400 chip, Matrox Corona-II features DualHead display technology, which provides the ability to simultaneously have an independent analog VGA output and a DVI-compliant digital VGA output, or an analog VGA output and encoder output to devices such as an NTSC/PAL/RGB TV or VCR.

Note that if you use the optional piggyback DVI flat-panel module, the video encoder cannot be used.

Other features

Matrox Corona-II also features an on-board UART (Universal Asynchronous Receiver/Transmitter) that provides an RS-232 serial interface. This allows you to remotely control a camera (gain, gamma, control, and operation mode) or a motion control unit, or communicate with a program logic controller (PLC).

Matrox Corona-II can be used as a hardware fingerprint for run-time licenses.


Using Matrox Corona-II with MIL

See Also | Previous | Next
Reference:
MsysAlloc

To use your Matrox Corona-II board with MIL, you must allocate a MIL Corona-II system (M_SYSTEM_CORONA_II), using MsysAlloc(). This allocation opens communication with the Matrox Corona-II board and allows MIL to use its resources. You can run only one process (executable) on a Matrox Corona-II board. The process can allocate a system for this board only once.

Refer to the MILCor_II.txt file in the \Matrox Imaging\MIL\doc (or user-specified) directory for any additions/modifications to these board specific notes.

SYSTEM CORONA II


Cameras that can be connected to Matrox Corona-II

Reference:
MdigChannel

The following types of camera can be connected to Matrox Corona-II. You can switch the grab between cameras of the same type using MdigChannel().

Type of camera | Number supported
RGB | 2
Monochrome | 6
Digital | 1


Using the encoder

Previous | Next

Matrox Corona-II's display section features an on-board encoder. The video encoder can be programmed to output composite (CVBS) and component (Y/C) video in NTSC/PAL formats. It can also output component RGB video with the same resolution and refresh rate as video in NTSC/PAL formats. To output from the encoder, use an auxiliary display with an encoder-supported output format. On Matrox Corona-II, the overlay buffer associated with such an auxiliary display will be driven by the graphics controller.

Note that during a continuous grab, the display is non-tearing.


User-defined signals for Matrox Corona-II

Reference:
MdigControl
MdigInquire

Matrox Corona-II supports user-defined signals for synchronizing with or controlling other devices, such as a strobe light.

The relationship between the MIL user-defined signal numbers and the actual user-defined signals on the video input/output connector of the main board, and on the video input connector of the companion digital-input board, are as follows:

MIL user-defined signal # | I/O | Main board video input connector signal | Digital-input board video input connector signal
1 | I | TTL USER1IN signal. |
2 | I | TTL USER2IN signal. |
3 | O | TTL USER1OUT signal. |
4 | O | TTL USER2OUT signal. |
5 | O |  | RS-422 USEROUT0 signal.
6 | O |  | RS-422 USEROUT1 signal.
7 | I |  | RS-422 USERIN0 signal.
8 | I |  | RS-422 USERIN1 signal.
9 | O |  | TTL USER3OUT signal.
10 | O |  | TTL USER4OUT signal.

There is no user-defined signal 0 for this board.

Controlling and inquiring about user-defined signals

To control or inquire about user-defined signals on Matrox Corona-II, you need to use the M_USER_BIT_... control types or inquire types of MdigControl() and MdigInquire(), respectively.

You can set the state (on/off) of the user-defined output signals using MdigControl() with M_USER_BIT_VALUE. In addition, you can inquire about the state of the user-defined input and output signals using MdigInquire() with M_USER_BIT_VALUE.

USER BIT VALUE USER BIT VALUE


Matrox Corona-II board flow diagrams

Previous

This section contains the data flow diagram for Matrox Corona-II board.


Matrox CronosPlus

Chapter 2: Matrox CronosPlus

This chapter discusses features of MIL that are particular to the Matrox CronosPlus board and ways that optimize the board's performance. Board-specific information regarding specific functions is integrated into the functions' reference topics. Refer to the milcronos.txt file in the \Matrox Imaging\MIL\doc (or user-specified) folder for any additions/modifications to the board specific notes in this chapter or in the MIL Reference.

  • Matrox CronosPlus-specific features
  • Using Matrox CronosPlus with MIL
  • Cameras that can be connected to Matrox CronosPlus
    • Internal Buffers
  • User-defined signals for Matrox CronosPlus
    • Controlling and inquiring about user-defined signals
    • Interruptible user-defined signal
  • Matrox CronosPlus board flow diagrams


Matrox CronosPlus-specific features

Next

Matrox CronosPlus is a frame grabber capable of acquiring standard monochrome video in RS-170/CCIR format, and composite (CVBS) and component (Y/C) color video in NTSC/PAL format. The Matrox CronosPlus board can switch between a maximum of four monochrome/composite cameras.

It can be used as a hardware fingerprint for run-time licenses.

Matrox CronosPlus supports Windows 2000/XP.


Using Matrox CronosPlus with MIL

Reference:
MsysAlloc

To use your Matrox CronosPlus board with MIL, allocate a CronosPlus system (M_SYSTEM_CRONOSPLUS), using MsysAlloc(). This allocation opens communication with the Matrox CronosPlus board and allows MIL to use its resources. You can run only one process (executable) on a Matrox CronosPlus board. The process can allocate a system for this board only once.

Refer to the MilCronosPlus.txt file in the \Matrox Imaging\MIL\doc (or user-specified) directory for any additions/modifications to these board specific notes.

SYSTEM CRONOSPLUS


Cameras that can be connected to Matrox CronosPlus

Reference:
MdigChannel
MdigControl

The following types of camera can be connected to Matrox CronosPlus. You can switch the grab between cameras of the same type using MdigChannel().

Type of camera | Number supported
Composite color/monochrome | 4
Y/C | 1

Internal Buffers

Matrox CronosPlus uses an internal FIFO to buffer image data while waiting to access the PCI bus; therefore image data could be lost due to long bus-access latencies found in heavily loaded systems. When the PCI bus is extremely loaded, Matrox CronosPlus might not be able to empty the FIFO when required. This problem causes an acquisition error known as a "Data transfer error (FIFO overflow)". A way to reduce the occurrence of this error is to grab into a M_YUV16 packed buffer instead of a M_BGR24 or M_BGR32 buffer. Using an AGP graphics controller for display instead of a PCI graphics controller will also reduce the PCI load. Alternatively, when an error occurs, the driver will restart the grab as many times as you specify using MdigControl() with M_GRAB_FAIL_RETRY_NUMBER.

YUV16 BGR24 BGR32 GRAB FAIL RETRY NUMBER


User-defined signals for Matrox CronosPlus

Reference:
MsysControl
MsysHookFunction
MsysInquire

Matrox CronosPlus supports user-defined signals for synchronizing with or controlling other devices, such as a strobe light.

The relationship between the MIL user-defined signal numbers and the actual user-defined signals on the video input connector are as follows:

MIL user-defined signal # | I/O | Video input connector signal
0 | I | USERBIT0 (TTL only) input signal.¹
1 | I | USERBIT1 (TTL only) input signal.
2 | I | USERBIT2 (TTL only) input signal.
3 | O | USERBIT3 (TTL only) output signal.
4 | O | USERBIT4 (TTL only) output signal.
5 | O | USERBIT5 (TTL only) output signal.
6 | O | USERBIT6 (TTL only) output signal.

¹ Note that only this user-defined signal can cause an interrupt.

Controlling and inquiring about user-defined signals

To control or inquire about user-defined signals on Matrox CronosPlus, you need to use the M_USER_BIT_... control types or inquire types of MsysControl() and MsysInquire(), respectively.

You can set the state (on/off) of the user-defined output signals using MsysControl() with M_USER_BIT_VALUE_OUT. In addition, you can inquire about the state of the user-defined input and output signals using MsysInquire() with M_USER_BIT_VALUE_IN and M_USER_BIT_VALUE_OUT, respectively.

You can control or inquire about either a specific user-defined signal or a group of user-defined signals. For an individual signal, add the MIL user-defined signal number to the control or inquire type. For a group of user-defined signals, add the M_BIT_MASK macro to the control or inquire type; the macro takes a bit-encoded mask value that identifies which user-defined signals to affect. For example, adding M_BIT_MASK(88) affects user-defined signals 3, 4, and 6 since the binary equivalent is equal to 1011000. Note that when controlling a group of user-defined output signals, you must set the control value to a bit-encoded value that specifies the setting for each of the user-defined signals in the group. In addition, when inquiring about a group of user-defined signals, the return value is a bit-encoded value that specifies the current setting of each of the user-defined signals in the group.

Interruptible user-defined signal

To handle user-defined input signals, you can either poll their state or generate an event when they change state. Note that only user-defined signal 0 can generate an event (interrupt). To generate an interrupt when user-defined input signal 0 changes state:

  1. Specify whether user-defined input signal 0 should generate an interrupt upon a rising edge or falling edge, using MsysControl() with M_USER_BIT_INTERRUPT_MODE set to either M_EDGE_RISING or M_EDGE_FALLING.
  2. Enable the interrupt state for user-defined signal 0, using MsysControl() with M_USER_BIT_INTERRUPT_STATE.
  3. Hook a function to the change in state of user-defined input signal 0, using MsysHookFunction() with M_USER_BIT_CHANGE.
USER BIT VALUE OUT USER BIT VALUE IN USER BIT VALUE OUT BIT MASK USER BIT INTERRUPT MODE EDGE RISING EDGE FALLING USER BIT INTERRUPT STATE USER BIT CHANGE


Matrox CronosPlus board flow diagrams

Previous

This section contains the data flow diagram for a Matrox CronosPlus board.


Matrox Genesis

Chapter 3: Matrox Genesis

This chapter discusses features of MIL that are particular to the different Matrox Genesis boards and ways that optimize each board's performance. Board-specific information regarding specific functions is integrated into the functions' reference topics. Refer to the milgen.txt file in the \Matrox Imaging\MIL\doc (or user-specified) folder for any additions/modifications to the board specific notes in this chapter or in the MIL Reference.

  • Matrox Genesis-specific features
  • Using Matrox Genesis with MIL
  • Cameras that can be connected to Matrox Genesis
  • Grabbing to a Host image with Matrox Genesis-LC
    • Optimizing the use of the frame buffers
    • Increasing the default temporary buffer size
    • Grabbing in on-board images
    • Grabbing large frames of data
    • Monochrome display
    • An example
    • Color display
    • Other options
  • COM ports and UARTS
  • Processing operations
    • Host-recommended processing
  • User-defined signals for Matrox Genesis
    • Controlling and inquiring about user-defined signals
  • Matrox Genesis board flow diagrams
    • Genesis
    • Genesis LC


Matrox Genesis-specific features

Next

The Matrox Genesis family consists of two types of configurable, single-slot, PCI imaging boards: the Matrox Genesis main board (including Matrox Genesis-LC) and the processor board (including Matrox GenesisPlus).

The Matrox Genesis main board is a single-slot PCI imaging board which integrates acquisition, high-speed processing, and display capabilities. The processing section (also known as a node) includes a Matrox Video Interface ASIC (VIA), Matrox Neighborhood Operations Accelerator (NOA), a Texas Instruments TMS320C80 ('C80) multi-processor, and 64 Mbytes of SDRAM for local processing. The main board has an on-board display section and offers a powerful, integrated grab module. The display section features a 6 Mbyte (color/monochrome) main frame buffer (also referred to as the underlay frame buffer surface). In addition, it has a 2 Mbyte graphics overlay frame buffer (also referred to as the overlay frame buffer surface) for non-destructive overlay capabilities (1600 x 1200 x 8-bit pseudo-color overlay). When the display section is being used to display the Windows desktop, the display format of the on-screen portion of the frame buffers is set using the selected Windows display resolution. The resolution is the same for both the underlay and overlay frame buffers. When the display section is being used for auxiliary displays, the display format is set when allocating the display.

Matrox Genesis-LC is the cost-sensitive version of the Matrox Genesis main board. This board performs all the acquisition and display functions of the main board, but does not have a processing section (node).

The Matrox Genesis processor board is a board that is dedicated to processing. It is available with either one or two processing nodes. It does not include a grab module or a display section.

Matrox GenesisPlus is an upgraded processor board. Each node includes a VIA, a NOA, a Motorola G4 Power PC microprocessor, and 128 or 256 Mbytes of SDRAM.

Several Matrox Genesis boards can be connected to each other by their grab ports and by their VMChannel, allowing high-speed accesses to each other's resources without accessing the primary PCI bus. For example, with multiple processor boards, images can be sent to and processed by all nodes, increasing the speed of all required processing operations.

Note that the Matrox Genesis board cannot be used as a fingerprint for run-time licenses.

MIL documentation generally refers to all Matrox Genesis boards as Matrox Genesis. When it is necessary to distinguish between the Matrox Genesis boards, the manual refers to the Main Board or the Processor Board. In addition, it generally does not explicitly refer to Matrox Genesis-LC, because a discussion of the main board also applies to the Matrox Genesis-LC, excluding any discussion of the processing section.


Using Matrox Genesis with MIL

Reference:
MsysAlloc

To use a Matrox Genesis-LC board, or a node on a Main or Processor Board, you must allocate it as a Genesis system (M_SYSTEM_GENESIS), using MsysAlloc(). This allocation opens communication with the Matrox Genesis board and allows MIL to use its resources. You can run multiple processes (executables) on the same board simultaneously. Each process can have one allocated system.

When Matrox Genesis boards are interconnected, they form a cluster. Each Matrox Genesis board in a cluster must still be allocated separately. MIL will automatically detect the interconnection. If you have several Matrox Genesis boards connected together (forming a cluster), you must allocate the boards in that cluster in sequential order, starting with board 0. For example, if you have a two board cluster, you cannot allocate board 1 before you have allocated board 0. When the boards are not connected together, they can be allocated in any order.

For auxiliary displays, the Matrox Genesis will only use its on-board display section.

When using a Processor Board, or when using a node that cannot access Matrox Genesis' display section without accessing the primary PCI bus, MIL will use not only the board/node's resources and Host computer memory, but also the VGA board. Use of the VGA board has been included to allow you to display grabbed images.

SYSTEM GENESIS


Cameras that can be connected to Matrox Genesis

Reference:
MdigChannel

The following types of cameras can be connected to Matrox Genesis. You can switch the grab between cameras of the same type using MdigChannel().

Type of camera | Number supported
Monochrome 8-bit | 4
Digital 2-tap 8-bit or 16-bit | 2
RGB 8-bitm 24-bit or 2-tap 16-bit analog | 1
4-tap or 32-bit | 1


Grabbing to a Host image with Matrox Genesis-LC

Reference:
MbufAllocColor
MbufCreate2d
MsysControl
MsysInquire

When grabbing to a Host image, Matrox Genesis-LC uses off-screen frame buffer memory (that is, frame buffer memory that is not configured for display purposes) as a FIFO, to buffer image data while the board waits for access to the PCI bus. Loss of image data could otherwise occur during long bus-access latencies, found in heavily loaded systems.

Matrox Genesis-LC uses hardware/software transfer control logic to double-buffer the grab between two temporary buffers set up in off-screen memory. This logic toggles the grab between one temporary buffer and the other, transferring grabbed data from the buffer in which data is not being grabbed to the Host. The double-buffering is done on a line-block basis rather than on a frame basis.

In general, the default size of the temporary buffers provides a good compromise between maintaining a small latency before the beginning of the transfer and minimizing the transfer's dependency on the PCI bus load. However, when the PCI bus is extremely loaded, the Matrox Genesis-LC board might not be able to maintain the grab and transfer sequence. If the request to transfer is not serviced in time, the grab might overwrite non-transferred data. This is known as a grab over-run.

For example, a typical load on the PCI bus is that of the Matrox Genesis-LC grabbing to a Host image while the Host is updating the Matrox Genesis-LC's display. When updating the GUI (for windowed displays) and/or the display of grabbed and processed images, the display updates are frequent. This bi-directional traffic might increase the latency in servicing the request to write grabbed data to Host memory. At some point, the accumulated latencies might cause a grab over-run.

Optimizing the use of the frame buffers

If you experience grab over-runs, try the following solutions in the specified order:

  1. Increase the default temporary buffer size. This should be enough to resolve your problems. See the section below.
  2. If possible, double-buffer the grab on a frame basis rather than a line-block basis. In this case, you have to manage the double-buffering of the grab yourself. This method involves one frame of latency before the beginning of the transfer.
  3. Reduce the display resolution or, if possible, reduce the PCI bus load.

Increasing the default temporary buffer size

You can increase the default temporary buffer size. Larger temporary buffers make the grab's transfer-to-Host less dependent on the PCI bus load. That is, the grab is less affected by long bus-access latencies, found in heavily loaded systems, because more memory is available to buffer the data. Note, however, that larger temporary buffers also increase the latency before the beginning of the transfer.

The maximum size of each temporary buffer is limited by the amount of off-screen memory divided by three:

max temp buffer size = off-screen memory / 3

The amount of off-screen frame buffer memory is determined by the amount of frame buffer memory that is not configured for display purposes. Decreasing the display resolution increases the amount of off-screen memory.

The amount of off-screen memory per frame buffer plane is determined as follows:

off-screen memory/plane = 2 Mbytes - (w * h)

where w and h are the width and height of the selected display resolution.

The following table lists the amount of off-screen memory available for some typical display resolutions, as well as the maximum temporary buffer size for each resolution.

Display Resolution | Bytes of off-screen memory/plan | Maximum temporary buffer size
640 x 480 | 1789952 | 596650
800 x 600 | 1617152 | 539050
1024 x 768 | 1310720 | 436906
1280 x 1024 | 786432 | 262144
1600 x 1200 | 177152 | 59050

You can increase the default temporary buffer size by adjusting the SizeOfTmpBufferForHostGrab field in the genesis.ini file.

Grabbing in on-board images

If increasing the size of the temporary buffers does not resolve your over-run problem, you can try double-buffering the grab on a frame basis rather than a line-block basis. The grab is then less dependent on the PCI bus load because the data does not have to be transferred as frequently and intermittent bus latencies are averaged over an entire frame. The downside of this process is that there is one frame of latency before the beginning of the transfer.

To implement this model, you have to manage the double-buffering. To do so, create two frame-sized images on-board and then grab a field/frame into one image while copying the other image to the Host. Since you control the synchronization between the grab and transfer, you can detect when something goes wrong.

Note that, by default, the copy operation is driven by the Host CPU. To speed up the copy and reduce Host intervention, enable VIA-driven copies by setting the MsysControl() M_BUS_MASTER_COPY_TO_HOST control to M_ENABLE.

This method is only possible if sufficient on-board memory is available to create the two images.

Grabbing large frames of data

When grabbing large frames of data (for example, 2K X 2K and 4K X 4K), there is no way to store the whole frame in frame buffer memory. In this case, you can only grab to a Host image. However, if you are experiencing over-runs using this method, try the suggestions in the Other options subsection in this section.

Monochrome display

When the frame buffers are in an 8-bit (monochrome) display resolution, an area of only one frame buffer plane is used to maintain the display. In this case, sufficient memory is available to keep two entire average-sized frames on-board.

Although an area of only one frame buffer plane is actually used to maintain the display, MIL reserves the corresponding area of the two other frame buffer planes so that you can switch between a monochrome and color display without corrupting off-screen memory.

This means that if you try to allocate the buffers with an M_ON_BOARD attribute, there might not be sufficient true off-screen memory to allocate the entire buffer. Instead, you might need to allocate the grab buffers in the reserved frame buffer memory. To do so, inquire the address of the underlay frame buffer using MsysInquire(), and then, using MbufCreate2d(), create your two buffers at the appropriate offset (that is, 0, 2, or 4 Mbytes).

If you create images in reserved display memory, you cannot switch to color mode or select a color image on the display; otherwise, the grab images will be corrupted.

An example

The following example shows how to allocate buffers in reserved display memory and then grab in these buffers.

mgenlc.c

Color display

When the frame buffers are in a 24-bit (color) display resolution, the three frame buffer planes are used to maintain the display. In this case, off-screen memory is the only memory available in which to perform double-buffering without affecting the display.

In a 1024 x 768 display resolution, there is 1310720 bytes of off-screen memory/plane available for a double buffering scheme. If, for example, your camera is a 512 x 480 RGB source, only 737280 (512 x 480 x 3) bytes are required to buffer one frame. So, you can allocate the buffers in the off-screen memory of two planes. Since you need to allocate the buffers in off-screen memory, simply allocate the buffers with MbufAllocColor() and use the M_ON_BOARD flag; the buffers will automatically be allocated in the appropriate off-screen memory.

When grabbing larger frames of data or when displaying in a higher resolution, the previous method might not be suitable. For example:

Display | Camera | Bytes missing in off-screen memory
1280 x 1024 | 1K x 1K monochrome source | 262,144
1600 x 1200 | 1K x 1K monochrome source | 871,424
1600 x 1200 | 512 x 480 monochrome source 68,608 | 68,608

In these cases, the only way to achieve the grab is to use off-screen memory as a FIFO and grab into a Host image. However, if you are experiencing over-runs using this method, try the suggestions in the following subsection.

Other options

In the unlikely event that the previous two suggestions do not resolve grab over-runs, you have the following options:

  • You can try reducing the display resolution. This reduces the PCI bus load because there is less to update, and it increases the amount of off-screen memory so you can create larger temporary buffers.
  • If your application permits, use other methods to reduce the PCI bus load. For example, reduce the number of display updates of the processed grabbed image; this, however, involves manual intervention.
BUS MASTER COPY TO HOST ENABLE ON BOARD ON BOARD


COM ports and UARTS

Reference:
MdigControl

Matrox Genesis offers RS-232 compatible serial interfaces (each controlled by a UART). Each interface is mapped as a COM port so that it can be accessed through the Microsoft Windows API. Use the Microsoft Win32 library, the manufacturer's Camera configuration application to access and control the serial ports. Alternately, MIL can control and access the serial ports (use MdigControl() with M_UART...). To view them in a Microsoft Windows operating system, refer to Microsoft Window's device manager, under Ports (COM & LPT). Camera Link Cameras are also visible to the manufacture's camera configuration application that support the Camera Link standard. For more information, refer to the Matrox Genesis Installation and Hardware Reference manual.


Processing operations

Reference:
MappControl
MbufBayer
MbufCopyCond
MdigFocus
MgenWarpParameter
MimArith
MimArithMultiple
MimBinarize
MimClip
MimConnectMap
MimConvert
MimConvolve
MimCountDifference
MimDilate
MimDistance
MimEdgeDetect
MimErode
MimFindExtreme
MimFlip
MimHistogram
MimLabel
MimLocateEvent
MimLutMap
MimMorphic
MimProject
MimRank
MimResize
MimRotate
MimShift
MimThick
MimThin
MimTransform
MimTranslate

Most of MIL's processing operations are performed by the on-board Matrox Genesis processor when a Genesis system is specified. Exceptions are listed in one of two categories:

  • Host-recommended processing. Processing operations that are performed by the Host processor rather than the on-board processor.
  • Host-specific processing. Processing operations that cannot be done by the on-board processor and must be done by a specified system other than Matrox Genesis. These operations are denoted in their reference description as not being supported on Matrox Genesis.

Host-recommended processing

There are some processing operations that, although you specified that they should be performed by a Genesis system (the on-board processor), they will be performed by the Host processor instead. This occurs for one of two reasons: in some cases, operations can be performed more efficiently using the Host; in other cases, the on-board processor is not set up to perform the operation. You can force Matrox Genesis to process the operation by setting MappControl() with M_PROCESSING to M_COMPENSATION_DISABLE. In this case, each time Matrox Genesis is unable to perform an operation, an error message is produced.

Note also that functions dealing with JPEG2000 compressed buffers will be performed by the Host (the functions are not included in the following list).

The following is a list of functions under which their operations will be performed by the Host (by default), instead of the on-board processor:

  • MbufBayer().
  • MimArith() with M_CONST_DIV + M_FIXED_POINT.
  • MimConvert() with M_RGB_TO_Y.
  • MimResize() or MimRotate() with M_OVERSCAN_DISABLE.

The following is a list of functions that, under certain conditions only, are performed by the Host:

  • MbufCopyCond() is performed by the Host if it uses floating point buffers.
  • MdigFocus() is performed by the Host only when the destination buffer has a depth of 1-bit.
  • MgenWarpParameter() is performed by the Host only when 32-bit LUT buffers are used.
  • MimArith() with (M_ADD, M_SUB, M_ADD_CONST, M_SUB_CONST, M_CONST_SUB or M_SUB_ABS) + M_SATURATION is performed by the Host under the following conditions:
    • Whenever floating-point buffers are used.
    • Whenever a mix of 32-bit buffer types are used.
  • MimArith() with (M_DIV or M_DIV_CONST) + M_FIXED_POINT is performed by the Host under the following conditions:
    • If either source is 32-bit.
    • If the source is 8-bit and the destination is 32-bit.
  • MimArithMultiple() with M_OFFSET_GAIN or M_WEIGHTED_AVERAGE is performed by the Host under the following conditions:
    • If it uses 32-bit buffers.
    • If one of the buffers is signed.
    • If the destination buffer's depth is equal or less than that of the source buffer.
    • If the source buffers are of different types.
  • MimArithMultiple() with M_MULTIPLY_ACCUMULATE_1 is performed by the Host if it uses 32-bit integer buffers.
  • MimArithMultiple() with M_MULTIPLY_ACCUMULATE_2 is performed by the Host under the following conditions:
    • If it uses 32-bit integer buffers.
    • If one source buffer is signed and the other is unsigned.
  • MimArithMultiple() with (M_MULTIPLY_ACCUMULATE_1 or M_MULTIPLY_ACCUMULATE_2) + M_SATURATION is performed by the Host if it uses float buffers.
  • MimBinarize(), MimClip(), MimCountDifference(), and MimLocateEvent() are performed by the Host if they use float buffers.
  • MimConnectMap(), MimDilate(), MimDistance(), MimErode(), MimThin(), MimThick(), and MimLabel() are performed by the Host if they use buffers with a depth greater than 16 bits.
  • MimConvolve() is performed by the Host under any one of the following conditions:
    • When using an IIR filter
    • If the source or destination buffer has a depth of 1 bit or greater than 16 bits.
    • If float buffers are used.
    • If the NOA is disabled and the kernel is larger than 15x15.

      • Note that the maximum kernel size can be as large as 31x31 if all the following conditions are met:

      • The source buffer is unsigned 8-bit.
      • The destination buffer is 8- or 16-bit.
      • The kernel is signed 8-bit [-128, +127].
    • If the NOA is enabled and any of the following conditions are met:
      • The kernel width or height is greater than 33.

        • Note that the following are exceptions to the above rule.

        • If both the image and kernel are 8-bit, then the kernel width can be a maximum of 64. The kernel height is still limited to 33.
        • If the kernel is 1xN (the width equals 1) then the maximum kernel height is 64.
      • The total number of kernel elements exceeds 1024 and the kernel data is 8-bit or exceeds 521 and the kernel data is 16-bit.
  • MimEdgeDetect() is performed by the Host:
    • Except with M_FAST_EDGE_DETECT, M_FAST_ANGLE+M_FAST_GRADIENT, or M_REGULAR_ANGLE + M_FAST_GRADIENT.
    • If the buffers have a depth greater than 16 bits.
  • MimFindExtreme() is performed by the Host when dealing with float buffers.
  • MimFlip() is performed by the Host under the following conditions:
    • When dealing with float buffers.
    • The source and destination buffers have different depths.
  • MimHistogram() is performed by the Host under the following conditions:
    • When dealing with float buffers.
    • When dealing with source buffers with depths greater than 16 bits.
  • MimLutMap() is performed by the Host under the following conditions:
    • When dealing with float buffers.
    • When dealing with a 32-bit source buffer.
    • When dealing with a 32-bit signed destination buffer.
  • MimMorphic() is performed by the Host whenever dealing with buffers with a depth greater than 16 bits.
  • MimMorphic() with M_ERODE is performed by the Host if structuring elements exceed 15x15 in size.
  • MimMorphic() with M_DILATE is performed by the Host if structuring elements exceed 15x15 in size.
  • MimMorphic() with M_THIN is performed by the Host if grayscale structuring elements are not 3x3 in size or if binary structuring elements exceed 15x15 in size.
  • MimMorphic() with M_THICK is performed by the Host if grayscale structuring elements are not 3x3 in size or if binary structuring elements exceed 15x15 in size.
  • MimMorphic() with M_HIT_OR_MISS is performed by the Host under the following conditions:
    • When dealing with grayscale structuring elements that are not 3x3 in size.
    • When dealing with binary structuring elements exceeding 15x15 in size.
  • MimProject() is performed by the Host under the following conditions:
    • When dealing with float buffers.
    • When dealing with 32-bit source buffers.
  • MimRank() is performed by the Host under the following conditions:
    • When dealing with any structuring elements that are not predefined.
    • When the rank is not minimum, maximum or M_MEDIAN.
    • When buffers have a depth greater than 16 bits.
  • MimResize() is performed by the Host under the following conditions:
    • When dealing with float buffers.
    • When the interpolation mode is either M_BILINEAR or M_BICUBIC and you are using 32-bit source buffers.
    • When the source buffer is 32-bit and the destination buffer is 1-bit or vice-versa.
  • MimRotate() is performed by the Host under the following conditions:
    • When dealing with float buffers.
    • When the interpolation mode is either M_BILINEAR or M_BICUBIC and you are using 32-bit source buffers.
    • When the source buffer is 32-bit and the destination buffer is 1-bit or vice-versa.
  • MimShift() is performed by the Host when dealing with float buffers.
  • MimTransform() is performed by the Host except when performing an M_FFT operation on 32-bit signed buffers and the DC component is not centered (the M_CENTER flag is not used).
  • MimTranslate() is performed by the Host for fractional X or Y displacement when source and/or destination buffers have a depth of 1 bit or greater than 16 bits.
PROCESSING COMPENSATION DISABLE CONST DIV FIXED POINT RGB TO Y OVERSCAN DISABLE ADD SUB ADD CONST SUB CONST CONST SUB SUB ABS SATURATION DIV DIV CONST FIXED POINT OFFSET GAIN WEIGHTED AVERAGE MULTIPLY ACCUMULATE 1 MULTIPLY ACCUMULATE 2 MULTIPLY ACCUMULATE 1 MULTIPLY ACCUMULATE 2 SATURATION FAST EDGE DETECT ERODE DILATE THIN THICK HIT OR MISS MEDIAN BILINEAR BICUBIC BILINEAR BICUBIC FFT CENTER


User-defined signals for Matrox Genesis

Reference:
MdigControl
MdigInquire

Matrox Genesis supports user-defined signals for synchronizing with or controlling other devices, such as a strobe light.

The relationship between the MIL user-defined signal numbers and the actual user-defined signals on the grab module digital port are as follows:

For the companion digital input board:

MIL user-defined signal # | I/O | Grab module digital port
0 | O | USER0 OUTPUT (RS-422 only) signal. ¹
0 | I | USER0 INPUT (RS-422 only) signal.
1 | O | USER1 OUTPUT (RS-422 only) signal.¹
1 | I | USER0 INPUT (RS-422 only) signal.
2 | O | CAMERA CONTROL BIT 0 (TTL only) signal.
3 | O | CAMERA CONTROL BIT 1 (TTL only) signal.
4 | O | CAMERA CONTROL BIT 2 (TTL only) signal.

For the digital cable adapter:

MIL user-defined signal # | I/O | Grab module digital port
0 | O | USER0 OUTPUT (TTL or RS-422) signal.¹
0 | I | USER0 INPUT (TTL or RS-422) signal.
1 | O | USER1 OUTPUT (TTL or RS-422) signal.¹
1 | I | USER0 INPUT (TTL or RS-422) signal.
2 | O | MODULE LOAD OUTPUT (TTL only) signal.
3 | O | MODULE CLOCK OUTPUT (TTL only) signal.
4 | O | MODULE DATA OUTPUT (TTL only) signal.

¹ Note that there are two user-defined signals for user-defined signal 0 and 1. When inquired, the user-defined input signal is returned. When controlled, the user-defined output signal is changed.

Controlling and inquiring about user-defined signals

To control or inquire about user-defined signals on Matrox Genesis, you need to use the M_USER_BIT_... control types or inquire types of MdigControl() and MdigInquire(), respectively.

You can set the state (on/off) of the user-defined output signals using MdigControl() with M_USER_BIT_VALUE. In addition, you can inquire about the state of the user-defined input and output signals using MdigInquire() with M_USER_BIT_VALUE.

USER BIT VALUE USER BIT VALUE


Matrox Genesis board flow diagrams

Previous

This section contains data flow diagrams for all Matrox Genesis boards.

Genesis

The following diagram illustrates the ,ain and processor boards for a Matrox Genesis.

Genesis LC

The following diagram illustrates the data flow of a Genesis LC.

The following diagram illustrates the grab module.


Matrox Helios

Chapter 4: Matrox Helios

This section discusses features of MIL that are distinct to Matrox Helios and ways that optimize the board's performance. Board-specific information regarding specific functions is integrated into the functions' reference topics. Refer to the MilHelios.txt file in the \Matrox Imaging\MIL\doc (or user-specified) folder for any additions/modifications to the board specific notes in this chapter or in the MIL Reference.

  • Matrox Helios-specific features
    • Summary of Matrox Helios features
    • Note on nomenclature
  • Using Matrox Helios with MIL
  • Allocating independent MIL digitizers on Matrox Helios
    • Matrox Helios XA
    • Matrox Helios XCL
  • Preprocessing and formatting grabs with Matrox Helios
    • PA optimizations
      • Real-time PA processing
      • An example
    • Additional processing information
      • Asynchronous and synchronous functionality
      • Multiple CPU computers
      • Running multiple processes and threads
      • Simultaneous actions
    • Bayer conversion
    • Memory
      • Shared memory
  • Minimum latency and grabbing all frames
  • COM ports and UARTS
  • Matrox Helios utilities
    • Matrox Helios Bench
    • Usage Meter
  • User-defined signals for Matrox Helios
    • Camera Link
    • Analog
    • Controlling and inquiring about user-defined signals
    • Interruptible user-defined signals
  • Matrox Helios board flow diagrams
    • Matrox Helios XCL
    • Matrox Helios XA


Matrox Helios-specific features

Next

The Matrox Helios family consists of two PCI-X compliant, single-slot, frame grabbers with powerful preprocessing capabilities: Matrox Helios XCL and Matrox Helios XA.

Matrox Helios XCL is a Camera Link frame grabber. It is available in two factory-configured versions:

  • A dual-Base version. Allows simultaneous acquisition from two independent Camera Link cameras using the Base configuration.
  • A single-Full version. Acquires from a single Camera Link camera using the Base, Medium, or Full configuration.

Matrox Helios XA is a high-performance analog frame grabber, capable of high frequency and high fidelity simultaneous acquisition from up to four cameras.

To reduce the number of the image formatting and preprocessing tasks performed by the Host CPU, both Matrox Helios XCL and XA include the custom Matrox Oasis ASIC and up to 256 Mbytes of processing memory for local processing and buffering. The Matrox Oasis ASIC integrates a pixel accelerator (PA), a main memory controller, and data formatters (Links controller). Using Matrox Oasis, Matrox Helios can preprocess and format grabbed data in on-board buffers before transferring them to the Host.

Summary of Matrox Helios features

The following table outlines the features currently available for each member of the Matrox Helios family.

Matrox Helios | XCL | XA
Matrox Oasis ASIC | Yes | Yes
Memory | 128/256 Mbytes | 128/256 Mbytes
Number of acquisition paths | 1 or 2 | 4
Number of supported triggers | 2/digitizer, 2 that can be shared by all digitizers | 2/digitizer, 2 that can be shared by all digitizers
Asynchronous reset mode support for triggers | Yes | Yes
Exposure timers per digitizer | 2/digitizer | 2/digitizer
Number of supported UARTS | 1/digitizer | 1/digitizer
Number of user-defined signals | (4 out, 4 in, and 3 I/O) /digitizer, 6 that can be shared by all digitizers | (3 out, 4 in) /digitizer, 8 that can be shared by all digitizers
Digitizer LUT | Yes | Yes

Note on nomenclature

This manual refers to all Matrox Helios boards as Matrox Helios. When necessary, it distinguishes between them by using their full name.


Using Matrox Helios with MIL

User Guide:
Multi-processing
Multi-threading

Reference:
MbufCopy
MsysAlloc
MthrControl

To use a Matrox Helios board, you must allocate it as a MIL Helios system (M_SYSTEM_HELIOS), using MsysAlloc(). This allocation opens communication with the Matrox Helios board and allows MIL to use its resources. You can run multiple processes (executables) on the same board simultaneously. Each process can have one allocated system.

To support preprocessing and formatting grabs, supported functions (see HeliosPA.txt) are interpreted on the Host and sent to the Helios for execution. See the Preprocessing and formatting grabs with Matrox Helios section later in this chapter for more information.

Refer to the MilHelios.txt file in the \Matrox Imaging\MIL\doc directory for any additions/modifications to these board specific notes.

SYSTEM HELIOS


Allocating independent MIL digitizers on Matrox Helios

Reference:
MdigAlloc
MdigChannel

Depending on the frame grabber, you can allocate several independent MIL digitizers. Independent digitizers have different device numbers and use different acquisition paths.

Matrox Helios XA

You can allocate up to 4 independent digitizers on Matrox Helios XA, depending on the cameras connected. The following table lists the acquisition paths and the digitizer's device number to use when connecting asynchronous cameras of different types.

Each acquisition path supports input from one of two sources, therefore all digitizers have 2 data channels. You can switch between them using MdigChannel().

Synchronization signals can either come combined with the data (CSYNC), come along the data input signal of another acquisition path that is not already allocated (external analog synchronization), or come along a signal dedicated for synchronization either on the same acquisition path or another acquisition path (external digital synchronization). Note that using an acquisition path to receive an external analog synchronization signal renders that acquisition path "occupied" and not available for allocating another digitizer on that acquisition path. For example, when allocating a 3-tap (RGB) digitizer on acquisition paths 0, 1, and 2 (using MdigAlloc() with M_DEV0), you can set your synchronization signal on acquisition path 3 (using MdigChannel() with M_CH3 + M_SYNC). This results in acquisition path 3 not being available for allocation for another camera. Alternatively, if using an external digital synchronization signal on acquisition path 3 (by customizing the DCF using Matrox Intellicam), a digitizer for a monochrome camera could be allocated and use M_DEV3 simultaneously.

Matrox Helios XCL

The number of independent digitizers that you can allocate on Matrox Helios XCL is determined by the version in use. There are two versions of Matrox Helios XCL available:

  • Single-Full. The single-Full version has only one acquisition path (MdigChannel() with M_DEV0) with only one data channel (M_CH0).
  • Dual-Base. The dual-Base version has two acquisition paths (M_DEV0 and M_DEV1), but each only has one data channel (MdigChannel() with M_CH0).
CH3 + M SYNC CH0 CH0


Preprocessing and formatting grabs with Matrox Helios

User Guide:
Multi-threading
Using buffers with the Bayer color filter

Reference:
MappTimer
MbufBayer
MbufCopy
MbufGet
MdigControl
MdigInquire
MdigProcess
MimFlip
MimResize
MsysControl
MthrControl
MthrWait

Time consuming processing operations, relating to preprocessing and formatting of grabbed data, are best done by Matrox Helios. If data is already on the Host, it is not efficient to transfer the data to Matrox Helios for processing and then transfer it back to the Host.

Refer to the HeliosPA.txt file in the \Matrox Imaging\MIL\DOC directory for a list of the accelerated functions, as well as the latest information on this topic.

PA optimizations

The most efficient way to use the PA is as follows:

  1. Grab to an on-board buffer.
  2. Process the grabbed data on-board. Refer to HeliosPA.txt for a list of available functions.
  3. Copy the on-board buffer to a Host buffer.
  4. Process the Host buffer.

Note that when timing a PA-supported function, you must wait until the function finishes. Use MthrWait() to synchronize benchmarking applications with the end of the function. You should also ensure that you are not in debug mode for best effect.

When processing an on-board buffer (MbufAlloc...() with M_ON_BOARD), most neighborhood operations (including convolutions and morphological operations), point-to-point, and certain statistical functions are accelerated using the PA, included in the Matrox Oasis ASIC. The PA considerably reduces the time required by I/O-intensive operations.

Note that, if even one of the buffers is not allocated on-board, then the function will be performed by the Host. This will result in all the on-board buffers first being transferred to the Host before processing begins. Once the function completes, the data is then transferred back to the on-board buffers. There are, however, 2 exceptions: MimResize() and MimFlip(). These can both have destination buffers on the Host without forcing all associated buffers being transferred to the Host.

When grabbing to an off-board buffer, Matrox Helios uses internal buffering to store image data while formatting data, or waiting to access the PCI bus.

Note that Matrox Helios uses the data formatters, in the Matrox Oasis ASIC, to format grabbed data.

Real-time PA processing

Use MdigProcess() for real-time processing and grabbing. It acquires images and store them sequentially in a list of buffers. It also hooks a user-defined function to the modification of any buffer in the specified list. So every time a new frame is grabbed in a buffer in the list, the user-defined function is called.

MdigProcess() is optimized for Matrox Helios. MdigInquire() returns statistics regarding the frame-rate, missed frames, and the grab period (M_PROCESS_FRAME_...). The Matrox Helios driver queues commands into an interrupt service routine (ISR), giving them a higher execution priority. Note that any synchronous function forces the Host to wait until the function finishes; this stops real-time processing. For more information, refer to the Additional processing information subsection in this section.

An example

The following example shows how to correctly use the PA for image processing.

/*
 * Synopsis : This program shows how to correctly use the PA.
 * It assumes the buffers have been  correctly allocated on-board
 * (MILImageOnboard...) and on host (MILImageOffBoard). After the grab
 * and before being transferred to the host, processing is performed.
*/

/* Allocate buffers in the on-board memory of the Matrox Helios. */
MbufAlloc2d(MilSystem, 1024, 1024, 8 + M_UNSIGNED, M_IMAGE + M_ON_BOARD + M_PROC + M_GRAB,
    &MilImageOnBoardGrab);
MbufAlloc2d(MilSystem, 1024, 1024, 8 + M_UNSIGNED, M_IMAGE + M_ON_BOARD + M_PROC,
    &MilImageOnBoardB);
MbufAlloc2d(MilSystem, 1024, 1024, 8 + M_UNSIGNED, M_IMAGE + M_ON_BOARD + M_PROC,
    &MilImageOnBoardC);
MbufAlloc2d(MilSystem, 1024, 1024, 8 + M_UNSIGNED, M_IMAGE + M_ON_BOARD + M_PROC,
    &MilImageOnBoardOffset);
MbufAlloc2d(MilSystem, 1024, 1024, 8 + M_UNSIGNED, M_IMAGE + M_ON_BOARD + M_PROC,
    &MilImageOnBoardGain);

/* Allocate a bufffer in the Host memory, off board. */
MbufAlloc2d(MilSystem, 1024, 1024, 8 + M_UNSIGNED, M_IMAGE + M_OFF_BOARD + M_PROC + M_NON_PAGED,
    &MilImageOffBoard);

/* Grab an image. */
MdigGrab(MilDigitizer, MilImageOnBoardGrab);

/* When using on-board buffers, the PA is used. This function is asynchronous. */
MimArithMultiple(MilImageOnBoardGrab, MilImageOnBoardOffset, MilImageOnBoardGain,
                 64, M_NULL, MilImageOnBoardB, M_OFFSET_GAIN+M_SATURATION,
                 M_DEFAULT);
MimConvolve(MilImageOnBoardB, MilImageOnBoardC, M_SMOOTH);

/*
 * When transferring the result to the Host, the function is synchronous.
 * When the function returns, all the data is available for processing
 * by the Host CPU.
*/
MbufCopy(MilImageOnBoardC, MilImageOffBoard);

/*
 * If one of the buffers is located on the Host, the whole operation will be
 * done by the Host CPU. The performance will be greatly reduced because all
 * the on-board buffers must be internally transfered to the Host before beginning
 * the processing (MimResize and MimFlip are exceptions).
*/
MimArithMultiple(MilImageOnBoardGrab, MilImageOnBoardOffset, MilImageOnBoardGain,
                 64, M_NULL, MilImageOffBoard, M_OFFSET_GAIN+M_SATURATION,
                 M_DEFAULT);

Additional processing information

Matrox Helios supports both asynchronous and synchronous functionality with multiple Host CPUs and threads. It also allows multi-threading, multi-processing, and simultaneous actions.

Asynchronous and synchronous functionality

Typically a function is executed asynchronously if the following conditions are met:

  • All the associated buffers are allocated on-board.
  • The PA supports the functionality.

    • Refer to the HeliosPA.txt file in the \Matrox Imaging\MIL\DOC directory for a list of the PA supported functions.

  • The function does not have a return value.

To verify that a code segment is executed asynchronously, bench mark the code segment, using MappTimer(). If the amount of time it takes is minimal (for example, each function takes less than 10-20 msecs), then the code segment is asynchronous.

Functions that copy data (such as MbufGet() and MbufCopy()) are synchronous by default. In addition, MimResize() and MimFlip() are synchronous by default if one buffer is allocated on-board and the other is off-board. Note that MbufCopy(), MimResize(), and MimFlip() can all be used asynchronously using MthrControl() with M_BUS_MASTER_COPY_MODE set to M_ASYNCHRONOUS.

Some functions can be performed synchronously if they are configured appropriately (using MthrControl() with M_THREAD_MODE, MdigControl() with M_GRAB_MODE, or MthrWait() with M_EVENT_SYNCHRONIZE).

Multiple CPU computers

On a computer (Host) with multiple CPUs, to assure no frames are lost, a single process can use multiple CPUs to process grabs. This is particularly useful if processing time is longer than it takes to grab a frame (for example, a grab takes 10 msec, but the processing takes 15 msec). To achieve this, hook your processing function to the modification of your grab destination buffers using MdigProcess(), and enable multi-threading using MsysControl() with M_MODIFIED_BUFFER_HOOK_MODE set to M_MULTI_THREAD; the operating system dispatches the entire hooked function on available CPUs, depending on their workload. MIL cannot guarantee the order in which hooked functions are performed on any frame on such a computer because they are executed concurrently. Instead, use Microsoft Windows Win32 functions to synchronize the threads.

Running multiple processes and threads

Several processes (executables) can run simultaneously on Matrox Helios. On-board resources can be shared by different processes. However, multiple processes running at the same time have to share the available processing time, and cannot share data since the memory used by one process is protected from all other processes. MIL applications are autonomous processes and therefore can profit from multi-processing by executing independently.

Multi-threaded applications are possible with Matrox Helios. To control the threads and manage events, use MIL's thread module (Mthr...()). Note that when MIL is running on Matrox Helios, every Host (Windows) thread that sends MIL functions has an equivalent Matrox Helios on-board thread that executes them.

For information on MIL and multi-threading, see the Multi-threading section in Chapter 22: Using MIL with multi-processing and under multi-thread systems of the MIL User Guide.

Simultaneous actions

Matrox Helios can perform grabs, process with the PA, and transfer information to the Host simultaneously, as long as none of these three actions are working with the exact same buffers at the same time. The following example shows how to optimize efficiency in the same thread by grabbing, processing, and transferring information simultaneously.

MHeliosConcurent.c

Bayer conversion

Matrox Helios supports automatic Bayer conversion when grabbing from a camera that has a Bayer color filter (as specified by the DCF). To make use of this feature, use MdigControl() with M_BAYER_CONVERSION enabled. During conversion, the image can be white balanced if white balancing is enabled using MdigControl() with M_WHITE_BALANCE.

The white balance coefficients can be set explicitly using MdigControl() with M_BAYER_COEFFICIENTS_ID or calculated automatically using MdigControl() with M_WHITE_BALANCE set to M_CALCULATE.

The M_BAYER_... control types can only be used when grabbing from a camera that has a Bayer color filter (as specified by the DCF), otherwise an error will be generated.

For a more conventional technique of controlling Bayer conversion, use MbufBayer(). Note that with the more conventional technique, the conversion is not done as data is grabbed. For more information, see the Using buffers with the Bayer color filter section in Chapter 14: Specifying and managing your data buffers.

Memory

By default, all buffers are allocated in off-board memory. If allocated in Host memory, the buffer can be allocated in either paged or non-paged memory. If allocated on-board, the buffer can be allocated in either unshared (the default) or shared memory.

Shared memory

Shared memory is the amount of on-board memory that is visible to the PCI bus. This amount is configurable through MILConfig. When buffers are allocated in shared memory, they have both a physical address and a logical address on the Host. Buffers not allocated in shared memory have neither a physical address recognized by the Host, nor a logical address on the Host, but can still be accessed and used by MIL functions, except MbufCreate...().

Note that you can only use MbufCreate...() with shared or Host memory because it relies on having a physical address recognized by the Host.

Note that buffers allocated on-board Matrox Helios must fit within either the amount of shared memory or the amount of unshared memory. For example, if your board has 256 Mbytes and you have configured it to have 128 Mbytes of shared and 128 Mbytes of unshared memory, the largest buffer that you could allocate in either type of memory would be 128 Mbytes. If you need to allocate a buffer larger than the size of either memory type, use MilConfig to change the memory configuration for your board. When the shared memory size is not large enough for the buffer, an error is returned.

ON BOARD BUS MASTER COPY MODE ASYNCHRONOUS THREAD MODE GRAB MODE EVENT SYNCHRONIZE MODIFIED BUFFER HOOK MODE MULTI THREAD BAYER CONVERSION WHITE BALANCE BAYER COEFFICIENTS ID WHITE BALANCE CALCULATE


Minimum latency and grabbing all frames

Reference:
MdigGrab
MdigInquire
MdigProcess

When grabbing with either MdigGrab() or MdigProcess(), Matrox Helios is optimized to have the smallest latency possible between the last pixel sent from the camera to the last pixel written into the buffer (either on-board or to the Host). This allows the buffer to be available for processing with a minimum amount of delay.

By default, Matrox Helios grabs into off-board buffers. When grabbing into off-board buffers, if the acquisition rate is higher than the transfer rate across the PCI/PCI-X bus, frames will be skipped rather than allowing a grab over-run to occur. For example, if your camera is 1024 by 1024 and grabs at 150 frames/sec, your acquisition rate is higher than the maximum transfer rate of the PCI bus (32 bit, 33 MHz), therefore frames will be skipped. When using a PCI-X bus, however, real-time grabs would still be feasible. To determine the image transfer speed to the Host, use the Matrox Helios Bench utility.

To be certain that no frames are missed when using MdigProcess(), use MdigInquire() with M_PROCESS_FRAME_MISSED. Use M_PROCESS_FRAME_COUNT to determine the total number of frames grabbed in the sequence. Use M_PROCESS_FRAME_RATE to return the estimate of the number of frames grabbed.

PROCESS FRAME MISSED PROCESS FRAME COUNT PROCESS FRAME RATE


COM ports and UARTS

Reference:
MsysControl
MsysInquire

Matrox Helios offers RS-232 compatible serial interfaces (each controlled by a UART). Each interface is mapped as a COM port so that it can be accessed through the Microsoft Windows API.

Use the Microsoft Win32 library to access and control the serial ports. To view them in a Microsoft Windows operating system, refer to Microsoft Window's device manager, under Ports (COM & LPT). Alternately, MIL can control and access the serial ports (use MsysControl() with M_UART...). For more information, refer to the Matrox Helios Installation and Hardware Reference manual. To learn which UART is associated to which Microsoft Windows COM port, use MsysInquire() with M_COM_PORT_NUMBER.

With Matrox Helios XCL, the Camera Link manufacturer's camera configuration application can access and control the serial ports, as well as any Camera Link camera.

COM PORT NUMBER


Matrox Helios utilities

Previous | Next

There are two Matrox Helios utilities available: Matrox Helios Bench and Usage Meter.

Matrox Helios Bench

The Matrox Helios Bench utility (HeliosBench.exe), located in your Matrox Imaging\MIL\Helios\Tools directory, calculates the real-time transfer speed of the PCI/PCI-X slot (in Mbytes/sec) from:

  • Matrox Helios to Host.
  • Host to Matrox Helios.
  • Matrox Helios to display.

It can also calculate the speed of an internal copy between 2 on-board buffers on the same system.

The Matrox Helios bench utility evaluates a given system's ability to buffer grabs from a connected, high frame rate camera. The results determine the maximum frame rate of the camera, connected to a Matrox Helios, without missing a frame.

Usage Meter

The Usage Meter utility (UsageMeter.exe) calculates how much of the grab section, PA, and the transfer section is being used. This rate of utilization is expressed as a percentage.


User-defined signals for Matrox Helios

Reference:
MdigControl
MdigGetHookInfo
MdigHookFunction
MdigInquire

Matrox Helios supports user-defined signals for synchronizing with or controlling other devices, such as a strobe light.

MIL user-defined signal numbers map to different signals depending on the type of frame grabber (XCL or XA) and the device number specified for an allocated digitizer. Most of the user-defined signals are actually multi-purpose auxiliary signals and can only be used as user-defined signals if they are not defined/used for another purpose. See the Matrox Helios Installation and Hardware Reference manual for more details.

Camera Link

The relationship between the MIL user-defined signal numbers and the actual user-defined signals for an M_DEV0 digitizer on Matrox Helios XCL are as follows:

MIL user-defined signal # | I/O | External Auxiliary I/O Connector 0 (HD-44) | External auxiliary I/O connector 1 (DB-9) | Camera Link video input connector 0 (MDR)
0 | O | P0_LVDS_AUX_OUT0 |  |
1 | O | P0_LVDS_AUX_OUT1 |  |
2 | I/O |  | P0_TTL_AUX_IO_0 |
3 | I/O | P0_TTL_AUX_IO_1 |  |
4 | I/O | TTL_AUX_IO_0¹ |  |
5 | I/O | TTL_AUX_IO_1¹ |  |
6 | I | LVDS_AUX_IN0¹ |  |
7 | I | LVDS_AUX_IN1¹ |  |
8 | I | OPTO_AUX_IN0¹ |  |
9 | I | OPTO_AUX_IN1¹ |  |
10 | I | P0_LVDS_AUX_IN0 |  |
11 | I | P0_LVDS_AUX_IN1 |  |
12 | I |  | P0_OPTO_AUX_IN0 |
13 | I |  | P0_OPTO_AUX_IN1 |
M_CC1 | O |  |  | CC1²
M_CC2 | O |  |  | CC2²
M_CC3 | O |  |  | CC3²
M_CC4 | O |  |  | CC4²

The relationship between the MIL user-defined signal numbers and the actual user-defined signals for an M_DEV1 digitizer on Matrox Helios XCL are as follows:

MIL user-defined signal # | I/O | External Auxiliary I/O Connector 0 (HD-44) | Camera Link video input connector 1 (MDR)
0 | O | P1_LVDS_AUX_OUT0 |
1 | O | P1_LVDS_AUX_OUT1 |
2 | I/O | P1_TTL_AUX_IO_0 |
3 | I/O | P1_TTL_AUX_IO_1 |
4 | I/O | TTL_AUX_IO_0¹ |
5 | I/O | TTL_AUX_IO_1¹ |
6 | I | LVDS_AUX_IN0¹ |
7 | I | LVDS_AUX_IN1¹ |
8 | I | OPTO_AUX_IN0¹ |
9 | I | OPTO_AUX_IN1¹ |
M_CC1 | O |  | CC1²
M_CC2 | O |  | CC2²
M_CC3 | O |  | CC3²
M_CC4 | O |  | CC4²

¹ Note that these user-defined signals are shared between digitizers. If used by one digitizer, they can be simultaneously used by the other digitizer that shares this user-defined signal.

² Note that you can only output 2 different signals on the 4 signals available.

Analog

The relationship between the MIL user-defined signal numbers and the actual user-defined signals for an M_DEV0 digitizer on Matrox Helios XA are as follows:

MIL user-defined signal # | I/O | External Auxiliary I/O Connector 0 (HD-44) | External auxiliary I/O connector 1 (DB-9) | Analog Video Input Connector (DVI-0) | Analog Video Input Connector (DVI-1)
0 | O | P0_LVDS/TTL_AUX_OUT0 |  |  |
1 | O | P0_LVDS/TTL_AUX_OUT1 |  |  |
2 | O |  |  | P0_TTL_AUX(EXP)_OUT |
3 | I |  |  | P0_TTL_AUX(TRIG)_IN |
4 | I |  | P0_OPTO_AUX(TRIG)_IN |  |
5 | I | LVDS/TTL_AUX_IN0¹ |  |  |
6 | I | LVDS/TTL_AUX_IN1¹ |  |  |
7 | I | LVDS/TTL_AUX_IN2¹ |  |  |
8 | I | LVDS/TTL_AUX_IN3¹ |  |  |
9 | I | LVDS/TTL_AUX_IN4¹ |  |  |
10 | I | LVDS/TTL_AUX_IN5¹ |  |  |
11 | I | LVDS/TTL_AUX_IN6¹ |  |  |
12 | I | LVDS/TTL_AUX_IN7¹ |  |  |

The relationship between the MIL user-defined signal numbers and the actual user-defined signals for an M_DEV1 digitizer on Matrox Helios XA are as follows:

MIL user-defined signal # | I/O | External Auxiliary I/O Connector 0 (HD-44) | External auxiliary I/O connector 1 (DB-9) | Analog Video Input Connector (DVI-0) | Analog Video Input Connector (DVI-1)
0 | O | P1_LVDS/TTL_AUX_OUT0 |  |  |
1 | O | P1_LVDS/TTL_AUX_OUT1 |  |  |
2 | O |  |  | P1_TTL_AUX(EXP)_OUT |
3 | I |  |  | P1_TTL_AUX(TRIG)_IN |
4 | I |  | P1_OPTO_AUX(TRIG)_IN |  |
5 | I | LVDS/TTL_AUX_IN0¹ |  |  |
6 | I | LVDS/TTL_AUX_IN1¹ |  |  |
7 | I | LVDS/TTL_AUX_IN2¹ |  |  |
8 | I | LVDS/TTL_AUX_IN3¹ |  |  |
9 | I | LVDS/TTL_AUX_IN4¹ |  |  |
10 | I | LVDS/TTL_AUX_IN5¹ |  |  |
11 | I | LVDS/TTL_AUX_IN6¹ |  |  |
12 | I | LVDS/TTL_AUX_IN7¹ |  |  |

The relationship between the MIL user-defined signal numbers and the actual user-defined signals for an M_DEV2 digitizer on Matrox Helios XA are as follows:

MIL user-defined signal # | I/O | External Auxiliary I/O Connector 0 (HD-44) | External auxiliary I/O connector 1 (DB-9) | Analog Video Input Connector (DVI-0) | Analog Video Input Connector (DVI-1)
0 | O | P2_LVDS/TTL_AUX_OUT0 |  |  |
1 | O | P2_LVDS/TTL_AUX_OUT1 |  |  |
2 | O |  |  | P2_TTL_AUX(EXP)_OUT |
3 | I |  |  | P2_TTL_AUX(TRIG)_IN |
4 | I |  | P2_OPTO_AUX(TRIG)_IN |  |
5 | I | LVDS/TTL_AUX_IN0¹ |  |  |
6 | I | LVDS/TTL_AUX_IN1¹ |  |  |
7 | I | LVDS/TTL_AUX_IN2¹ |  |  |
8 | I | LVDS/TTL_AUX_IN3¹ |  |  |
9 | I | LVDS/TTL_AUX_IN4¹ |  |  |
10 | I | LVDS/TTL_AUX_IN5¹ |  |  |
11 | I | LVDS/TTL_AUX_IN6¹ |  |  |
12 | I | LVDS/TTL_AUX_IN7¹ |  |  |

The relationship between the MIL user-defined signal numbers and the actual user-defined signals for an M_DEV3 digitizer on Matrox Helios XA are as follows:

MIL user-defined signal # | I/O | External Auxiliary I/O Connector 0 (HD-44) | External auxiliary I/O connector 1 (DB-9) | Analog Video Input Connector (DVI-0) | Analog Video Input Connector (DVI-1)
0 | O | P3_LVDS/TTL_AUX_OUT0 |  |  |
1 | O | P3_LVDS/TTL_AUX_OUT1 |  |  |
2 | O |  |  | P3_TTL_AUX(EXP)_OUT |
3 | I |  |  | P3_TTL_AUX(TRIG)_IN |
4 | I |  | P3_OPTO_AUX(TRIG)_IN |  |
5 | I | LVDS/TTL_AUX_IN0¹ |  |  |
6 | I | LVDS/TTL_AUX_IN1¹ |  |  |
7 | I | LVDS/TTL_AUX_IN2¹ |  |  |
8 | I | LVDS/TTL_AUX_IN3¹ |  |  |
9 | I | LVDS/TTL_AUX_IN4¹ |  |  |
10 | I | LVDS/TTL_AUX_IN5¹ |  |  |
11 | I | LVDS/TTL_AUX_IN6¹ |  |  |
12 | I | LVDS/TTL_AUX_IN7¹ |  |  |

¹ Note that these user-defined signals are shared between digitizers. If used by one digitizer, they can be simultaneously used by all other digitizers that share this user-defined signal.

Controlling and inquiring about user-defined signals

To control or inquire about user-defined signals on Matrox Helios, you need to use the M_USER_BIT_... control types or inquire types of MdigControl() and MdigInquire(), respectively.

To use user-defined I/O (bi-directional) signals, you must set their mode to either input or output, using the MdigControl() with M_USER_BIT_MODE.

You can set the state (on/off) of the user-defined output signals using MdigControl() with M_USER_BIT_VALUE. In addition, you can inquire about the state of the user-defined input and output signals using MdigInquire() with M_USER_BIT_VALUE.

You can control or inquire about either a specific user-defined signal or a group of user-defined signals. For an individual signal, add the MIL user-defined signal number to the control or inquire type. For a group of user-defined signals, add the M_BIT_MASK macro to the control or inquire type; the macro takes a bit-encoded mask value that identifies which user-defined signals to affect. For example on Matrox Helios XCL, adding M_BIT_MASK(45) affects user-defined signals 0, 2, 3, and 5 since the binary equivalent is equal to 101101. Note that when controlling a group of user-defined output signals, you must set the control value to a bit-encoded value that specifies the setting for each of the user-defined signals in the group. In addition, when inquiring about a group of user-defined signals, the return value is a bit-encoded value that specifies the current setting of each of the user-defined signals in the group.

Interruptible user-defined signals

To handle user-defined input signals, you can either poll their state or generate an event when they change state; all user-defined input signals can generate an event (interrupt). To generate an interrupt when there is a change in the state of a specified user-defined input signal:

  1. If bi-directional (I/O), set the user-defined signal to input mode as described above.
  2. Enable the interrupt state for the user-defined input signal, using MdigControl() with M_USER_BIT_INTERRUPT_STATE. The user-defined signal will generate an interrupt upon a rising edge.
  3. Hook a function to the user-defined signal's change of functional state, using MdigHookFunction() with M_USER_BIT_CHANGE.
  4. Within the scope of the hook function itself, inquire which user-defined signal(s) generated the interrupt, using MdigGetHookInfo() with M_USER_BIT. Then, execute according to the result of the inquiry.
USER BIT MODE USER BIT VALUE USER BIT VALUE BIT MASK USER BIT INTERRUPT STATE USER BIT CHANGE USER BIT


Matrox Helios board flow diagrams

Previous

This section contains data flow diagrams for Matrox Helios boards.

Matrox Helios XCL

The following diagram illustrates the data flow of a dual-Base Matrox Helios XCL.

The following diagram illustrates the data flow of a sngle-Full Matrox Helios XCL.

Matrox Helios XA

The following diagram illustrates the data flow of Matrox Helios XA.


Matrox Iris

Chapter 5: Matrox Iris

This section discusses features of MIL that are distinct to the Matrox Iris family and ways that optimize their performance. Matrox Iris-specific information regarding specific functions is integrated into the functions' reference topics. Refer to the miliris.txt file in the \Matrox Imaging\MIL\doc folder for any additions/modifications to the board-specific notes in this chapter or in the MIL Reference.

  • Matrox Iris-specific features
    • Summary of Matrox Iris features
  • Using Matrox Iris with MIL
  • Matrox Iris remote display
    • Remote display size and depth
    • Displaying buffers of different data depths
    • Zooming and Panning
    • Annotating the displayed image non-destructively
    • Bandwidth limitations on display
  • Using the Matrox Iris strobe
  • User-defined signals for Matrox Iris
    • Controlling and inquiring about user-defined signals
    • Using a user-defined signal
  • Matrox Iris board flow diagrams


Matrox Iris-specific features

Next

The Matrox Iris family of products combines the integration of a conventional smart camera with the flexibility of a traditional computer-based machine vision system. It is a fully programmable device, allowing extensive customization. It features an Intel-architecture processor and Microsoft Windows CE .NET, a real-time operating system.

Matrox Iris uses an interline transfer, progressive scan, CCD image sensor with square pixels. The sensors supports an externally triggered electronic shutter. An FPGA device is present to preprocess sensor data which allows the camera's microprocessor to be used for advanced image processing and analysis, communication, and control tasks.

The Intel architecture microprocessor is an Intel Ultra Low Voltage (ULV) Celeron processor with an Intel 440MX companion interface bridge. The 64 Mbytes flash disk and 128 Mbytes SDRAM memory provide in-camera (on-board) storage for both the operating system and additional data. Matrox Iris can connect to any device through an Ethernet network interface, RS-232 serial interface, and user-defined digital I/O signals.

The primary difference between the different cameras in the Matrox Iris family of products is the effective resolution and type of lens used. Matrox Iris P300 supports a 4.5 mm (1/4" type) lens with an effective resolution of 640 x 480 pixels. Matrox Iris P700 supports a 6 mm (1/3" type) lens with an effective resolution of 1024 x 768 pixels. Whereas, Matrox Iris P1200 supports an 8 mm (1/2" type) lens with an effective resolution of 1280 x 1024 pixels. Note that all lenses are measured on the diagonal.

Summary of Matrox Iris features

The following table outlines the features currently available on each member of the Matrox Iris family.

Features | Matrox Iris
Memory | 128 Mbytes SDRAM
Flash disk | 64 Mbytes
Number of acquisition paths | 1
Number of supported triggers | 2
Asynchronous reset mode support for triggers | Yes
Number of digitizers | 1
Exposure timers per digitizer | 2
Number of user-defined signals | 16 (8 in and 8 out).
Digitizer LUT | Yes


Using Matrox Iris with MIL

Reference:
MsysAlloc

To use Matrox Iris, you must allocate it as a MIL Iris system (M_SYSTEM_IRIS), using MsysAlloc(). This allocation opens communication with Matrox Iris and allows MIL to use its resources. You can allocate one process (executable) on Matrox Iris. The process can allocate a system for this camera only once.

Refer to the MilIris.txt file in the \Matrox Imaging\MIL\Doc directory for any additions/modifications to these notes.


Matrox Iris remote display

User Guide:
Annotating the displayed image non-destructively

Reference:
MbufFree
MdispAlloc
MdispFree
MdispSelect

When programming for your Matrox Iris, there is no local display to show the images or other data. The only display available is remote, which is displayed on the client computer (in a web page). Use MdispAlloc() with "REMOTEVIEW" to allocate the remote display. Your Matrox Iris does not support windowed or auxiliary displays.

A remote display requires two parts. The first is local to Matrox Iris and requires the use of MIL functions and ILib functions to allocate, control, grab, and send data to the client computer. The second uses ActiveILib to create the display and to receive data from Matrox Iris on the client computer.

Multiple remote displays can be allocated and selected for display using MdispSelect(); the display's device number should always be set to the default, using MdispAlloc() with the DispNum parameter set to M_DEFAULT.

If the display is freed using MdispFree() or the displayed buffer is freed using MbufFree(), the remote display will go blank.

Remote display size and depth

For remote displays, the display size is set using the ActiveILib Height and Width properties. The displayed image buffer is always scaled or stretched to fit these dimensions.

Displaying buffers of different data depths

Displayable image buffers usually have a depth of 8 bits (or 8 bits per band, in the case of color images). Due to the limitations of a remote display, you cannot display images of other depths.

Zooming and Panning

To zoom or pan the image, use the ActiveILib properties and methods. Refer to the Matrox Iris ILib and ActiveILib user guide and reference for more information.

Annotating the displayed image non-destructively

For remote displays, you can annotate the displayed image non-destructively using MIL's overlay-display mechanism. Refer to the Annotating the displayed image non-destructively section in Chapter 16: Displaying an image.

Bandwidth limitations on display

Remote displays rely upon a network connection between Matrox Iris and the client computer. The speed with which the image is updated on the client computer is limited by the bandwidth available between the client computer and Matrox Iris. In addition, the total amount of bandwidth available to Matrox Iris is shared by all active connections (for example, if two or more client computers view the same image simultaneously, the available bandwidth is divided evenly, providing the maximum bandwidth possible to each client computer).

Note that the largest amount of bandwidth is consumed when the entire image is sent at its full size (for example, when the zoom is set to 1). Matrox Iris sends only what is needed to keep the amount of bandwidth used as low as possible. Less bandwidth is consumed when a region of the image is displayed.

DEFAULT


Using the Matrox Iris strobe

Reference:
MdigControl

Matrox Iris can output a strobe signal. It is designed to be linked to an external flash or strobe light. A strobe takes a certain amount of time to go off and fade sufficiently to provide lighting for a good image. MIL treats the strobe signal as a specialized exposure signal. Use MdigControl() with M_GRAB_EXPOSURE... control types to set up the strobe signal. Note that the signal on which the strobe signal occurs is defined in the DCF as IND_USER/STB_OUT0. In the following example, the hardware triggered strobe starts the grab.

 /*
 * Synopsis: This program shows how to configure an exposure so that
 * a grab is triggered after the strobe (flash) occurs.
*/
    MdigControl(MilDigitizer, M_GRAB_EXPOSURE_SOURCE + M_TIMER1, M_HARDWARE_PORT0 );
    MdigControl(MilDigitizer, M_GRAB_EXPOSURE_TIME + M_TIMER1,  10 * 1000 * 1000); // 10 ms. time in nsec.
    MdigControl(MilDigitizer, M_GRAB_EXPOSURE_TIME_DELAY + M_TIMER1,  1 * 1000 * 1000); // 1 ms. time in nsec.
    MdigControl(MilDigitizer, M_GRAB_EXPOSURE + M_TIMER1,  M_ENABLE);

    MdigControl(MilDigitizer, M_GRAB_TRIGGER_SOURCE,  M_TIMER1);
    MdigControl(MilDigitizer, M_GRAB_TRIGGER_MODE ,  M_EDGE_FALLING );
    MdigControl(MilDigitizer, M_GRAB_TRIGGER,  M_ENABLE);


User-defined signals for Matrox Iris

Reference:
MsysControl
MsysGetHookInfo
MsysHookFunction
MsysInquire

Matrox Iris supports user-defined signals for synchronizing with or controlling other devices, such as a strobe light.

The relationship between the MIL user-defined signal numbers and the actual user-defined signals on your Matrox Iris are as follows:

MIL user-defined signal # | I/O | External Auxiliary I/O Connector 0 (HD-44)
0 | I | IND_USER/TRIG_IN0
1 | I | IND_USER/TRIG_IN1
2 | I | IND_USER_IN2
3 | I | IND_USER_IN3
4 | I | IND_USER_IN4
5 | I | IND_USER_IN5
6 | I | IND_USER_IN6
7 | I | IND_USER_IN7
0 | O | IND_USER/STB_OUT0
1 | O | IND_USER/EXP_OUT1
2 | O | IND_USER_OUT2
3 | O | IND_USER_OUT3
4 | O | IND_USER_OUT4
5 | O | IND_USER_OUT5
6 | O | IND_USER_OUT6
7 | O | IND_USER_OUT7

Note that the user-defined signal numbers restart for the output signals.

You should use the dedicated user-defined signals before using the multi-purpose signals (for example, IND_USER_IN2 before using IND_USER/TRIG_IN0). In addition, you should use lower-ranked user-defined signals before using higher-ranked user-defined signals (for example, IND_USER_OUT2 before using IND_USER_OUT7).

Controlling and inquiring about user-defined signals

To control or inquire about user-defined signals on Matrox Iris, you need to use the M_USER_BIT_... control types or inquire types of MsysControl() and MsysInquire(), respectively.

You can set the state (on/off) of the user-defined output signals using MsysControl() with M_USER_BIT_VALUE_OUT. In addition, you can inquire about the state of the user-defined input and output signals using MsysInquire() with M_USER_BIT_VALUE_IN and M_USER_BIT_VALUE_OUT, respectively.

You can control or inquire about either a specific user-defined signal or a group of user-defined signals. For an individual signal, add the MIL user-defined signal number to the control or inquire type. For a group of user-defined signals, add the M_BIT_MASK macro to the control or inquire type; the macro takes a bit-encoded mask value that identifies which user-defined signals to affect. For example, adding M_BIT_MASK(45) affects user-defined signals 0, 2, 3, and 5 since the binary equivalent is equal to 101101. Note that when controlling a group of user-defined output signals, you must set the control value to a bit-encoded value that specifies the setting for each of the user-defined signals in the group. In addition, when inquiring about a group of user-defined signals, the return value is a bit-encoded value that specifies the current setting of each of the user-defined signals in the group.

Using a user-defined signal

To handle user-defined input signals, you can either poll their state or generate an event when they change state; all user-defined signals can generate an event (interrupt). To generate an interrupt when there is a change in the state of a specified user-defined input signal:

  1. Specify whether the user-defined input signal should generate an interrupt upon a rising edge or falling edge, using MsysControl() with M_USER_BIT_INTERRUPT_MODE set to either M_EDGE_RISING or M_EDGE_FALLING.
  2. Enable the interrupt state for the user-defined input signal, using MsysControl() with M_USER_BIT_INTERRUPT_STATE.
  3. Hook a function to the user-defined signal's change of functional state, using MsysHookFunction() with M_USER_BIT_CHANGE.
  4. Within the scope of the hook function itself, inquire which user-defined signal(s) generated the interrupt using MsysGetHookInfo() with M_USER_BIT. Then, execute according to the result of the inquiry.
USER BIT VALUE OUT USER BIT VALUE IN USER BIT VALUE OUT BIT MASK USER BIT INTERRUPT MODE EDGE RISING EDGE FALLING USER BIT INTERRUPT STATE USER BIT CHANGE USER BIT


Matrox Iris board flow diagrams

Previous

The following diagram illustrates the data flow of Matrox Iris.


Matrox Meteor-II

Chapter 6: Matrox Meteor-II

This chapter discusses features of MIL that are particular to the different Matrox Meteor-II boards and ways that optimize each board's performance. Board-specific information regarding specific functions is integrated into the functions' reference topics. Refer to the milmet2.txt file in the \Matrox Imaging\MIL\doc (or user-specified) folder for any additions/modifications to the board specific notes in this chapter or in the MIL Reference.

  • Matrox Meteor-II-specific features
    • UART
  • Using Matrox Meteor-II with MIL
  • Cameras that can be connected to Matrox Meteor-II
    • Matrox Meteor-II /Camera Link
  • Grabbing to a Host image with Matrox Meteor-II /Digital and /Camera Link
    • Optimizing the use of the frame buffers
    • Increasing the default temporary buffer size
    • Grabbing in on-board images
    • Grabbing large frames of data
    • An example
  • IEEE 1394 serial bus-specific features
    • Video formats and modes
    • An example
    • Read/write capabilities
    • MdigGrab() buffers with Matrox Meteor-II /1394
  • Grabbing from multiple 1394 DCS-compliant cameras
    • In general
    • Establishing a pool of IEEE 1394 DCS-compliant cameras
    • Assigning a camera/digitizer to a system
    • Important points to consider
  • Setting 1394 DCS-compliant camera features
    • Setting general camera controls
    • Setting 1394 DCS-specific camera controls
    • An example
  • User-defined signals for Matrox Meteor-II
    • Matrox Meteor-II /Digital
    • Matrox Meteor-II /Camera Link
    • Matrox Meteor-II /Standard and Matrox Meteor-II /Multi-Channel
    • Controlling and inquiring about user-defined signals
  • Matrox Meteor II board flow diagrams
    • Matrox Meteor-II /Standard
    • Matrox Meteor-II /Multi-Channel
    • Matrox Meteor-II /Digital and /Digital PC/104-Plus
    • Matrox Meteor-II /1394
    • Matrox Meteor-II /Camera Link and /Camera Link PC/104-Plus


Matrox Meteor-II-specific features

Next

The Matrox Meteor-II family is comprised of four acquisition boards: Matrox Meteor-II /Standard, Matrox Meteor-II /Multi-Channel, Matrox Meteor-II /Digital, Matrox Meteor-II /1394 and Matrox Meteor-II /Camera Link. Each Matrox Meteor-II board is available in one or more of the following form factors: PCI, CompactPCI, and PC/104-Plus.

All Matrox Meteor-II boards share two essential features: they have no on-board display section, and they are able to transfer images in real-time to Host memory.

A number of other features are not available on every Matrox Meteor-II board. These features include the VMChannel, UART, as well as support for the software triggers, exposure timers, and asynchronous reset mode.

The following table outlines the features currently available for each member of the Matrox Meteor-II family:

Matrox Meteor-II | STD | MC | DIG | 1394 | CL
Available in PCI form factor | X | X | X | X | X
Available in CompactPCI form factor | X |  |  |  |
Available in PC/104-Plus form factor | X | X | X |  |
Uses standard VGA for display | X | X | X | X | X
Has an on-board UART (PCI form factor) | X | X | X |  | X
Has a VMChannel interface (PCI form factor) | X | X | X |  | X
Supports mono-tap and dual-tap camera configurations |  | X | X |  | X
Supports multi-tap configurations |  |  | X |  | X
Supports hardware triggers | X | X | X | X | X
Supports software triggers | X | X | X |  | X
Has 2 exposure timers |  | X | X |  | X
Supports asynchronous reset mode |  | X | X |  | X
Supports Windows Me | X | X |  | X |
Can be used as a fingerprint for run-time licenses |  |  |  | X* |

*A camera must be plugged-in before launching your development environment, as well as before running your application; otherwise the run-time license will not work.

It is important to note that Windows 2000/XP is supported on all members of the Matrox Meteor-II family. However, the Matrox Meteor-II /1394 driver does not support "plug and play".

UART

Most Matrox Meteor-II boards for PCI also feature an on-board UART (Universal Asynchronous Receiver/Transmitter) that provides an RS-232 serial interface. This allows you to remotely control a camera or a motion control unit, or communicate with a program logic controller (PLC).


Using Matrox Meteor-II with MIL

Reference:
MdigGrab
MdigGrabContinuous
MsysAlloc

To use a Matrox Meteor-II board with MIL, you must allocate it as a Meteor-II system using MsysAlloc() with one of the following system types: M_SYSTEM_METEOR_II, M_SYSTEM_METEOR_II_DIG, M_SYSTEM_METEOR_II_1394, or M_SYSTEM_METEOR_II_CL. This allocation opens communication with the Matrox Meeor-II board and allows MIL to use its resources. You can run only one process (executable) on a Matrox Meeor-II board. The process can allocate a system for this board only once. The graphics controller has been included to allow you to display grabbed images (none of the Matrox Meteor-II boards have an on-board display section).

It is important to note that more than one system can be allocated on a Matrox Meteor-II /1394 board. For a discussion on how to use 1394-compliant cameras on a system, see the Grabbing from multiple 1394 DCS-compliant cameras section later in this chapter.

The native format of grabbed data depends on the camera connected.

SYSTEM METEOR II SYSTEM METEOR II DIG SYSTEM METEOR II 1394 SYSTEM METEOR II CL


Cameras that can be connected to Matrox Meteor-II

Reference:
MdigAlloc
MdigChannel

The number of composite/monochrome, Y/C, or RGB cameras that can be attached to the different Matrox Meteor-II boards depends on the form factor used and the type of board. With the exception of the Matrox Meteor-II /1394, you can grab from only one camera at a time. The following table lists the maximum number of cameras that can be attached for each available form factor of Matrox Meteor-II boards. You can switch the grab between cameras of the same type using MdigChannel().

Board | Type of camera | PCI | CompactPCI | PC/104-Plus
Matrox Meteor-II/Standard¹ | Monochrome RS-170/CCIR | 12 | 7 | 12
 | Composite NTSC/PAL | 12 | 7 | 12
 | Y/C | 6 | 3 | 6
Matrox Meteor-II/Multi-Channel | Standard/ non-standard monochrome | 6 |  | 6
 | RGB | 2 |  | 2
Matrox Meteor-II/Digital | Digital monochrome | 4 |  | 4
 | Digital RGB | 1 |  | 1
Matrox Meteor-II/1394² | Digital IEEE 1394 standard | >=1* |  |
Matrox Meteor-II/Camera Link | Digital monochrome | 2 |  |
 | Digital RGB | 1 |  |

¹Note, Rev. 1 of Matrox Meteor-II /Standard supports only 4 monochrome or 2 Y/C cameras.

²More than one independent IEEE 1394 DCAM-compliant camera can be attached to the Matrox Meteor-II /1394 board, but each 1394 DCAM-compliant camera must be allocated as a separate digitizer with different digitizer numbers (using MdigAlloc() with M_DEVn). When attaching multiple cameras, they must comply with an IEEE 1394 tree topology.

Matrox Meteor-II /Camera Link

For Matrox Meteor-II /Camera Link, the camera description and the mode, specified in the DCF, determine the channels available for switching. In the base mode configuration (one connector per camera), you can switch between two cameras (non-simultaneous acquisition):

Camera description | Signal/Sync Input
8 bit, 1 tap | bit 0-7
10-16 bit, 1 tap | bit 0-15
8 bit, 2 taps | bit 0-15
10-12 bit, 2 taps | bit 0-23*
RGB | bit 0-23

* 32 bits are used to transfer the 2 taps. Data bits 0-11 (first tap) are transferred to bits 0-15, whereas data bits 12-23 (second tap) are transferred to bits 16-31. Non-data bits are padded with 0.

In the medium mode configuration, you can use two connectors per camera. Note that only M_CH0 is supported in this mode.

Camera description | Signal/Sync input
8 bits, 2 taps | Connector 1, bit 0-7 and connector 2, bit 0-7
10-16 bits, 2 taps | Connector 1, bit 0-15 and connector 2, bit 0-15 or* Connector 1, bit 0-23 and connector 2, bit 0-7
8 bits, 4 taps | Connector 1, bit 0-15 and connector 2, bit 0-15 or* Connector 1, bit 0-23 and connector 2, bit 0-7

*As specified in the DCF file.

CH0


Grabbing to a Host image with Matrox Meteor-II /Digital and /Camera Link

Reference:
MdigGrab
MdigGrabContinuous
MsysControl

When grabbing to a Host image, Matrox Meteor-II /Digital and Matrox Meteor-II /Camera Link use video transfer memory to temporarily store the grabbed data while the board waits for access to the PCI bus. Loss of image data could otherwise occur during long bus-access latencies, found in heavily loaded systems.

Matrox Meteor-II /Digital uses hardware/software transfer control logic to double-buffer the grab between two temporary buffers created within the video transfer memory. This logic toggles the grab between one temporary buffer and the other, transferring grabbed data from the buffer in which data is not being grabbed to the Host. The double-buffering is done on a line-block basis rather than on a frame basis.

In general, the default size of the temporary buffers provides a good compromise between maintaining a small latency before the beginning of the transfer and minimizing the transfer's dependency on the PCI bus load. However, when the PCI bus is extremely loaded, the Matrox Meteor-II /Digital (or Matrox Meteor-II /Camera Link) board might not be able to maintain the grab and transfer sequence. If the request to transfer is not serviced in time, the grab might overwrite non-transferred data. This is known as a grab over-run.

For example, a typical load on the PCI bus is that of the Matrox Meteor-II /Digital (or Matrox Meteor-II /Camera Link) zooming grabbed data from a high frequency camera before transferring it. A digital camera with a frequency of 40 MHz presents no problem on its own, but zooming by a factor of four would require a bandwidth of 160 Mbytes/sec. The PCI bandwidth has a limit of 133 Mbytes/sec. This situation would result in a grab over-run.

Optimizing the use of the frame buffers

If you experience grab over-runs, try the following solutions in the specified order:

  1. Increase the default temporary buffer size. This should be enough to resolve your problems.
  2. If possible, double-buffer the grab on a frame basis rather than a line-block basis. In this case, you have to manage the double-buffering of the grab yourself. This method involves one frame of latency before the beginning of the transfer.
  3. Reduce the PCI bus load.

Increasing the default temporary buffer size

You can increase the default temporary buffer size. Larger temporary buffers make the grab's transfer-to-Host less dependent on the PCI bus load. That is, the grab is less affected by long bus-access latencies, found in heavily loaded systems, because more memory is available to buffer the data. Note, however, that larger temporary buffers also increase the latency before the beginning of the transfer.

You can increase the default temporary buffer size by adjusting the SizeOfTmpBufferForHostGrab field in the genesis.ini file in the \GENESIS\SHELL directory.

Grabbing in on-board images

If increasing the size of the temporary buffers does not resolve your over-run problem, you can try double-buffering the grab on a frame basis rather than a line-block basis. The grab is then less dependent on the PCI bus load because the data does not have to be transferred as frequently and intermittent bus latencies are averaged over an entire frame. The downside of this process is that there is one frame of latency before the beginning of the transfer.

To implement this model, you have to manage the double-buffering. To do so, create two frame-sized images on-board and then grab a field/frame into one image while copying the other image to the Host. Since you control the synchronization between the grab and transfer, you can detect when something goes wrong.

Note that, by default, the copy operation is driven by the Host CPU. To speed up the copy and reduce Host intervention, enable board driven (VIA-driven) copies by setting the MsysControl() M_BUS_MASTER_COPY_TO_HOST control to M_ENABLE.

This method is only possible if sufficient on-board memory is available to create the two images.

Grabbing large frames of data

When grabbing large frames of data (for example, 2K X 2K and 4K X 4K), there is no way to store the whole frame in video transfer memory. In this case, you can only grab to a Host buffer. This restriction does not apply to Matrox Meteor-II /Camera Link, since 32 Mbytes of video transfer memory are available.

An example

The following example shows how to allocate buffers in video transfer memory and then grab in these buffer.

mmet2dig.c
BUS MASTER COPY TO HOST ENABLE


IEEE 1394 serial bus-specific features

Reference:
MdigAlloc
MdigControl
MdigGrab
MdigGrabContinuous
MdigInquire
MdigReference

Although the Matrox Meteor-II /1394 is Open Host Controller Interface (OHCI) compliant, MIL can use Matrox Meteor-II /1394 to acquire serial data only from a digital camera that complies with the IEEE IIDC 1394 -based Digital Camera Specification. Currently, data transfer rates of up to 400 Mbits per second (Mbps) are possible.

In MIL, to access and acquire data from an IEEE 1394 DCAM-compliant camera, allocate it as a digitizer (MdigAlloc()) on a Matrox Meteor-II /1394 system. To access and acquire data from multiple IEEE 1394 DCAM-compliant cameras, refer to the Grabbing from multiple 1394 DCS-compliant cameras section later in this chapter.

Video formats and modes

Matrox Meteor-II /1394 supports monochrome and color IEEE 1394 cameras. Most 1394-digital cameras support one or more of four standard formats: format 0, 1, 2, and 7. The format determines the maximal image/screen resolutions supported (see the table below):

Format | Resolution Range (Maximum)
0 | [160x120, 640x480] (640x480)
1 | [800x600, 1024x768] (1024 x 768)
2 | [1280x960, 1600x1200] (1600 x 1200)
7 | Scalable image size format

Each camera format can support a number of modes. Each format/mode combination corresponds to a specific camera setting specifying a resolution, data format, and internal storage size (as per the IEEE 1394 Digital Camera Specification).

For formats 0, 1, and 2, MIL supports all YUV 4:1:1, YUV 4:2:2, and 1-band, 8-bit modes (at all frame rates) on the Matrox Meteor-II /1394.

Format 0 includes two format/mode combinations which approximate the RS-170 (monochrome) and NTSC (color) video format standards, respectively.

Note that the Matrox Meteor-II /1394 driver does not support native YUV 4:4:4 camera modes. Use MdigInquire() with M_FORMAT_SUPPORTED to generate a list of all supported data formats/modes for your 1394 digital camera.

In addition, note that on the Matrox Meteor-II /1394, YUV 4:2:2 data is grabbed in UYVY format.

An example

The following example shows how to inquire and print the supported strings.

Met2_1394SerialBus.c

Read/write capabilities

The read and write capabilities of Matrox Meteor-II /1394 are supported through the standard MIL digitizer inquire and control functions.

Use MdigInquire() to read the actual, minimum, or maximum value of any status register feature. Use MdigControl() and MdigReference() to modify the actual value of a status or control register feature.

MdigGrab() buffers with Matrox Meteor-II /1394

MdigGrab(), performed with Matrox Meteor-II /1394, can involve more Host CPU usage than with other Matrox imaging boards. This is because there is no on-board memory, no on-board data converter, and the format of the grabbed data cannot be assumed at buffer allocation time. To resolve this issue, temporary buffers are internally created when MdigAlloc() is called; upon an MdigGrab() call, the grab occurs to an internal buffer and then copied to the allocated grab buffer, converting the data, if necessary. Note that by default, the allocation format of the grab buffer is RBG24 planar; this format is chosen because it is the one used when processing, saving, or superimposing an overlay on a display.

When you need to display continuously grabbed data, it is more efficient to use MdigGrabContinuous() than to use MdigGrab() with a displayable buffer. This is because if the grabbed data is in the format of the display, the data does not undergo conversion.

FORMAT SUPPORTED


Grabbing from multiple 1394 DCS-compliant cameras

Reference:
MdigAlloc
MdigFree
MdigGrab
MsysAlloc
MsysInquire

Matrox Meteor-II /1394 supports acquisition from multiple IEEE 1394 DCAM-compliant cameras attached in an IEEE 1394 topology. However, there are issues with respect to both the PCI bus and the IEEE 1394 bus that restricts the actual number of cameras that can be used. Refer to the Hardware reference chapter in the Matrox Meteor-II /1394 Installation and Hardware Reference manual.

In general

To access and grab from multiple cameras, allocate each camera as a digitizer on a Matrox Meteor-II /1394 system (MdigAlloc()). With each call, the DigNum parameter must be set to M_DEVn, where n is the camera number, starting from 0 (M_DEV0). You can then perform simultaneous grabs from each of these cameras, hardware permitting, by making multiple calls to MdigGrab() with the appropriate MIL digitizer (camera) identifiers.

Establishing a pool of IEEE 1394 DCS-compliant cameras

All cameras that are attached to a Matrox Meteor-II /1394 board are detected when the first MsysAlloc() function call is made. This establishes a "pool" of cameras. Any cameras attached after the "pool" has been established cannot be accessed (allocated).

You must not unplug a camera that is part of the pool until the last system is freed; also, the camera should be plugged-in before launching your development environment.

When it is necessary to manage multiple systems, specify the correct system device number when allocating the system.

Assigning a camera/digitizer to a system

Although cameras in the pool are detected when the first MsysAlloc() function call is made, these cameras are not associated to an allocated system. To be used on a system, a camera from the pool must be assigned to one of the available Meteor-II /1394 systems using MdigAlloc().

A camera in the pool also has no fixed device number. Accordingly, you need to assign an appropriate device number to MdigAlloc(). To accomplish this:

  1. Inquire the number of digitizers that can be allocated on the system using MsysInquire() with M_DIGITIZER_NUM. This returns the number of digitizers already allocated on the system, in addition to the number of unassigned cameras (digitizers) in the pool; in other words, it returns the total number of digitizers.
  2. Use a device number that is less than this inquired value, and that has not already been used for another digitizer on the system.

Important points to consider

Once a 1394-compliant camera is allocated as a digitizer on a MIL system, the camera (digitizer) then belongs to the system, until it is freed with MdigFree(). When a digitizer is freed, it is returned to the common pool of available digitizers (cameras) that is shared by all Meteor-II /1394 systems.

Once you install the MIL Matrox Meteor-II /1394 driver (needed to access Matrox Meteor-II /1394 board), you can only use cameras/digitizers that are IEEE 1394 DCS-compliant, and you can use these cameras only through MIL and other Matrox imaging software.

Windows 2000 supports the IEEE 1394 interface, however you must install the MIL Matrox Meteor-II /1394 driver to use IEEE 1394 DCS-compliant cameras through MIL. Once installed, you will only be able to use your IEEE 1394 DCS-compliant cameras through MIL. However, you can still interface any other type of IEEE 1394 device to the IEEE 1394 interface.

DIGITIZER NUM


Setting 1394 DCS-compliant camera features

Reference:
MdigControl
MdigInquire
MdigReference

There are both general and specific camera features for a 1394 DCS-compliant digital camera.

Setting general camera controls

The general camera controls include brightness, hue, saturation and (input) gain. For portability, you should set/control these standard control features in the conventional way using MdigReference() with M_BRIGHTNESS_REF, M_HUE_REF, or M_SATURATION_REF, and using MdigControl() with M_GRAB_INPUT_GAIN.

On a Matrox Meteor-II /1394, the MdigReference() function will map the smallest value supported by the camera to M_MIN_LEVEL, and map the largest value supported by the camera to M_MAX_LEVEL. The number of values supported by your camera can differ such that consecutive reference-level settings might produce the same result. See the MdigReference() function in the MIL Reference for more details on reference levels.

If you need more flexibility when setting these features, you can use the method described in the next subsection for 1394 DCS-specific camera controls.

Setting 1394 DCS-specific camera controls

The specific camera controls include auto-exposure, sharpness, white balance U/V, gamma, shutter, iris, focus, target temperature, zoom, pan, tilt, optical filter, capture size, and capture quality. For these specific camera controls, there is a non-standard approach that allows flexible management of any compliant camera.

  1. Inquire whether the camera has a required camera feature using the MdigInquire() function. An error message will be generated if the requested feature (inquire type) is not supported.

    2. If the required feature is available, inquire the minimum and maximum possible values of a required control feature using the MdigInquire() function.

    To do so, add M_MIN_VALUE or M_MAX_VALUE to the specified inquire type, respectively. For example, to inquire the minimum sharpness value, use M_SHARPNESS + M_MIN_VALUE.

  2. Once you have determined the range of possible values, you can set or adjust the camera-control option using the MdigControl() function. See the board-specific section of MdigControl() in the MIL Reference for information on Matrox Meteor-II/1394 restrictions.

For camera features that have an automatic mode (for example, white balance), use the M_DEFAULT control value with the appropriate control type to set the camera to automatic mode.

An example

The following code snippet demonstrates how to use the 1394-specific method to set the sharpness level for a 1394-compliant digital camera. In this example, the sharpness level is set to the mean (average) sharpness level for a particular camera:

/* Inquire the minimum and maximum values, respectively, for the image sharpness.
* Calculate the mean sharpness, and then set the sharpness value to the mean.
*/
long MinVal, MaxVal, NewVal;
MdigInquire(DigID, M_SHARPNESS+M_MIN_VALUE, &MinVal); /* Inquire minimum value */
MdigInquire(DigID, M_SHARPNESS+M_MAX_VALUE, &MaxVal); /* Inquire maximum value */
NewVal = (MinVal + MaxVal) /2; /* Calculate average */
MdigControl(DigID, M_SHARPNESS, NewVal); /*Set current value to average */
BRIGHTNESS REF HUE REF SATURATION REF GRAB INPUT GAIN MIN LEVEL MAX LEVEL MIN VALUE MAX VALUE SHARPNESS MIN VALUE


User-defined signals for Matrox Meteor-II

Reference:
MdigControl
MdigInquire

Matrox Meteor-II supports user-defined signals for synchronizing with or controlling other devices, such as a strobe light.

Matrox Meteor-II /Digital

The relationship between the MIL user-defined signal numbers and the actual user-defined signals on the digital interface connector are as follows:

MIL user-defined signal # | I/O | Digital interface connector signal
0 | O | USER0 OUTPUT (RS-422/LVDS only) signal.¹
0 | I | USER0IN signal.
1 | O | USER1 OUTPUT (RS-422/LVDS only) signal.¹
1 | I | USER1IN signal.
2 | O | CAMERA CONTROL 0 (TTL only) signal.
3 | O | CAMERA CONTROL 1 (TTL only) signal.
4 | O | CAMERA CONTROL 2 (TTL only) signal.

¹ Note that there are two user-defined signals for user-defined signal 0 and 1. When inquired, the user-defined input signal is returned. When controlled, the user-defined output signal is changed.

Matrox Meteor-II /Camera Link

The relationship between the MIL user-defined signal numbers and the actual user-defined signals on the auxiliary synchronization and control connector are as follows:

MIL user-defined signal # | I/O | Auxiliary synchronization and control signal
0 | I | USER0 INPUT (RS-422/LVDS) signal.
0 | O | Group A of the CAMCTRLn¹ OUTPUT (TTL only) signals.
1 | I | USER1 INPUT (RS-422/LVDS only) signal.
1 | O | Group B of the CAMCTRLn¹ OUTPUT (TTL only) signals.
2 | O | CAMERA CONTROL 0 (TTL only) signal.²
3 | O | CAMERA CONTROL 1 (TTL only) signal.²
4 | O | CAMERA CONTROL 2 (TTL only) signal.²

¹ By default, these user-defined signals can be grouped together in the DCF. Otherwise, use MdigControl() with M_CAMERALINK_CCn_SOURCE to identify which CAMCTRL signal (0 through 4) to associate with group A or group B (use MdigControl() with M_CAMERALINK_CCn_SOURCE + M_USER_BIT_CC_A or M_USER_BIT_CC_B).

² Note that these user-defined output signals are not the same as the camera control signals on the Camera Link connectors.

³ Note that there are two user-defined signals for user-defined signal 0 and 1. When inquired, the user-defined input signal is returned. When controlled, the user-defined output signal is changed.

Matrox Meteor-II /Standard and Matrox Meteor-II /Multi-Channel

The relationship between the MIL user-defined signal numbers and the actual user-defined signals on the video input connector are as follows:

MIL user-defined signal # | I/O | Video input connector signal
1 | I | USER1IN signal.
2 | I | USER2IN signal.
3 | O | USER1OUT signal.
4 | O | USER2OUT signal.

Note that there is no user-defined signal 0 for these boards.

Controlling and inquiring about user-defined signals

To control or inquire about user-defined signals on Matrox Meteor-II, you need to use the M_USER_BIT_... control types or inquire types of MdigControl() and MdigInquire(), respectively.

You can set the state (on/off) of the user-defined output signals using MdigControl() with M_USER_BIT_VALUE. In addition, you can inquire about the state of the user-defined input and output signals using MdigInquire() with M_USER_BIT_VALUE.

CAMERALINK CCn SOURCE CAMERALINK CCn SOURCE USER BIT CC A USER BIT CC B USER BIT VALUE USER BIT VALUE


Matrox Meteor II board flow diagrams

Previous

This section contains data flow diagrams for Matrox Meteor-II boards.

Matrox Meteor-II /Standard

The following diagram illustrates the data flow of a Matrox Meteor-II /Standard.

Matrox Meteor-II /Multi-Channel

The following diagram illustrates the data flow of a Matrox Meteor-II /Multi-Channel.

Matrox Meteor-II /Digital and /Digital PC/104-Plus

The following diagram illustrates the data flow of a Matrox Meteor-II /Digital and a Meteor-II /Digital PC/104-Plus. Grey areas on the following graphic are supported on PCI version only.

Matrox Meteor-II /1394

The following diagram illustrates the data flow of a Matrox Meteor-II /1394.

Matrox Meteor-II /Camera Link and /Camera Link PC/104-Plus

The following diagram illustrates the data flow of a Matrox Meteor-II /Camera-Link and a /Camera Link PC/104-Plus. Grey areas on the following graphic are supported on PCI version only.


Matrox Morphis

Chapter 7: Matrox Morphis

This chapter discusses features of MIL that are particular to the Matrox Morphis board and ways that optimize the board's performance. Board-specific information regarding specific functions is integrated into the functions' reference topics. Refer to the milmorphis.txt file in the \Matrox Imaging\MIL\doc (or user-specified) folder for any additions/modifications to the board specific notes in this chapter or in the MIL Reference.

  • Matrox Morphis-specific features
    • Acquisition features
    • Compression/decompression
    • Additional functionality
      • Data transfer
  • Using Matrox Morphis with MIL
    • JPEG2000 support
  • Cameras that can be connected to Matrox Morphis
  • COM ports and UARTS
  • Matrox Morphis JPEG2000
    • Compression/decompression
    • JPEG2000 tiling
    • Warming up
    • A simple grab and compress
    • Decompress from a Host pointer
    • Example how to efficiently compress Host images
  • Matrox Morphis watchdog functionality
  • Matrox Morphis utilities
    • Usage Meter
    • Matrox Morphis Bench
  • User defined signals for Matrox Morphis
    • Controlling and inquiring about user-defined signals
    • Interruptible user-defined signals
  • Matrox Morphis board flow diagrams


Matrox Morphis-specific features

Next

The Matrox Morphis family consists of three frame grabbers capable of acquiring standard, monochrome/color, analog video. They can also perform JPEG2000 compression/decompression when integrated with a JPEG2000 accelerator.

This chapter outlines basic features of the Matrox Morphis family of frame grabbers (specifically Matrox Morphis PC/104-Plus, Matrox Morphis Dual, and Matrox Morphis Quad), and relates them to specific functions in MIL.

Note that Matrox Morphis PC/104-Plus can be used in conjunction with Matrox 4Sight-M.

Acquisition features

The Matrox Morphis family of frame grabbers can simultaneously capture from multiple cameras using its independent acquisition paths. In addition, it can switch the capture (channel switch) between cameras of the same type. If not simultaneously capturing from either 2 or 4 cameras, the Matrox Morphis family of frame grabbers can perform ultra-fast switching. Matrox Morphis Dual and Matrox Morphis PC/104-Plus each has two independent acquisition paths, and Matrox Morphis Quad has four independent acquisition paths.

The Matrox Morphis family video decoders can accept composite (CVBS) and component S-video (Y/C) in NTSC/PAL formats, and monochrome video in RS-170/CCIR, both of which have square pixels. Grabbed data can be converted into the following formats: RGB planar, BGR32 packed, YUV16 packed (stored in YUYV format), and 8-bit monochrome.

As a standard feature, you can connect up to 4 CVBS/monochrome or 2 Y/C video sources, or a combination of both, to the Matrox Morphis family of frame grabbers. Using optional expansion modules, you can extend the number of video sources that can be connected. You can use up to three Matrox Morphis Video Input modules and to each module, connect the same number of video sources as is supported by the base board. Alternatively, you can use a single expansion module, the Matrox Morphis Video and I/O module, and connect an additional 12 CVBS/monochrome or 6 Y/C video sources, or a combination of both.

Note that you can only connect a single Matrox Morphis Video and I/O module to the Matrox Morphis Dual or Quad. The Matrox Morphis Video and I/O module and the Matrox Morphis Video Input module are mutually exclusive. The Matrox Morphis Video Input module is compatible with Matrox Morphis PC/104-Plus.

Formatting features of Matrox Morphis include cropping (ROI capture), subsampling to 1/16th of a field or frame, and vertical/horizontal flipping. Matrox Morphis accepts two external trigger inputs, and can operate in next valid frame/field mode when grabbing upon a trigger.

Compression/decompression

Matrox Morphis Dual and Matrox Morphis PC/104-Plus can be a JPEG2000 image compression/decompression accelerator. Matrox Morphis Dual and Matrox Morphis PC/104-Plus both support real-time performance for standard video rates, including lossy (9/7 wavelet) and lossless (5/3 wavelet) modes. Matrox Morphis JPEG2000 module can compress 16-bit buffers with 12-bit per pixel.

Matrox Morphis Dual and Matrox Morphis PC/104-Plus can compress images from the acquisition section, from another frame grabber (such as Matrox Helios), or from the Host.

Matrox Morphis Dual and Matrox Morphis PC/104-Plus have 16 Mbytes of on-board compression/decompression memory.

Additional functionality

In addition to the core video capture and compression/decompression functionality, the Matrox Morphis family of frame grabbers incorporate a variety of features to simplify overall system integration. These features include:

  • Hardware facilities for implementing custom software-based motion detection.
  • An integrated watchdog timer for automatically recovering from application or system failure.¹
  • 16 TTL user I/O integrated signals to control or synchronize with other user inputs.¹
  • An RS-485 serial interface, mapped as a Microsoft Windows COM port so that the interface can be accessed through the Win32 API. The serial interface can both receive and transmit signals, but in half-duplex mode. The serial interface can be connected to an RS-485 two-wire multi-drop network. ¹
  • Video input testing. The CVBS or Y input of decoder 0 can be routed out to the Matrox Morphis Video and I/O module for test purposes.

¹ Note that these features are not available on Matrox Morphis PC/104-Plus.

Data transfer

The Matrox Morphis family of boards allows continuous grabbing to Host memory or display memory. Matrox Morphis can also act as a 32-bit 33/66 MHz PCI bus master to reduce CPU usage. The Matrox Morphis family of frame grabbers can also generate interrupts for the start and end of a field, frame, and sequence capture.


Using Matrox Morphis with MIL

Reference:
MsysAlloc

To use a Matrox Morphis board, you must allocate it as a MIL Morphis system (M_SYSTEM_MORPHIS), using MsysAlloc(). This allocation opens communication with the Matrox Morphis board and allows MIL to use its resources. You can run only one process (executable) on a Matrox Morphis board. The process can allocate a system for this board only once.

Refer to the MilMorphis.txt file in the \Matrox Imaging\MIL\doc folder for any additions/modifications to these board specific notes.

JPEG2000 support

A version of the JPEG2000 software is resident on Matrox Morphis. This provides a royalty-free run-time comprssion/decompression software that can be used both on-board Matrox Morphis with JPEG2000 compression/decompression accelerator as well as on the associated Host machine. Note that this does not provide a license for JPEG, only JPEG2000.

When you have a Matrox Morphis with an integrated JPEG2000 accelerator, JPEG2000 compression/decompression is supported in MIL-Lite. Note that, even with the integrated JPEG2000 accelerator, JPEG compression is not supported in MIL-Lite.

Note that to use JPEG2000 acceleration, the buffer must be allocated on a Morphis system.

SYSTEM MORPHIS


Cameras that can be connected to Matrox Morphis

Reference:
MdigAlloc
MdigChannel

The following types of camera can be connected to Matrox Morphis.

Type of camera | Number supported
Composite color/monochrome | 16
Y/C | 8

You can allocate up to 2 independent digitizers on Matrox Morphis Dual and Matrox Morphis PC/104-Plus, or up to 4 independent digitizers on Matrox Morphis Quad, with MdigAlloc().

Each acquisiton path supports input from a total of 16 data channels. You can switch the grab between cameras of the same type using MdigChannel().


COM ports and UARTS

Reference:
MsysControl

Matrox Morphis Dual and Quad each offers a RS-232 compatible serial interfaces (each controlled by a UART). Each interface is mapped as a COM port so that it can be accessed through the Microsoft Windows API.

Use the Microsoft Win32 library to access and control the serial ports. Alternately, MIL can control and access the serial ports (use MsysControl() with M_UART...). To view them in a Microsoft Windows operating system, refer to Microsoft Window's device manager, under Ports (COM & LPT). For more information, refer to the Matrox Morphis Installation and Hardware Reference manual.


Matrox Morphis JPEG2000

Reference:
MbufControl
MbufCopy

Matrox Morphis can optionally perform JPEG2000 compression/decompression with a JPEG2000 accelerator. Matrox Morphis has 2 independent 16 Mbyte memory banks: one for general acquisition and one for JPEG2000.

Note that when decompressing or compressing a Host buffer, the compression speed is increased when Matrox Morphis JPEG2000 accelerator is in a 66MHz PCI slot.

Compression/decompression

If a JPEG2000 compression/decompression accelerator is present, and the hardware supports the compressed buffer's format, compression/decompression is performed by the hardware. If the hardware does not support the buffer's format, compression/decompression is performed by the Host.

All on-board buffers are allocated in the JPEG2000 memory bank, if available. If you want to compress while grabbing, the grab buffer must be stored in the JPEG2000 memory bank (with MbufAlloc...() using M_ON_BOARD). Compression is done when the grab buffer is copied from an uncompressed to a compressed buffer using MbufCopy().

Note that JPEG2000 decompressions into a non-paged buffer (allocated with MbufAlloc...() using M_NON_PAGED) are faster than with buffers allocated in paged memory.

The following buffer formats are supported for compression:

Data type | Source buffer | Destination JPEG2000 lossy buffer | Destination JPEG2000 lossless buffer
8-bit monochrome | Yes | Yes | Yes
16-bit monochrome | Yes | Yes | Yes
YUV16 packed | Yes | Yes | Yes

The following buffer formats are supported for decompression:

Data type | JPEG2000 lossy source buffer | JPEG2000 lossless source buffer | Destination buffer
8-bit monochrome | Yes | Yes | Yes
16-bit monochrome | Yes | Yes | Yes
YUV16 packed | Yes | Yes | Yes
BGR32 packed | No | No | Yes
RGB24 planar | No | No | Yes

The following is a list of known limitations when compressing/decompressing with the Matrox Morphis JPEG2000 compression/decompression accelerator:

  • When compressing, the decomposition level can be set from 1 to 5, using MbufControl() with M_DECOMPOSITION_LEVEL.
  • The quantification tables (M_QUANTIZATION, M_QUANTIZATION_CHROMINANCE, and M_QUANTIZATION_LUMINANCE) for JPEG2000 cannot be changed when dealing with compression. Instead, they are ignored.
  • The compression buffer's x size (using MbufAlloc...() with SizeX) must be a multiple of 64.
  • The compression buffer's y size (using MbufAlloc...() with SizeY) must be a multiple of 8.

Note that if any of the previous limitations are not respected, compression will be done on the Host.

JPEG2000 tiling

If a JPEG2000 compression/decompression accelerator is present, Matrox Morphis supports JPEG2000 tiling. This is particularly useful for both the compression/decompression of very large images. Images can be compressed in rectangular tiles of the following supported sizes:

Size | Lossy format | Lossless format
256x256 | Supported | Supported
512x512 | Supported | Supported
1024x1024 | Supported | Not supported

Use MbufControl() with M_TILE_SIZE_X and M_TILE_SIZE_Y to change the tile size.

Note that the best compression/decompression speed is achieved when the buffer x-size and y-size are multiples of the tile size.

Warming up

The Matrox Morphis JPEG2000 accelerator, once configured to either compress or decompress, provides a faster rate of compression/decompression so long as it is continuously used in the same mode. For example, it is more efficient to compress multiple images one after another than to compress an image and immediately decompress that (or another) image.

A simple grab and compress

The following is an example of how JPEG2000 compression/decompression can be used.

// Allocate defaults.
MappAllocDefault(M_SETUP, &MilApplication, &MilSystem, &MilDisplay,
                                           &MilDigitizer, M_NULL);

SizeBand = MdigInquire(MilDigitizer, M_SIZE_BAND, M_NULL);
SizeX    = MdigInquire(MilDigitizer, M_SIZE_X, M_NULL);
SizeY    = MdigInquire(MilDigitizer, M_SIZE_Y, M_NULL);

// Allocate and select a display buffer.
MbufAllocColor(MilSystem, SizeBand, SizeX, SizeY, 8L+M_UNSIGNED,
               M_IMAGE + M_DISP + M_NON_PAGED, &MilImageDisp);

MbufClear(MilImageDisp, M_BLACK);
MdispSelect(MilDisplay, MilImageDisp);

// Allocate grab buffers in Host memory.
for(i = 0; i < 2; i++)
   MbufAllocColor(MilSystem, SizeBand, SizeX, SizeY, 8L+M_UNSIGNED,
                  M_IMAGE + M_GRAB, &MilImage[i]);

// Allocate grab buffers in on-board memory.
for(i = 0; i < 2; i++)
   MbufAllocColor(MilSystem, SizeBand, SizeX, SizeY, 8L+M_UNSIGNED,
                  M_IMAGE + M_GRAB + M_ON_BOARD, &MilImageOnBoard[i]);

  // Allocate JPEG2000 buffer.
  MbufAllocColor(MilSystem, SizeBand, SizeX, SizeY, 8L+M_UNSIGNED,
               M_IMAGE + M_COMPRESS + M_JPEG2000_LOSSY, &MilImageCompress);

while(!kbhit())
   {
   // Grab in to on-board memory.
   MdigGrab(MilDigitizer, MilImageOnBoard[0]);

   // Compress the buffer.
   MbufCopy(MilImageOnBoard[0], MilImageCompress);

   // Decompresses the buffer to the display.
   MbufCopy(MilImageCompress, MilImageDisp);
   }

Decompress from a Host pointer

The following is an example of how to decompress a bit-stream of a Host pointer.

while(!kbhit())
   {
   MappTimer(M_TIMER_READ, &TimeStart);

   // pJP2KCodeStream is a pointer to valid jpeg2000 data.
   MbufInquire(MilImageCompress, M_HOST_ADDRESS, &pJP2KCodeStream);

   // Map a MIL buffer on the Host pointer.
    MbufCreateColor(MilSystem,  SizeBand, SizeX, SizeY, 8L+M_UNSIGNED,
                   M_IMAGE + M_COMPRESS + M_JPEG2000_LOSSY
                   + (SizeBand == 3? M_YUV16 + M_PLANAR: 0),
                   M_HOST_ADDRESS,
                   M_DEFAULT,
                   &pJP2KCodeStream,
                   &MilImageCreateCompress);

   // Decompress the buffer.
   MbufCopy(MilImageCreateCompress, MilImageDisp);
   }

Example how to efficiently compress Host images

The following is an example of how to compress one image while grabbing another on the Host.

// Grab images into Host buffers.
for(i = 0; i < 2; i++)
   MdigGrab(MilDigitizer, MilImage[i]);

// Set the compression to be asynchronous.
MthrControl(MilSystem, M_BUS_MASTER_COPY_MODE, M_ASYNCHRONOUS);

i = 0;
MbufCopy(MilImage[i], MilImageOnBoard[i]);
while(!kbhit())
   {
   MappTimer(M_TIMER_READ, &TimeStart);

   // Perform the compression of on-board image asynchronously.
   MbufCopy(MilImageOnBoard[i], MilImageCompress);

   // While the image is being compressed, copy the next image into on-board memory.
   i = 1 - i;
   MbufCopy(MilImage[i], MilImageOnBoard[i]);

   // Wait for the compression to terminate.
   MthrWait(MilSystem, M_THREAD_WAIT, M_NULL);

   MappTimer(M_TIMER_READ, &TimeEnd);
   printf("\rPerforming precompressions of host buffers at ");
   printf(" %3.1f frames/sec", 1.0/(TimeEnd-TimeStart));
   printf(" (%1.4f sec)", (TimeEnd-TimeStart));
   }

MthrControl(MilSystem, M_BUS_MASTER_COPY_MODE, M_SYNCHRONOUS);
ON BOARD NON PAGED DECOMPOSITION LEVEL QUANTIZATION QUANTIZATION CHROMINANCE QUANTIZATION LUMINANCE TILE SIZE X TILE SIZE Y


Matrox Morphis watchdog functionality

Reference:
MsysControl
MsysHookFunction
MsysInquire

The Watchdog allows your system to automatically recover from either application or some other type of failure. The Watchdog can automatically reboot your computer when, for some reason, your computer hangs for longer than a pre-set amount of time.

Note that the Matrox Morphis PC/104-Plus does not have Watchdog functionality.

When enabled, using MsysControl() with M_WATCHDOG_MODE set to M_ENABLE, your application should send a reset signal within the time specified by the main timer. Each time the reset signal is received, Watchdog resets its main timer. If the signal is not received within the specified time allotted by the reboot timer, the Watchdog sends a hardware signal to reboot the computer.

To set the time that the Watchdog will wait before rebooting, use MsysControl() with M_WATCHDOG_TIMEOUT. Note that if the reboot timer is disabled, the warning timer will be ignored, and the main timer will trigger the reboot. To reset the Watchdog's timers, use M_WATCHDOG_RESET.

The Watchdog permits a user-defined function to be attached (hooked) to a Watchdog warning. If the Watchdog warning does not receive a response within the specified time allotted by the warning timer, the Watchdog will perform the attached user-defined function. Note that the Watchdog warning timeout value must be less than the Watchdog reboot timer. In addition the length of time it takes to perform the user-defined function should be examined to assure that it completes before the Watchdog reboot timer expires.

The Watchdog can be used either directly within your own code or as a hooked function. When hooking a function to handle a Watchdog event (which occurs when the warning timeout expires), use MsysHookFunction() with M_WATCHDOG_WARNING.

The Watchdog can also force a reboot if your computer hangs while rebooting. If the reboot process is not complete within a certain amount of time, the Watchdog will send a hardware signal to reboot the computer again. To set the time that the Watchdog will wait while booting before forcing a reboot, use M_WATCHDOG_REBOOT_TIMEOUT. The Watchdog also keeps a count of the number of times your computer reboots. Use MsysInquire() with M_WATCHDOG_RESET_COUNTER. To reset the counter that records how often your computer has rebooted use MsysControl() with M_WATCHDOG_RESET_COUNTER.

The following example shows the Watchdog in application code. Note that exactly where you call the Watchdog within your application is highly situational.

/* Initialize the Watchdog by setting the required timeout values. */
MsysControl(MilSystem, M_WATCHDOG_REBOOT_TIMEOUT, 120 * 1000); // 2 min.
MsysControl(MilSystem, M_WATCHDOG_TIMEOUT, 30 * 1000);     // 30 sec.
/* Enable the Watchdog */
MsysControl(MilSystem, M_WATCHDOG_MODE, M_ENABLE);

/* While in a processing loop, somewhere in your application,
   you must send the command to reset the watchdog timer. */
while(ProcessingLoop)
{
/* Place your application's processing loop here */
/* Reset the Watchdog's timer.*/
MsysControl(MilSystem, M_WATCHDOG_RESET, M_DEFAULT);

} /* End the processing loop */

Note that, if Watchdog functionality is required, install the appropriate cables as described in the Matrox Morphis Installation and Hardware reference manual.

WATCHDOG MODE ENABLE WATCHDOG TIMEOUT WATCHDOG RESET WATCHDOG WARNING WATCHDOG REBOOT TIMEOUT WATCHDOG RESET COUNTER WATCHDOG RESET COUNTER


Matrox Morphis utilities

Previous | Next

There are two Matrox Morphis utilities available: Usage Meter and Matrox Morphis Bench.

Usage Meter

The Usage Meter utility (UsageMeter.exe) calculates the following amounts:

  • JPEG2000 accelerator (if available) usage.
  • Grab section usage.
  • Transfer section usage.
  • On-board memory usage.

The rate of utilization in each case is expressed as a percentage.

Matrox Morphis Bench

The Matrox Morphis Bench utility (MorphisBench.exe), located in your Matrox Imaging\MIL\Morphis\Tools directory, calculates the real-time transfer speed of the PCI/PCI-X slot (in Mbytes/sec) from:

  • Matrox Morphis to Host.
  • Host to Matrox Morphis.
  • Matrox Morphis to display.


User defined signals for Matrox Morphis

Reference:
MsysControl
MsysGetHookInfo
MsysHookFunction
MsysInquire

Using the Matrox Morphis Video and I/O module, Matrox Morphis supports user-defined signals for synchronizing with or controlling other devices, such as a strobe light.

Note that the Matrox Morphis Video and I/O module is not supported on Matrox Morphis PC/104-Plus.

The relationship between the MIL user-defined signal numbers and the actual user-defined signals on the external video & I/O connector 0 are as follows.

MIL user-defined signal # | I/O | External video & I/O connector 0
0 | I/O | TTL user input/output 0
1 | I/O | TTL user input/output 1
2 | I/O | TTL user input/output 2
3 | I/O | TTL user input/output 3
4 | I/O | TTL user input/output 4
5 | I/O | TTL user input/output 5
6 | I/O | TTL user input/output 6
7 | I/O | TTL user input/output 7
8 | I/O | TTL user input/output 8
9 | I/O | TTL user input/output 9
10 | I/O | TTL user input/output 10
11 | I/O | TTL user input/output 11
12 | I/O | TTL user input/output 12
13 | I/O | TTL user input/output 13
14 | I/O | TTL user input/output 14
15 | I/O | TTL user input/output 15

Controlling and inquiring about user-defined signals

To control or inquire about user-defined signals on Matrox Morphis Dual or Quad, you need to use the M_USER_BIT_... control types or inquire types of MsysControl() and MsysInquire(), respectively.

You must set the mode of the required user-defined signals to either input or output, using MsysControl() with M_USER_BIT_MODE.

You can set the state (on/off) of the user-defined output signals using MsysControl() with M_USER_BIT_VALUE_OUT. In addition, you can inquire about the state of the user-defined input and output signals using MsysInquire() with M_USER_BIT_VALUE_IN and M_USER_BIT_VALUE_OUT, respectively.

You can control or inquire about either a specific user-defined signal or a group of user-defined signals. For an individual signal, add the MIL user-defined signal number to the control or inquire type. For a group of user-defined signals, add the M_BIT_MASK macro to the control or inquire type; the macro takes a bit-encoded mask value that identifies which user-defined signals to affect. For example, adding M_BIT_MASK(45) affects user-defined signals 0, 2, 3, and 5 since the binary equivalent is equal to 101101. Note that when controlling a group of user-defined output signals, you must set the control value to a bit-encoded value that specifies the setting for each of the user-defined signals in the group. In addition, when inquiring about a group of user-defined signals, the return value is a bit-encoded value that specifies the current setting of each of the user-defined signals in the group.

The following snippet of code shows how to set the mode and functional state of a single user-defined signal, as well as how to set the mode and functional state of two user-defined signals using a bit-encoded mask.

/* Set bit 1 to output mode */
MsysControl(M_DEFAULT_HOST,M_USER_BIT_MODE+1, M_OUTPUT);
/* Set the functional state of bit 1 to on.*/
MsysControl(M_DEFAULT_HOST,M_USER_BIT_VALUE_OUT+1, M_ON);
/* Set bits 2 and 3 to output mode. */
MsysControl(M_DEFAULT_HOST,M_USER_BIT_MODE+M_BIT_MASK(0xC), 0xC);
/* Set bit 2 to on, but bit 3 to off. */
MsysControl(M_DEFAULT_HOST,M_USER_BIT_VALUE_OUT+M_BIT_MASK(0xC), 0x4);

Interruptible user-defined signals

To handle user-defined input signals, you can either poll their state or generate an event when they change state; all user-defined signals can generate an event (interrupt). To generate an interrupt when there is a change in the state of a specified user-defined input signal:

  1. Set the user-defined signal to input mode as described above.
  2. Specify whether the user-defined input signal should generate an interrupt upon a rising edge or falling edge, using MsysControl() with M_USER_BIT_INTERRUPT_MODE set to either M_EDGE_RISING or M_EDGE_FALLING.
  3. Enable the interrupt state for the user-defined input signal, using MsysControl() with M_USER_BIT_INTERRUPT_STATE.
  4. Hook a function to the user-defined signal's change of functional state, using MsysHookFunction() with M_USER_BIT_CHANGE.
  5. Within the scope of the hook function itself, inquire which user-defined signal(s) generated the interrupt, using MsysGetHookInfo() with M_USER_BIT. Then, execute according to the result of the inquiry.

The following snippet of code demonstrates how to hook a function and its related hook data to a particular change of state of a user-defined signal (rising edge, in this case). When the interrupt mode is set to rising edge, a user-defined signal's change of state from 0 (OFF) to 1 (ON) is required to generate the interrupt. When no longer required, the specified function is then unhooked from this event.

/* Set user bit 1 to input mode. */
MsysControl(M_DEFAULT_HOST,M_USER_BIT_MODE+1, M_INPUT);
/* Set the interrupt mode to be generated on a rising edge for bit 1. */
MsysControl(M_DEFAULT_HOST,M_USER_BIT_INTERRUPT_MODE+1, M_EDGE_RISING);

/* Enable the interrupt state of bit 1. */
MsysControl(M_DEFAULT_HOST,M_USER_BIT_INTERRUPT_STATE+1, M_ENABLE);
/* Hook your function (YourHookFunction) and any related hook data (YourHookData)
* to a change of functional state of the user bit.
*/
MsysHookFunction(M_DEFAULT_HOST,M_USER_BIT_CHANGE,YourHookFunction,
(void*)&YourHookData);
/* Perform processing operations...*/
/* Unhook the function */
MsysHookFunction(M_DEFAULT_HOST,M_USER_BIT_CHANGE+M_UNHOOK,YourHookFunction,
(void*)&YourHookData);
USER BIT MODE USER BIT VALUE OUT USER BIT VALUE IN USER BIT VALUE OUT BIT MASK USER BIT INTERRUPT MODE EDGE RISING EDGE FALLING USER BIT INTERRUPT STATE USER BIT CHANGE USER BIT


Matrox Morphis board flow diagrams

Previous

This section contains data flow diagrams for the Matrox Morphis boards.

The following diagram illustrates the data flow of a Matrox Morphis Dual base board.

The following diagram illustrates the data flow of a Matrox Morphis PC/104-Plus board.

The following diagram illustrates the data flow of a Matrox Morphis Quad base board.

The following diagram illustrates the Matrox Morphis Video & I/O module.

The following diagram illustrates the Matrox Morphis Video Input module.


Matrox Odyssey

Chapter 8: Matrox Odyssey

This section discusses features of MIL that are distinct to Matrox Odyssey and ways that optimize the board's performance. Board-specific information regarding specific functions is integrated into the functions' reference topics. Refer to the milodyssey.txt file in the \Matrox Imaging\MIL\doc (or user-specified) folder for any additions/modifications to the board specific notes in this chapter or in the MIL Reference.

  • Matrox Odyssey-specific features
    • Matrox Odyssey XPro and Matrox Odyssey Xpro+
    • Other Matrox Odyssey boards
    • Summary of Matrox Odyssey features
    • Note on nomenclature
  • Using Matrox Odyssey with MIL
    • MIL on-board
  • Allocating independent MIL digitizers on Matrox Odyssey
    • Matrox Odyssey XA
    • Matrox Odyssey XD
    • Matrox Odyssey XCL
    • Matrox Odyssey Xpro/Xpro+ frame grabber modules
  • Optimizing performance
    • Transferring an image between two boards
    • Running multiple processes and threads
    • Optimized functions
    • Programming models
    • Asynchronous and synchronous functions
    • Bayer conversion
    • Memory
      • Shared memory
      • Fast Memory
  • COM ports and UARTS
  • User-defined signals for Matrox Odyssey
    • Camera Link
    • Analog
    • Digital
    • Controlling and inquiring about user-defined signals
    • Interruptible user-defined signals
  • Matrox Odyssey board flow diagrams
    • Matrox Odyssey Xpro and Matrox Odyssey Xpro+
    • Matrox Odyssey XCL, XA, and XD
      • Matrox Odyssey XCL acquisition section
      • Matrox Odyssey XA acquisition section
      • Matrox Odyssey XD acquisition section


Matrox Odyssey-specific features

Next

The Matrox Odyssey family consists of five types of configurable, PCI-X compliant, single-slot, vision processor boards: Matrox Odyssey Xpro, Matrox Odyssey Xpro+, Matrox Odyssey XCL, Matrox Odyssey XA, and Matrox Odyssey XD.

Matrox Odyssey XPro and Matrox Odyssey Xpro+

Matrox Odyssey Xpro/Xpro+ are scalable vision processor boards. They each have an optional frame grabber for image acquisition and a high-speed processing section which includes: a Matrox Oasis ASIC, a Motorola G4 PowerPC microprocessor with cache, and up to 2 Gbytes of processing memory for local processing. The Matrox Oasis ASIC integrates a CPU bridge, Links Controller with data formatters, main memory controller, and a Pixel Accelerator (PA).

Matrox OdysseyXpro/Xpro+ offer internode link ports so that multiple Xpro/Xpro+ boards can be interconnected as a cluster, allowing direct, high-speed access to each other's resources while bypassing the primary PCI/PCI-X bus. For display purposes, images can be transferred to Matrox Odyssey XG (a display board) via its link ports, or to any available display board in the computer via the primary PCI/PCI-X bus.

Matrox Odyssey Xpro+ also has a customizable FPGA co-processor for operations not accelerated by the PA. Binary operators, large LUT mappings, and warping are just a sample of the operations accelerated by the FPGA co-processor. The FPGA co-processor can be further customized by Matrox Imaging upon request.

Matrox Odyssey Xpro/Xpro+ offer the choice of using the Matrox Odyssey Camera Link frame grabber module (Camera Link module), the Matrox Odyssey analog frame grabber module (Analog module), or the Matrox Odyssey RS-422/LVDS Digital frame grabber module (Digital module) through their PCI/PCI-X mezzanine card (PMC) site and/or using a Matrox Odyssey PMC carrier board.

The Camera Link module has:

  • A dual-Base version. Allows simultaneous acquisition from two independent Camera Link cameras using the Base configuration.
  • A single-Full version. Acquires from a single Camera Link camera using the Base, Medium, or Full configuration.

The Analog and the Digital modules each have four independent acquisition paths. The Analog module is capable of high-frequency and high-fidelity analog capture, while the Digital module is a high bandwidth, RS-422/LVDS, digital frame grabber.

Other Matrox Odyssey boards

Matrox Odyssey XCL, XA, and XD differ from Xpro/Xpro+ in that they each have 512 Mbytes of memory, no L3 cache, and no link ports. They have a lower processor speed and use an integrated acquisition section instead of a PMC site. Note that the integrated acquisition section is almost identical in functionality to the associated frame grabber module for Matrox Odyssey Xpro/Xpro+.

Board type | Type of integrated acquisition section | Identical to
Matrox Odyssey XCL | Camera Link | Camera Link module
Matrox Odyssey XA | analog | Analog module¹
Matrox Odyssey XD | LVDS/RS-422 digital | Digital module

¹ Note that the integrated analog acquisition section is almost identical to the Analog module. The acquisition speed and filter are different between the two.

Matrox Odyssey XG is a graphics accelerator display board. XG has 128 Mbytes of memory and a 256-bit GPU. It has digital and analog (including TV) output capabilities, 10-bit 400 MHz RAMDACs, and multi-display support. It features two link ports, allowing image transfers from a Matrox Odyssey Xpro/Xpro+ cluster without using Host PCI/PCI-X bandwidth.

Summary of Matrox Odyssey features

The following table outlines the features currently available for each member of the Matrox Odyssey family.

Matrox Odyssey | Camera Link module² | Analog module | Digital module | XCL² | XA | XD
On-board CPU | Yes¹ | Yes¹ | Yes¹ | Yes | Yes | Yes
Memory | 2 Gbytes¹ | 2 Gbytes¹ | 2 Gbyte¹ | 512 Mbytes | 512 Mbytes | 512 Mbytes
Cache | Yes² | Yes² | Yes² | No | No | No
Scalable through link ports | Yes¹ | Yes¹ | Yes¹ | No | No | No
Customizable co-processor FPGA | Yes¹ | Yes¹ | Yes¹ | No | No | No
Matrox Oasis ASIC | Yes¹ | Yes¹ | Yes¹ | Yes | Yes | Yes
Acquisition section | Camera Link module¹ | Analog module¹ | Digital module¹ | Integrated Camera Link frame grabber section. | Integrated analog frame grabber section. | Integrated LVDS/RS-422 digital frame grabber section.
Number of acquisition paths | 1 or 2³ | 4 | 4 | 1 or 2³ | 4 | 4
Number of supported triggers | 2/digitizer, 2 that can be shared by all digitizers. | 2/digitizer, 2 that can be shared by all digitizers. | 5/digitizer. | 2/digitizer, 2 that can be shared by all digitizers. | 2/digitizer, 2 that can be shared by all digitizers. | 8/digitizer, 8 that can be shared by all digitizers.
Asynchronous reset mode support for triggers | Yes | Yes | Yes | Yes | Yes | Yes
Exposure timers per digitizer | 2/digitizer. | 2/digitizer. | 2/digitizer. | 2/digitizer. | 2/digitizer. | 2/digitizer.
Number of supported UARTS | 1/digitizer. | 1/digitizer. | 1/digitizer. | 1/digitizer. | 1/digitizer. | 1/digitizer.
Number of user-defined signals | (4 out, 4 in, and 3 I/O) /digitizer, 6 that can be shared by all digitizers. | (3 out, 4 in) /digitizer, 8 that can be shared by all digitizers. | (6 out, 11 in, 1 I/O ) /digitizer, 7 that can be shared by all digitizers. | (4 out, 4 in, and 3 I/O) /digitizer, 6 that can be shared by all digitizers. | (3 out, 4 in) /digitizer, 8 that can be shared by all digitizers. | (6 out, 11 in, 1 I/O ) /digitizer, 8 that can be shared by all digitizers.
Digital LUT | Yes | Yes | Yes | Yes | Yes | Yes

¹ On Matrox Odyssey Xpro/Xpro+.

² Matrox Odyssey XPro+ uses L2 cache while Matrox Odyssey XPro uses L3 cache.

³ The number of acquisition paths depends on whether the dual-Base (2) or the single-Full (1) version is used.

Note on nomenclature

This manual refers to all Matrox Odyssey vision processor boards as Matrox Odyssey. When necessary, it distinguishes between them using their full name.

Matrox Odyssey Xpro/Xpro+ are not listed in the MIL reference. When using Matrox Odyssey Xpro/Xpro+, refer to the following table for more information:

Reference in MIL reference | Matrox Odyssey Xpro/Xpro+.
Matrox Odyssey XA | Refers to Matrox Odyssey Xpro/Xpro+ with or without an Analog module¹ and to Matrox Odyssey XA.
Matrox Odyssey XCL | Refers to Matrox Odyssey Xpro/Xpro+ with or without a Camera Link module¹ and to Matrox Odyssey XCL.
Matrox Odyssey XD | Refers to Matrox Odyssey Xpro/Xpro+ with or without a Digital module¹ and to Matrox Odyssey XD.

¹ Matrox Odyssey Xpro/Xpro+ cannot grab data without an acquisition module unless another Matrox Odyssey Xpro/Xpro+ in the cluster has an acquisition module.

Special mention is made in the MIL documentation's specifics whenever a variant of a board (for example, Matrox Odyssey XCL dual-Base) has a known limitation or benefit.


Using Matrox Odyssey with MIL

Reference:
MdigGrab
MdigProcess
MsysAlloc

To use any Matrox Odyssey board, you must allocate it as a MIL Odyssey system using MsysAlloc() with M_SYSTEM_ODYSSEY. This allocation opens communication with the Matrox Odyssey board and allows MIL to use its resources. You can run multiple processes (executables) on the same board simultaneously. Each process can have one allocated system.

When Matrox Odyssey boards are interconnected using their link ports, they form a cluster. Each Matrox Odyssey board in a cluster must still be allocated separately. MIL will automatically detect the interconnection. If you have several Matrox Odyssey Xpro/Xpro+ boards connected together (forming a cluster), you must allocate the boards in that cluster in sequential order, starting with board 0. For example, if you have a two-board cluster, you cannot allocate board 1 before you have allocated board 0. When the boards are not connected together, they can be allocated in any order.

If the Matrox Odyssey Xpro/Xpro+ board that you allocate has a frame grabber module attached to it or any other Matrox Odyssey Xpro/Xpro+ in the cluster, you can allocate a digitizer on each system (for example, if the cluster has 2 Matrox Odyssey Xpro/Xpro+ boards with only one frame grabber, a digitizer can be allocated on both MIL systems). It is, however, more efficient to allocate it on the system where it resides.

Refer to the MilOdyssey.txt file in the \Matrox Imaging\MIL\doc directory for any additions/modifications to these board specific notes.

MIL on-board

A complete version of MIL is resident on-board Matrox Odyssey. When you call a MIL function that uses Matrox Odyssey as a system, the on-board version is called, ensuring optimum performance. This provides a royalty-free run-time environment when used exclusively with a system allocated using MsysAlloc() with M_SYSTEM_ODYSSEY. If you run the MIL algorithms on the Host (M_SYSTEM_HOST) however, you will need to purchase separate redistribution (run-time) licenses.

When grabbing with either MdigGrab() or MdigProcess(), Matrox Odyssey is optimized to have the smallest latency possible between the last pixel sent from the camera to the last pixel written into the buffer (either on-board or to the Host). This allows the buffer to be available for processing with a minimum amount of delay.

Note that it is possible to exceed the amount of memory allocated for applications (heap size) on your Matrox Odyssey. Use MilConfig to change the heap size to better suit your application. See the MilOdyssey.txt file for more details.

SYSTEM ODYSSEY SYSTEM ODYSSEY SYSTEM HOST


Allocating independent MIL digitizers on Matrox Odyssey

Reference:
MdigAlloc
MdigChannel
MsysInquire

Depending on the frame grabber, you can allocate several independent MIL digitizers. Independent digitizers have different device numbers and use different acquisition paths.

One MIL digitizer can use several acquisition paths, depending on the camera. To allow simultaneous grabs from multiple cameras that might be asynchronous, the digitizers used to grab from them should use different acquisition paths.

Matrox Odyssey XA

You can allocate up to 4 independent digitizers on Matrox Odyssey XA, depending on the cameras connected. The following table lists the acquisition paths and digitizer's device number that you should use when connecting asynchronous cameras of different types.

Each acquisition path supports input from one of two sources, therefore all digitizers have 2 data channels. You can switch between them using MdigChannel().

Synchronization signals can either come combined with the data (CSYNC), come along the data input signal of another acquisition path that is not already allocated (external analog synchronization), or come along a signal dedicated for synchronization either on the same acquisition path or another acquisition path (external digital synchronization). Note that using an acquisition path to receive an external analog synchronization signal renders that acquisition path "occupied" and not available for allocating another digitizer on that acquisition path. For example, when allocating a 3-tap (RGB) digitizer on acquisition paths 0, 1, and 2 (using MdigAlloc() with M_DEV0), you can set your synchronization signal on acquisition path 3 (using MdigChannel() with M_CH3 + M_SYNC). This results in acquisition path 3 not being available for allocation for another camera. Alternatively, if using an external digital synchronization signal on acquisition path 3 (by customizing the DCF using Matrox Intellicam), a digitizer for a monochrome camera could be allocated and use M_DEV3 simultaneously.

Matrox Odyssey XD

You can allocate up to 4 independent digitizers on Matrox Odyssey XD, depending on the cameras connected. The following table lists the acquisition paths and digitizer's device number that you should use when connecting asynchronous cameras of different types.

Synchronization signals can come along the same acquisition path as the data. Note that MdigChannel() with M_CHn+M_SYNC is not supported on Matrox Odyssey XD.

Matrox Odyssey XCL

The number of independent digitizers that you can allocate on Matrox Odyssey XCL is determined by the version in use. There are two versions of Matrox Odyssey XCL available:

  • Single-Full. The single-Full version has only one acquisition path (M_DEV0) with only one data channel (MdigChannel() with M_CH0).
  • Dual-Base. The dual-Base version has two acquisition paths (M_DEV0 and M_DEV1), but each has only one data channel (MdigChannel() with M_CH0).

Matrox Odyssey Xpro/Xpro+ frame grabber modules

When frame grabber modules are present in a cluster, you can allocate digitizers (using MdigAlloc()) that use the acquisition paths of any of the modules within the cluster. In a cluster, the acquisition paths of all modules present are associated with sequential device numbers, determined by MIL. The following graphic depicts an Analog module and the dual-Base version of a Camera Link module as two frame grabber modules present in the same cluster.

In the above graphic, MIL has numbered the acquisition paths of the Analog module before those of the Camera Link module. Note that the position of each module within a cluster is determined by MIL and not the user. The acquisition paths on the Analog module are associated with M_DEV0 to M_DEV3. The acquisition paths on the Camera Link module are associated with M_DEV4 to M_DEV5.

You can only allocate a digitizer that uses the acquisition paths on one frame grabber module. In addition, only certain acquisition paths can be used, depending on the type of camera. Refer to the tables above displaying the list of acquisition paths and digitizer device numbers to be used when connecting cameras of different types.

To determine the total number of acquisition paths in the cluster, use MsysInquire() with M_DIGITIZER_NUM. To determine which device number associates with which board, use MsysInquire() with M_DIGITIZER_TYPE + M_DEVn.

CH3 + M SYNC CH0 CH0 DIGITIZER NUM DIGITIZER TYPE DEVn


Optimizing performance

User Guide:
Multi-processing
Multi-threading
Using buffers with the Bayer color filter

Reference:
MbufBayer
MbufInquire
MdigControl
MsysInquire
MthrControl
MthrWait

There are several ways to improve the overall performance of your applications with Matrox Odyssey. Understanding how MIL fully takes advantage of the board can help you develop optimized applications.

Transferring an image between two boards

The MbufCopy...() functions provide the best possible use of system resources, including speed in transferring data. If the source and destination buffers are on different systems that are in the same cluster, MbufCopy...() functions will send the information from one to the other over the high-speed internode communication link ports, rather than over the PCI/PCI-X bus.

Running multiple processes and threads

Several processes (executables) can run simultaneously on Matrox Odyssey. On-board resources can be shared by different processes, running at the same time. The memory used by one process is protected from all other processes. MIL applications are autonomous processes (or executables) and therefore can profit from multi-processing by executing independently. For more information, see the Multi-processing section in Chapter 22: Using MIL with multi-processing and under multi-thread systems of the MIL User Guide.

Multi-threaded applications are possible with Matrox Odyssey. To control the threads and manage events, use MIL's thread module (Mthr...()). Note that when MIL is running on Matrox Odyssey, every Host (Windows) thread that sends MIL functions has an equivalent Matrox Odyssey on-board thread that executes them. For information on MIL multi-threading, see the Multi-threading section in Chapter 22: Using MIL with multi-processing and under multi-thread systems of the MIL User Guide.

Optimized functions

Most neighborhood operations (including convolutions and morphological operations), point-to-point, and certain statistical functions are accelerated using the Pixel Accelerator (PA), included in the Matrox Oasis ASIC. MIL functions that are compute-intensive, such as convolution functions, benefit from the PA's speed. The PA considerably reduces the time required by compute-intensive operations.

Refer to the OdysseyPA.txt file in the \Matrox Imaging\MIL\DOC directory for a list of the accelerated functions, as well as the latest information on this topic.

Programming models

Application programs for Matrox Odyssey can run in a Host-driven or fully embedded mode. In the Host-driven mode, the application program runs on the CPU of the Host and remotely sends commands to the version of MIL that is on-board Matrox Odyssey, for execution. The Host-driven mode is the easiest to implement but is subject to the lack of determinism of the Host (that is, the Host might not respond on time or get interrupted by another task). In the fully embedded mode, the application program runs directly on the G4 PowerPC microprocessor. The application program has little or no interaction with the Host platform, ensuring deterministic behavior. Using the fully embedded mode requires the Matrox Odyssey Developer's Toolkit.

Asynchronous and synchronous functions

Matrox Odyssey is capable of processing both asynchronously and synchronously from the Host. Typically, whenever a function has a return value, that function is executed synchronously. When Matrox Odyssey is in fully embedded mode and running on-board, all functions are synchronous. In Host-driven mode, when sending functions to the board, the functions can be queued so long as the function does not return a value. Whenever possible, the functions are asynchronous from the Host's point of view.

Note that some functions can be performed synchronously if they are configured appropriately (using MthrControl() with M_THREAD_MODE, MdigControl() with M_GRAB_MODE, and MthrWait() with M_EVENT_SYNCHRONIZE).

Bayer conversion

Matrox Odyssey XCL supports automatic Bayer conversion when grabbing from a camera that has a Bayer color filter (as specified by the DCF). To disable this feature, if specifying such a DCF, use MdigControl() with M_BAYER_CONVERSION set to disable. During conversion, the image can be white balanced if white balancing is enabled with MdigControl() with M_WHITE_BALANCE.

The white balance coefficients can be set explicitly using MdigControl() with M_BAYER_COEFFICIENTS_ID or calculated automatically using MdigControl() with M_WHITE_BALANCE set to M_CALCULATE.

The M_BAYER_... control types can only be used when grabbing from a camera that has a Bayer color filter (as specified by the DCF), otherwise an error will be generated.

For a more conventional technique of controlling Bayer conversion, use MbufBayer(). Note that with the more conventional technique, the conversion is not done as data is grabbed. For more information, see the Using buffers with the Bayer color filter section in Chapter 14: Specifying and managing your data buffers.

Memory

By default, all buffers are allocated in on-board, unshared memory. If allocated specifically in Host memory, the buffer can be allocated in either paged or non-paged memory. If allocated specifically on-board, the buffer can be allocated in either unshared (the default), shared, or fast memory.

Shared memory

Shared memory is the amount of on-board memory that is visible to the PCI bus. This amount is configurable through MILConfig. When buffers are allocated in shared memory, they have both a physical address and a logical address on the Host. Buffers not allocated in shared memory have neither a physical address recognized by the Host, nor a logical address on the Host, but can still be accessed and used by all MIL functions, except MbufCreate...().

Note that you can only use MbufCreate...() with shared or Host memory because it relies on having either a physical or logical address recognized by the Host.

You can inquire both the total amount of memory available, using MsysInquire() with M_MEMORY_FREE, and the amount of shared memory available, using MsysInquire() with M_SHARED_MEMORY_FREE.

Note that buffers allocated on-board Matrox Odyssey must fit within either the amount of shared memory or the amount of unshared memory. For example, if your board has 256 Mbytes and you have configured it to have 128 Mbytes of shared and 128 Mbytes of unshared memory, the largest buffer that you could allocate in either type of memory would be 128 Mbytes. If you need to allocate a buffer larger than the size of either memory type, use MilConfig to change the memory configuration for your board. When the shared memory size is not large enough for the buffer, an error is returned.

Fast Memory

Fast memory is the amount of on-board memory in the L3 external cache (up to 2 Mbytes). It must be enabled using the OdcMon utility before it can be used. When buffers are allocated in fast memory, they can only be accessed by the G4 PowerPC microprocessor. Therefore, depending on the operation, allocating a buffer in fast processing memory might not accelerate processing.

To force a buffer into fast memory, allocate it with the M_FAST_MEMORY attribute.

Use MbufInquire() with the M_EXTENDED_ATTRIBUTE inquire type to determine if the buffer was allocated in fast memory. You can inquire both the total amount of memory available, using MsysInquire() with M_MEMORY_FREE, and the amount of fast memory available, using MsysInquire() with M_FAST_MEMORY_FREE.

Note that buffers allocated in fast memory must fit within the 2 Mbytes of memory available for fast processing. If it does not fit, the buffer will be allocated in ordinary processing memory instead.

THREAD MODE GRAB MODE EVENT SYNCHRONIZE BAYER CONVERSION WHITE BALANCE BAYER COEFFICIENTS ID WHITE BALANCE CALCULATE MEMORY FREE SHARED MEMORY FREE EXTENDED ATTRIBUTE MEMORY FREE FAST MEMORY FREE


COM ports and UARTS

Reference:
MdigControl

Matrox Odyssey offers RS-232 compatible serial interfaces (each controlled by a UART). Each interface is mapped as a COM port so that it can be accessed through the Microsoft Windows API.

Use the Microsoft Win32 library to access and control the serial ports. To view them in a Microsoft Windows operating system, refer to Microsoft Window's device manager, under Ports (COM & LPT). Alternately, MIL can control and access the serial ports (use MdigControl() with M_UART...). For more information, refer to the Matrox Odyssey Installation and Hardware Reference manual.

With Matrox Odyssey XCL, the Camera Link manufacturer's camera configuration application can access and control the serial ports, as well as any Camera Link camera.


User-defined signals for Matrox Odyssey

Reference:
MdigControl
MdigGetHookInfo
MdigHookFunction
MdigInquire

Matrox Odyssey supports user-defined signals for synchronizing with or controlling other devices, such as a strobe light.

MIL user-defined signal numbers map to different signals depending on the type of frame grabber (XCL, XA, or XD) and the device number specified for an allocated digitizer. Most of these user-defined signals are actually multi-purpose auxiliary signals and can only be used as user-defined signals if they are not defined/used for another purpose. See the Matrox Odyssey Installation and Hardware Reference manual for more details.

Camera Link

The relationship between the MIL user-defined signal numbers and the actual user-defined signals for an M_DEV0 digitizer on Matrox Odyssey XCL are as follows:

MIL user-defined signal # | I/O | External Auxiliary I/O Connector 0 (HD-44) | External auxiliary I/O connector 1 (DB-9) | Camera Link video input connector 0 (MDR)
0 | O | P0_LVDS_AUX_OUT0 |  |
1 | O | P0_LVDS_AUX_OUT1 |  |
2 | I/O |  | P0_TTL_AUX_IO_0 |
3 | I/O | P0_TTL_AUX_IO_1 |  |
4 | I/O | TTL_AUX_IO_0¹ |  |
5 | I/O | TTL_AUX_IO_1¹ |  |
6 | I | LVDS_AUX_IN0¹ |  |
7 | I | LVDS_AUX_IN1¹ |  |
8 | I | OPTO_AUX_IN0¹ |  |
9 | I | OPTO_AUX_IN1¹ |  |
10 | I | P0_LVDS_AUX_IN0 |  |
11 | I | P0_LVDS_AUX_IN1 |  |
12 | I |  | P0_OPTO_AUX_IN0 |
13 | I |  | P0_OPTO_AUX_IN1 |
M_CC1 | O |  |  | CC1²
M_CC2 | O |  |  | CC2²
M_CC3 | O |  |  | CC3²
M_CC4 | O |  |  | CC4²

The relationship between the MIL user-defined signal numbers and the actual user-defined signals for an M_DEV1 digitizer on Matrox Odyssey XCL are as follows:

MIL user-defined signal # | I/O | External Auxiliary I/O Connector 0 (HD-44) | Camera Link video input connector 1 (MDR)
0 | O | P1_LVDS_AUX_OUT0 |
1 | O | P1_LVDS_AUX_OUT1 |
2 | I/O | P1_TTL_AUX_IO_0 |
3 | I/O | P1_TTL_AUX_IO_1 |
4 | I/O | TTL_AUX_IO_0¹ |
5 | I/O | TTL_AUX_IO_1¹ |
6 | I | LVDS_AUX_IN0¹ |
7 | I | LVDS_AUX_IN1¹ |
8 | I | OPTO_AUX_IN0¹ |
9 | I | OPTO_AUX_IN1¹ |
M_CC1 | O |  | CC1²
M_CC2 | O |  | CC2²
M_CC3 | O |  | CC3²
M_CC4 | O |  | CC4²

¹ Note that these are shared user-defined signals between digitizers. If used by one digitizer, they can be simultaneously used by the other that shares this user-defined signal.

² Note that you can only output 2 different signals on the 4 signals available.

Analog

The relationship between the MIL user-defined signal numbers and the actual user-defined signals for an M_DEV0 digitizer on Matrox Odyssey XA are as follows:

MIL user-defined signal # | I/O | External Auxiliary I/O Connector 0 (HD-44) | External auxiliary I/O connector 1 (DB-9) | Analog Video Input Connector (DVI-0) | Analog Video Input Connector (DVI-1)
0 | O | P0_LVDS/TTL_AUX_OUT0 |  |  |
1 | O | P0_LVDS/TTL_AUX_OUT1 |  |  |
2 | O |  |  | P0_TTL_AUX(EXP)_OUT |
3 | I |  |  | P0_TTL_AUX(TRIG)_IN |
4 | I |  | P0_OPTO_AUX(TRIG)_IN |  |
5 | I | LVDS/TTL_AUX_IN0¹ |  |  |
6 | I | LVDS/TTL_AUX_IN1¹ |  |  |
7 | I | LVDS/TTL_AUX_IN2¹ |  |  |
8 | I | LVDS/TTL_AUX_IN3¹ |  |  |
9 | I | LVDS/TTL_AUX_IN4¹ |  |  |
10 | I | LVDS/TTL_AUX_IN5¹ |  |  |
11 | I | LVDS/TTL_AUX_IN6¹ |  |  |
12 | I | LVDS/TTL_AUX_IN7¹ |  |  |

The relationship between the MIL user-defined signal numbers and the actual user-defined signals for an M_DEV1 digitizer on Matrox Odyssey XA are as follows:

MIL user-defined signal # | I/O | External Auxiliary I/O Connector 0 (HD-44) | External auxiliary I/O connector 1 (DB-9) | Analog Video Input Connector (DVI-0) | Analog Video Input Connector (DVI-1)
0 | O | P1_LVDS/TTL_AUX_OUT0 |  |  |
1 | O | P1_LVDS/TTL_AUX_OUT1 |  |  |
2 | O |  |  | P1_TTL_AUX(EXP)_OUT |
3 | I |  |  | P1_TTL_AUX(TRIG)_IN |
4 | I |  | P1_OPTO_AUX(TRIG)_IN |  |
5 | I | LVDS/TTL_AUX_IN0¹ |  |  |
6 | I | LVDS/TTL_AUX_IN1¹ |  |  |
7 | I | LVDS/TTL_AUX_IN2¹ |  |  |
8 | I | LVDS/TTL_AUX_IN3¹ |  |  |
9 | I | LVDS/TTL_AUX_IN4¹ |  |  |
10 | I | LVDS/TTL_AUX_IN5¹ |  |  |
11 | I | LVDS/TTL_AUX_IN6¹ |  |  |
12 | I | LVDS/TTL_AUX_IN7¹ |  |  |

The relationship between the MIL user-defined signal numbers and the actual user-defined signals for an M_DEV2 digitizer on Matrox Odyssey XA are as follows:

MIL user-defined signal # | I/O | External Auxiliary I/O Connector 0 (HD-44) | External auxiliary I/O connector 1 (DB-9) | Analog Video Input Connector (DVI-0) | Analog Video Input Connector (DVI-1)
0 | O | P2_LVDS/TTL_AUX_OUT0 |  |  |
1 | O | P2_LVDS/TTL_AUX_OUT1 |  |  |
2 | O |  |  | P2_TTL_AUX(EXP)_OUT |
3 | I |  |  | P2_TTL_AUX(TRIG)_IN |
4 | I |  | P2_OPTO_AUX(TRIG)_IN |  |
5 | I | LVDS/TTL_AUX_IN0¹ |  |  |
6 | I | LVDS/TTL_AUX_IN1¹ |  |  |
7 | I | LVDS/TTL_AUX_IN2¹ |  |  |
8 | I | LVDS/TTL_AUX_IN3¹ |  |  |
9 | I | LVDS/TTL_AUX_IN4¹ |  |  |
10 | I | LVDS/TTL_AUX_IN5¹ |  |  |
11 | I | LVDS/TTL_AUX_IN6¹ |  |  |
12 | I | LVDS/TTL_AUX_IN7¹ |  |  |

The relationship between the MIL user-defined signal numbers and the actual user-defined signals for an M_DEV3 digitizer on Matrox Odyssey XA are as follows:

MIL user-defined signal # | I/O | External Auxiliary I/O Connector 0 (HD-44) | External auxiliary I/O connector 1 (DB-9) | Analog Video Input Connector (DVI-0) | Analog Video Input Connector (DVI-1)
0 | O | P3_LVDS/TTL_AUX_OUT0 |  |  |
1 | O | P3_LVDS/TTL_AUX_OUT1 |  |  |
2 | O |  |  | P3_TTL_AUX(EXP)_OUT |
3 | I |  |  | P3_TTL_AUX(TRIG)_IN |
4 | I |  | P3_OPTO_AUX(TRIG)_IN |  |
5 | I | LVDS/TTL_AUX_IN0¹ |  |  |
6 | I | LVDS/TTL_AUX_IN1¹ |  |  |
7 | I | LVDS/TTL_AUX_IN2¹ |  |  |
8 | I | LVDS/TTL_AUX_IN3¹ |  |  |
9 | I | LVDS/TTL_AUX_IN4¹ |  |  |
10 | I | LVDS/TTL_AUX_IN5¹ |  |  |
11 | I | LVDS/TTL_AUX_IN6¹ |  |  |
12 | I | LVDS/TTL_AUX_IN7¹ |  |  |

¹ Note that these are shared user-defined signals between digitizers. If used by one digitizer, they can be simultaneously used by all others that share this user-defined signal.

Digital

The relationship between the MIL user-defined signal numbers and the actual user-defined signals for an M_DEV0 digitizer on Matrox Odyssey XD are as follows:

MIL user-defined signal # | I/O | Digital video input connector 0 | External aux. I/O connector 0 (HD 44) | External aux. I/O connector 1 (DB 9)
0 | O | P0_LVDS_AUX(CLK)_OUT |  |
1 | O | P0_LVDS/TTL_AUX(HSYNC)_OUT0 |  |
2 | O | P0_LVDS/TTL_AUX(VSYNC)_OUT1 |  |
3 | O | P0_LVDS/TTL_AUX(EXP)_OUT2 |  |
4 | O | P0_LVDS/TTL_AUX(EXP)_OUT3 |  |
5 | I/O | P0_ TTL_AUX(TRIG)_IO |  |
6 | O |  | P0_ TTL_AUX(EXP)_OUT |
7 | I | P0_LVDS_AUX(VSYNC)_IN |  |
8 | I |  | P0_OPTO_AUX(TRIG)_IN0 |
9 | I |  |  | P0_OPTO_AUX(TRIG)_IN1
10 | I |  | LVDS/TTL_AUX(TRIG)_IN0¹ |
11 | I |  | LVDS/TTL_AUX(TRIG)_IN1¹ |
12 | I |  | LVDS/TTL_AUX(TRIG)_IN2¹ |
13 | I |  | LVDS/TTL_AUX(TRIG)_IN3¹ |
14 | I |  | LVDS/TTL_AUX(TRIG)_IN4¹ |
15 | I |  | LVDS/TTL_AUX(TRIG)_IN5¹ |
16 | I |  | LVDS/TTL_AUX(TRIG)_IN6¹ |
17 | I |  | LVDS/TTL_AUX(TRIG)_IN7¹ |

The relationship between the MIL user-defined signal numbers and the actual user-defined signals for an M_DEV1 digitizer on Matrox Odyssey XD are as follows:

MIL user-defined signal # | I/O | Digital video input connector 0 | External aux. I/O connector 0 (HD 44) | External aux. I/O connector 1 (DB 9)
0 | O | P1_LVDS_AUX(CLK)_OUT |  |
1 | O | P1_LVDS/TTL_AUX(HSYNC)_OUT0 |  |
2 | O | P1_LVDS/TTL_AUX(VSYNC)_OUT1 |  |
3 | O | P1_LVDS/TTL_AUX(EXP)_OUT2 |  |
4 | O | P1_LVDS/TTL_AUX(EXP)_OUT3 |  |
5 | I/O | P1_ TTL_AUX(TRIG)_IO |  |
6 | O |  | P1_ TTL_AUX(EXP)_OUT |
7 | I | P1_LVDS_AUX(VSYNC)_IN |  |
8 | I |  | P1_OPTO_AUX(TRIG)_IN0 |
9 | I |  |  | P1_OPTO_AUX(TRIG)_IN1
10 | I |  | LVDS/TTL_AUX(TRIG)_IN0¹ |
11 | I |  | LVDS/TTL_AUX(TRIG)_IN1¹ |
12 | I |  | LVDS/TTL_AUX(TRIG)_IN2¹ |
13 | I |  | LVDS/TTL_AUX(TRIG)_IN3¹ |
14 | I |  | LVDS/TTL_AUX(TRIG)_IN4¹ |
15 | I |  | LVDS/TTL_AUX(TRIG)_IN5¹ |
16 | I |  | LVDS/TTL_AUX(TRIG)_IN6¹ |
17 | I |  | LVDS/TTL_AUX(TRIG)_IN7¹ |

The relationship between the MIL user-defined signal numbers and the actual user-defined signals for an M_DEV2 digitizer on Matrox Odyssey XD are as follows:

MIL user-defined signal # | I/O | Digital video input connector 0 | External aux. I/O connector 0 (HD 44) | External aux. I/O connector 1 (DB 9)
0 | O | P2_LVDS_AUX(CLK)_OUT |  |
1 | O | P2_LVDS/TTL_AUX(HSYNC)_OUT0 |  |
2 | O | P2_LVDS/TTL_AUX(VSYNC)_OUT1 |  |
3 | O | P2_LVDS/TTL_AUX(EXP)_OUT2 |  |
4 | O | P2_LVDS/TTL_AUX(EXP)_OUT3 |  |
5 | I/O | P2_ TTL_AUX(TRIG)_IO |  |
6 | O |  | P2_ TTL_AUX(EXP)_OUT |
7 | I | P2_LVDS_AUX(VSYNC)_IN |  |
8 | I |  | P2_OPTO_AUX(TRIG)_IN0 |
9 | I |  |  | P2_OPTO_AUX(TRIG)_IN1
10 | I |  | LVDS/TTL_AUX(TRIG)_IN0¹ |
11 | I |  | LVDS/TTL_AUX(TRIG)_IN1¹ |
12 | I |  | LVDS/TTL_AUX(TRIG)_IN2¹ |
13 | I |  | LVDS/TTL_AUX(TRIG)_IN3¹ |
14 | I |  | LVDS/TTL_AUX(TRIG)_IN4¹ |
15 | I |  | LVDS/TTL_AUX(TRIG)_IN5¹ |
16 | I |  | LVDS/TTL_AUX(TRIG)_IN6¹ |
17 | I |  | LVDS/TTL_AUX(TRIG)_IN7¹ |

The relationship between the MIL user-defined signal numbers and the actual user-defined signals for an M_DEV3 digitizer on Matrox Odyssey XD are as follows:

MIL user-defined signal # | I/O | Digital video input connector 0 | External aux. I/O connector 0 (HD 44) | External aux. I/O connector 1 (DB 9)
0 | O | P3_LVDS_AUX(CLK)_OUT |  |
1 | O | P3_LVDS/TTL_AUX(HSYNC)_OUT0 |  |
2 | O | P3_LVDS/TTL_AUX(VSYNC)_OUT1 |  |
3 | O | P3_LVDS/TTL_AUX(EXP)_OUT2 |  |
4 | O | P3_LVDS/TTL_AUX(EXP)_OUT3 |  |
5 | I/O | P3_ TTL_AUX(TRIG)_IO |  |
6 | O |  | P3_ TTL_AUX(EXP)_OUT |
7 | I | P3_LVDS_AUX(VSYNC)_IN |  |
8 | I |  | P3_OPTO_AUX(TRIG)_IN0 |
9 | I |  |  | P3_OPTO_AUX(TRIG)_IN1
10 | I |  | LVDS/TTL_AUX(TRIG)_IN0¹ |
11 | I |  | LVDS/TTL_AUX(TRIG)_IN1¹ |
12 | I |  | LVDS/TTL_AUX(TRIG)_IN2¹ |
13 | I |  | LVDS/TTL_AUX(TRIG)_IN3¹ |
14 | I |  | LVDS/TTL_AUX(TRIG)_IN4¹ |
15 | I |  | LVDS/TTL_AUX(TRIG)_IN5¹ |
16 | I |  | LVDS/TTL_AUX(TRIG)_IN6¹ |
17 | I |  | LVDS/TTL_AUX(TRIG)_IN7¹ |

¹ Note that these are shared user-defined signals between digitizers. If used by one digitizer, they can be simultaneously used by all others that share this user-defined signal.

Controlling and inquiring about user-defined signals

To control or inquire about user-defined signals on Matrox Odyssey, you need to use the M_USER_BIT_... control types or inquire types of MdigControl() and MdigInquire(), respectively.

To use user-defined I/O (bi-directional) signals, you must set their mode to either input or output, using the MdigControl() with M_USER_BIT_MODE.

You can set the state (on/off) of the user-defined output signals using MdigControl() with M_USER_BIT_VALUE. In addition, you can inquire about the state of the user-defined input and output signals using MdigInquire() with M_USER_BIT_VALUE.

You can control or inquire about either a specific user-defined signal or a group of user-defined signals. For an individual signal, add the MIL user-defined signal number to the control or inquire type. For a group of user-defined signals, add the M_BIT_MASK macro to the control or inquire type; the macro takes a bit-encoded mask value that identifies which user-defined signals to affect. For example on Matrox Odyssey XCL, adding M_BIT_MASK(45) affects user-defined signals 0, 2, 3, and 5 since the binary equivalent is equal to 101101. Note that when controlling a group of user-defined output signals, you must set the control value to a bit-encoded value that specifies the setting for each of the user-defined signals in the group. In addition, when inquiring about a group of user-defined signals, the return value is a bit-encoded value that specifies the current setting of each of the user-defined signals in the group.

Interruptible user-defined signals

To handle user-defined input signals, you can either poll their state or generate an event when they change state; all user-defined input signals can generate an event (interrupt). To generate an interrupt when there is a change in the state of a specified user-defined input signal:

  1. If bi-directional (I/O), set the user-defined signal to input mode as described above.
  2. Enable the interrupt state for the user-defined input signal, using MdigControl() with M_USER_BIT_INTERRUPT_STATE. The user-defined signal will generate an interrupt upon a rising edge.
  3. Hook a function to the user-defined signal's change of functional state, using MdigHookFunction() with M_USER_BIT_CHANGE.
  4. Within the scope of the hook function itself, inquire which user-defined signal(s) generated the interrupt, using MdigGetHookInfo() with M_USER_BIT. Then, execute according to the result of the inquiry.
USER BIT MODE USER BIT VALUE USER BIT VALUE BIT MASK USER BIT INTERRUPT STATE USER BIT CHANGE USER BIT


Matrox Odyssey board flow diagrams

Previous

This section contains data flow diagrams for Matrox Odyssey boards.

Matrox Odyssey Xpro and Matrox Odyssey Xpro+

The following diagram illustrates the data flow of Matrox Odyssey Xpro.

The following diagram illustrates the data flow of Matrox Odyssey Xpro+.

Matrox Odyssey XCL, XA, and XD

The following diagram illustrates the data flow of Matrox Odyssey XCL, XA, and XD.

Matrox Odyssey XCL acquisition section

The following diagram illustrates the acquisition section of the dual-Base Matrox Odyssey XCL.

The following diagram illustrates the acquisition section of the single-Full Matrox Odyssey XCL.

Matrox Odyssey XA acquisition section

The following diagram illustrates the acquisition section of Matrox Odyssey XA.

Matrox Odyssey XD acquisition section

The following diagram illustrates the acquisition section of Matrox Odyssey XD.


Matrox Orion

Chapter 9: Matrox Orion

This chapter discusses features of MIL that are particular to the different Matrox Orion boards and ways that optimize each board's performance. Board-specific information regarding specific functions is integrated into the functions' reference topics. Refer to the milorion.txt file in the \Matrox Imaging\MIL\doc (or user-specified) folder for any additions/modifications to the board specific notes in this chapter or in the MIL Reference.

  • Matrox Orion-specific features
    • Display features
  • Using Matrox Orion with MIL
  • Cameras that can be connected to Matrox Orion
  • Simultaneous real-time grab transfer to the display and Host
  • Using the encoder
  • User-defined signals for Matrox Orion
    • Controlling and inquiring about user-defined signals
  • Matrox Orion board flow diagram
    • Matrox Orion
    • 4Sight-II add-on boards


Matrox Orion-specific features

See Also | Next

Matrox Orion is a frame grabber capable of acquiring standard monochrome video in RS-170/CCIR format, composite (CVBS) and component (Y/C) color video in NTSC/PAL format, and RGB video. Matrox Orion is available in both PCI and AGP configurations, and as grab modules on Matrox 4Sight-II.

The number of monochrome, composite, Y/C, or RGB cameras that can be attached to the Matrox Orion depends on the version of the board. See the the Cameras that can be connected to Matrox Orion section later in this chapter.

Matrox Orion also has three 256 x 8-bit input lookup tables (LUTs) that support any input source and image format. Note that there are no input LUTs on Matrox Orion /Standard for 4Sight-II.

Matrox Orion supports a grab feature that allows you to simultaneously perform a continuous grab into display memory, and a grab into Host memory for processing. This feature is available when allocating your digitizer.

When acquiring data on Matrox Orion (for AGP), the values 0 and 255 are reserved. Therefore, the range of possible input values spans from 1 to 254.

Matrox Orion can be used as a hardware fingerprint for run-time licenses.

Matrox Orion supports Windows 2000 and XP.

Display features

With its MGA G400 controller and 32-Mbyte frame buffer (display memory), Matrox Orion can deliver a true color (32-bit) image display with a 32-bit color overlay, for a completely true-color display at up to 1280x1024 resolution; the maximum refresh rate is 75 Hz, depending on your monitor. Matrox Orion can configure the overlay frame buffer (display memory used for the Windows desktop) in 8-bit monochrome format or 32-bit RGB format (BGR32 packed), thereby supporting either of these Windows display resolutions. In addition, Matrox Orion features non-destructive graphics overlay, and support for video-in-a-window with arbitrary video scaling (up or down).

Since the display section is controlled by the MGA G400 chip, Matrox Orion features DualHead display technology, which provides the ability to simultaneously have an independent analog VGA output and TV output.


Using Matrox Orion with MIL

Reference:
MsysAlloc

To use your Matrox Orion board with MIL, you must allocate an Orion system (M_SYSTEM_ORION), using MsysAlloc(). This allocation opens communication with the Matrox Orion board and allows MIL to use its resources. You can run only one process (executable) on a Matrox Orion board. The process can allocate a system for this board only once.

Refer to the MILOrion.txt file in the \Matrox Imaging\MIL\doc folder for any additions/modifications to these board specific notes.

SYSTEM ORION


Cameras that can be connected to Matrox Orion

Reference:
MdigChannel

The number of composite/monochrome, Y/C, or RGB cameras that can be attached to your Matrox Orion board depends on the number of channels available for acquisition from that type of camera on your version of Matrox Orion and the data path used. The following table lists the maximum number of cameras that can be attached for each available type of Matrox Orion board. You can switch the grab between cameras of the same type using MdigChannel().

Board | Type of camera | Number of cameras
Matrox Orion (for AGP/PCI) | Monochrome RS-170/CCIR | 6 (using the RGB path) or 8 (using the decoder path)
 | Composite NTSC/PAL | 8
 | Y/C | 4
 | RGB | 2
Matrox Orion /RGB for 4Sight-II | Monochrome RS-170/CCIR | 6 (using the RGB path) or 12 (using the decoder path)
 | Composite NTSC/PAL | 12
 | Y/C | 6
 | RGB | 2
Matrox Orion /Standard for 4Sight-II | Monochrome RS-170/CCIR | 12
 | Composite NTSC/PAL | 12
 | Y/C | 6
Matrox Orion /Dual for 4Sight-II | Monochrome RS-170/CCIR | 24
 | Composite NTSC/PAL | 24
 | Y/C | 12

When grabbing from the RGB path, two calls (MdigChannel() with M_CHn + M_SIGNAL and MdigChannel() with M_CHn + M_SYNC) can be made to control the channel of the data and synchronization signals, respectively.

SIGNAL


Simultaneous real-time grab transfer to the display and Host

Reference:
MdigAlloc
MdigGrab
MdigGrabContinuous

Matrox Orion has a special feature that permits real-time simultaneous transfers of grabbed images to display memory and Host memory. For example, an application can perform a continuous color grab in a buffer selected on the display and at the same time, grab in a monochrome Host buffer for processing.

To use this feature, two digitizers must be allocated. Both digitizers must have the same device number (M_DEV0) and the same DCF because physically, the same acquisition paths are used for both calls to MdigAlloc().

After the digitizers are allocated, you can then call MdigGrabContinuous() to grab into a buffer selected on the display, using one of the digitizer identifiers, and call MdigGrab() to grab into a Host buffer using the other digitizer identifier. This results in the same grabbed image being transferred to each buffer in their respective destination formats.

Both the buffer selected to the display and the Host buffer need not be in the same format or the same size. In addition, the M_GRAB_MODE and M_GRAB_SCALE control types can be independently set for each digitizer; all other controls will be used for both digitizers. Changing any other control for one digitizer, will affect the other.

The following example shows how to maintain a continuous color grab in the display and at the same time, grab in a monochrome Host buffer for processing.

MDigMultDestination.c
GRAB MODE GRAB SCALE


Using the encoder

Previous | Next

Matrox Orion's display section features an on-board encoder. The video encoder can be programmed to output composite (CVBS) and component (Y/C) video in NTSC/PAL formats. It can also output component RGB video with the same resolution and refresh rate as video in NTSC/PAL formats. To output from the encoder, use an auxiliary display with an encoder-supported output format. On Matrox Orion, the overlay buffer associated with such an auxiliary display will be driven by the graphics controller.

Note that during a continous grab, the display is non-tearing.


User-defined signals for Matrox Orion

Reference:
MdigControl
MdigInquire

Matrox Orion supports user-defined signals for synchronizing with or controlling other devices, such as a strobe light.

The relationship between the MIL user-defined signal numbers and the actual user-defined signals on the expanded video I/O connector are as follows:

MIL user-defined signal # | I/O | Expanded video I/O connector signal
1 | I | USER1IN signal.
2 | I | USER2IN signal.
3 | O | USER1OUT signal.
4 | O | USER2OUT signal.

Note that there is no user-defined signal 0 for this board.

Controlling and inquiring about user-defined signals

To control or inquire about user-defined signals on Matrox Orion, you need to use the M_USER_BIT_... control types or inquire types of MdigControl() and MdigInquire(), respectively.

You can set the state (on/off) of the user-defined output signals using MdigControl() with M_USER_BIT_VALUE. In addition, you can inquire about the state of the user-defined input and output signals using MdigInquire() with M_USER_BIT_VALUE.

USER BIT VALUE USER BIT VALUE


Matrox Orion board flow diagram

Previous

This section contains data flow diagrams for the different versions of a Matrox Orion.

Matrox Orion

The following diagram illustrates the data flow of a Matrox Orion board.

4Sight-II add-on boards

The following diagram illustrates the data flow of a Matrox Orion /Standard for 4Sight-II

The following diagram illustrates the data flow of a Matrox Orion /Dual for 4Sight-II

The following diagram illustrates the data flow of a Matrox Orion /RGB


Matrox Solios

Chapter 10: Matrox Solios

This section discusses features of MIL that are distinct to Matrox Solios and ways that optimize the board's performance. Board-specific information regarding specific functions is integrated into the functions' reference topics. Refer to the milsolios.txt file in the \Matrox Imaging\MIL\doc (or user-specified) folder for any additions/modifications to the board specific notes in this chapter or in the MIL Reference.

  • Matrox Solios-specific features
    • Summary of Matrox Solios features
    • Note on nomenclature
  • Using Matrox Solios with MIL
  • Allocating independent MIL digitizers on Matrox Solios
    • Matrox Solios XA
    • Matrox Solios XCL
  • Minimum latency and grabbing all frames
  • COM ports and UARTS
  • Matrox Solios utilities
    • Matrox Solios Bench
    • Usage Meter
  • User-defined signals for Matrox Solios
    • Camera Link
    • Analog
    • Controlling and inquiring about user-defined signals
    • Interruptible user-defined signals
  • Matrox Solios board flow diagrams
    • Matrox Solios XCL
    • Matrox Solios XA


Matrox Solios-specific features

See Also | Next
Reference:
MdigAlloc

The Matrox Solios family consists of three PCI-X compliant, single-slot, frame grabbers with powerful preprocessing capabilities: Matrox Solios XCL, Matrox Solios XA, and Matrox Solios XA single analog.

Matrox Solios XCL is a Camera Link frame grabber. It can be configured in one of two modes:

  • A dual-Base mode. Allows simultaneous acquisition from two independent Camera Link cameras using the Base configuration.
  • A single-Medium mode. Acquires from a single Camera Link camera using the Base or Medium configuration.

The mode of Matrox Solios can be changed using MILConfig (Solios tab) from its factory-default setting of single-Medium to dual-Base. Follow all on-screen procedures. Once changed, your computer must be shut-down and then turned back on (perform a cold-boot) for changes to take effect. Note that simply restarting your computer (using the Windows security Restart option) will not allow the changes to take affect.

If you change the mode of Matrox Solios, make certain you also change your DCF. Using the wrong DCF when performing a digitizer allocation (using MdigAlloc()) will result in an error.

Matrox Solios XA and Matrox Solios XA single analog are high-performance analog frame grabbers, capable of high frequency and high fidelity simultaneous acquisition. Matrox Solios XA can grab from up to four cameras, whereas Matrox Solios XA single analog can grab from one.

To reduce the number of the image formatting and preprocessing tasks performed by the Host CPU, both Matrox Solios XCL and XA include up to 64 Mbytes of processing memory for local processing and buffering. Matrox Solios can preprocess and format grabbed data in on-board buffers before transferring them to the Host if the board is purchased with the optional Processing Interface FPGA (PIF).

Summary of Matrox Solios features

The following table outlines the features currently available for each member of the Matrox Solios family.

Matrox Solios | XCL | XA | XA single analog
Memory | 64 Mbytes | 64 Mbytes | 64 Mbytes
Number of acquisition paths | 1 or 2 | 4 | 1¹
Number of supported triggers | 2/digitizer, 2 that can be shared by all digitizers. | 2/digitizer, 2 that can be shared by all digitizers. | 4
Asynchronous reset mode support for triggers | Yes | Yes | Yes
Exposure timers per digitizer | 2/digitizer | 2/digitizer | 2
Number of supported UARTS | 1/digitizer | 1/digitizer | 1
Number of user-defined signals | (4 out, 4 in, and 3 I/O) /digitizer, 6 that can be shared by all digitizers. | (3 out, 2 in) /digitizer, 8 that can be shared by all digitizers. | 3 out, 10 in.
Digitizer LUT | Yes | Yes | Yes

¹ Matrox Solios XA single analog has only 1 acquisition path. It uses the same user-defined signals as an M_DEV0 digitizer on Matrox Solios XA.

Note on nomenclature

This manual refers to all Matrox Solios boards as Matrox Solios. When necessary, it distinguishes between them by using their full name.


Using Matrox Solios with MIL

User Guide:
Multi-processing
Multi-threading

Reference:
MbufCopy
MsysAlloc
MthrControl

To use a Matrox Solios board, you must allocate it as a MIL Solios system (M_SYSTEM_SOLIOS), using MsysAlloc(). This allocation opens communication with the Matrox Solios board and allows MIL to use its resources. You can run multiple processes (executables) on the same board simultaneously. Each process can have one allocated system.

Refer to the MilSolios.txt file in the \Matrox Imaging\MIL\doc directory for any additions/modifications to these board specific notes.

SYSTEM SOLIOS


Allocating independent MIL digitizers on Matrox Solios

User Guide:
Basic concepts

Reference:
MdigAlloc
MdigChannel
MdigFree

Depending on the frame grabber, you can allocate several independent MIL digitizers. Independent digitizers have different device numbers and use different acquisition paths.

Matrox Solios XA

You can allocate up to 4 independent digitizers on Matrox Solios XA, depending on the cameras connected. The following table lists the acquisition paths and the digitizer number to use when connecting asynchronous cameras of different types.

Each acquisition path supports input from one of two sources, therefore all digitizers have 2 data channels. You can switch between them using MdigChannel().

Synchronization signals can either come combined with the data (CSYNC), from another acquisition path that is not already allocated (external analog synchronization), or from the DVI connector (external digital synchronization). Note that using an acquisition path to receive an external analog synchronization signal renders that acquisition path "occupied" and not available for allocating another digitizer on that acquisition path. For example, when allocating a 3-tap (RGB) digitizer on acquisition paths 0, 1, and 2 (using MdigAlloc(), with M_DEV0), you can set your synchronization signal on acquisition path 3 (using MdigChannel() with M_CH3 + M_SYNC). This results in acquisition path 3 not being available for allocation for another camera. Alternatively, if using an external digital synchronization signal on acquisition path 3 (by customizing the DCF using Matrox Intellicam), a digitizer for a monochrome camera could be allocated and use M_DEV3 simultaneously.

Matrox Solios XCL

The number of independent digitizers that you can allocate on Matrox Solios XCL is determined by the mode in use. There are two modes for the Matrox Solios XCL:

  • Single-Medium. One acquisition path is available (M_DEV0) with only one data channel (MdigChannel() with M_CH0).
  • Dual-Base. Two acquisition paths are available (M_DEV0 and M_DEV1), but each only has one data channel (MdigChannel() with M_CH0).
CH3 + M SYNC CH0 CH0


Minimum latency and grabbing all frames

Reference:
MdigGrab
MdigInquire
MdigProcess

When grabbing with either MdigGrab() or MdigProcess(), Matrox Solios is optimized to have the smallest latency possible between the last pixel sent from the camera to the last pixel written into the buffer. This allows the buffer to be available for processing with a minimum amount of delay.

By default, Matrox Solios grabs into off-board buffers. If the acquisition rate is higher than the transfer rate across the PCI/PCI-X bus, frames will be skipped rather than allowing a grab over-run to occur. For example, if your camera is 1024 by 1024 and grabs at 150 frames/sec, your acquisition rate is higher than the maximum transfer rate of the PCI bus (32-bit, 33 MHz), therefore frames will be skipped. When using a PCI-X bus, however, real-time grabs would still be feasible. To determine the image transfer speed to the Host, use the Matrox Solios Bench utility.

To be certain that no frames are missed when using MdigProcess(), use MdigInquire() with M_PROCESS_FRAME_MISSED. Use M_PROCESS_FRAME_COUNT to determine the total number of frames grabbed in the sequence. Use M_PROCESS_FRAME_RATE to return the estimate of the number of frames grabbed.

PROCESS FRAME MISSED PROCESS FRAME COUNT PROCESS FRAME RATE


COM ports and UARTS

Reference:
MsysControl

Matrox Solios offers RS-232 compatible serial interfaces (each controlled by a UART). Each interface is mapped as a COM port so that it can be accessed through the Microsoft Windows API.

Use the Microsoft Win32 library to access and control the serial ports. To view them in a Microsoft Windows operating system, refer to Microsoft Window's device manager, under Ports (COM & LPT). Alternately, MIL can control and access the serial ports (use MsysControl() with M_UART...). For more information, refer to the Matrox Solios Installation and Hardware Reference manual.

With Matrox Solios XCL, the Camera Link manufacturer's camera configuration application can access and control the serial ports as well as any Camera Link camera.


Matrox Solios utilities

Previous | Next

There are two Matrox Solios utilities available: Matrox Solios Bench and Usage Meter.

Matrox Solios Bench

The Matrox Solios Bench utility (SoliosBench.exe), located in your Matrox Imaging\MIL\Solios\Tools directory, calculates the real-time transfer speed of the PCI/PCI-X slot (in Mbytes/sec.) from:

  • Matrox Solios to Host.
  • Host to Matrox Solios.
  • Matrox Solios to display.

Usage Meter

The Usage Meter utility (UsageMeter.exe) calculates how much of the grab section and the transfer section is being used. This rate of utilization is expressed as a percentage.


User-defined signals for Matrox Solios

Reference:
MdigControl
MdigGetHookInfo
MdigHookFunction
MdigInquire

Matrox Solios supports user-defined signals for synchronizing with or controlling other devices, such as a strobe light.

MIL user-defined signal numbers map to different signals depending on the type of frame grabber (XCL or XA) and the device number specified for an allocated digitizer. Most of the user-defined signals are actually multi-purpose auxiliary signals and can only be used as user-defined signals if they are not defined/used for another purpose. See the Matrox Solios installation and hardware reference manual for more details.

Camera Link

The relationship between the MIL user-defined signal numbers and the actual user-defined signals for an M_DEV0 digitizer on Matrox Solios XCL are as follows:

MIL user-defined signal # | I/O | External Auxiliary I/O Connector 0 (HD-44) | External auxiliary I/O connector 1 (DB-9) | Camera Link video input connector 0 (MDR)
0 | O | P0_LVDS_AUX_OUT0 |  |
1 | O | P0_LVDS_AUX_OUT1 |  |
2 | I/O |  | P0_TTL_AUX_IO_0 |
3 | I/O | P0_TTL_AUX_IO_1 |  |
4 | I/O | TTL_AUX_IO_0¹ |  |
5 | I/O | TTL_AUX_IO_1¹ |  |
6 | I | LVDS_AUX_IN0¹ |  |
7 | I | LVDS_AUX_IN1¹ |  |
8 | I | OPTO_AUX_IN0¹ |  |
9 | I | OPTO_AUX_IN1¹ |  |
10 | I | P0_LVDS_AUX_IN0 |  |
11 | I | P0_LVDS_AUX_IN1 |  |
12 | I |  | P0_OPTO_AUX_IN0 |
13 | I |  | P0_OPTO_AUX_IN1 |
M_CC1 | O |  |  | CC1²
M_CC2 | O |  |  | CC2²
M_CC3 | O |  |  | CC3²
M_CC4 | O |  |  | CC4²

The relationship between the MIL user-defined signal numbers and the actual user-defined signals for an M_DEV1 digitizer on Matrox Solios XCL are as follows:

MIL user-defined signal # | I/O | External Auxiliary I/O Connector 0 (HD-44) | Camera Link video input connector 1 (MDR)
0 | O | P1_LVDS_AUX_OUT0 |
1 | O | P1_LVDS_AUX_OUT1 |
2 | I/O | P1_TTL_AUX_IO_0 |
3 | I/O | P1_TTL_AUX_IO_1 |
4 | I/O | TTL_AUX_IO_0¹ |
5 | I/O | TTL_AUX_IO_1¹ |
6 | I | LVDS_AUX_IN0¹ |
7 | I | LVDS_AUX_IN1¹ |
8 | I | OPTO_AUX_IN0¹ |
9 | I | OPTO_AUX_IN1¹ |
M_CC1 | O |  | CC1²
M_CC2 | O |  | CC2²
M_CC3 | O |  | CC3²
M_CC4 | O |  | CC4²

¹ Note that these are shared user-defined signals between digitizers. If used by one digitizer, they can be simultaneously used by all others that share this user-defined signal.

² Note that you can only output 2 different signals on the 4 signals available.

Analog

The relationship between the MIL user-defined signal numbers and the actual user-defined signals for an M_DEV0 digitizer on Matrox Solios XA are as follows:

MIL user-defined signal # | I/O | External Auxiliary I/O Connector 0 (HD-44) | External auxiliary I/O connector 1 (DB-9) | Analog Video Input Connector (DVI-0) | Analog Video Input Connector (DVI-1)
0 | O | P0_LVDS/TTL_AUX_OUT0 |  |  |
1 | O | P0_LVDS/TTL_AUX_OUT1 |  |  |
2 | O |  |  | P0_TTL_AUX(EXP)_OUT |
3 | I |  |  | P0_TTL_AUX(TRIG)_IN |
4 | I |  | P0_OPTO_AUX(TRIG)_IN |  |
5 | I | LVDS/TTL_AUX_IN0¹ |  |  |
6 | I | LVDS/TTL_AUX_IN1¹ |  |  |
7 | I | LVDS/TTL_AUX_IN2¹ |  |  |
8 | I | LVDS/TTL_AUX_IN3¹ |  |  |
9 | I | LVDS/TTL_AUX_IN4¹ |  |  |
10 | I | LVDS/TTL_AUX_IN5¹ |  |  |
11 | I | LVDS/TTL_AUX_IN6¹ |  |  |
12 | I | LVDS/TTL_AUX_IN7¹ |  |  |

Note that Matrox Solios XA single path uses the same MIL user-defined signal numbers as a M_DEV0 digitizer on Matrox Solios XA.

The relationship between the MIL user-defined signal numbers and the actual user-defined signals for an M_DEV1 digitizer on Matrox Solios XA are as follows:

MIL user-defined signal # | I/O | External Auxiliary I/O Connector 0 (HD-44) | External auxiliary I/O connector 1 (DB-9) | Analog Video Input Connector (DVI-0) | Analog Video Input Connector (DVI-1)
0 | O | P1_LVDS/TTL_AUX_OUT0 |  |  |
1 | O | P1_LVDS/TTL_AUX_OUT1 |  |  |
2 | O |  |  | P1_TTL_AUX(EXP)_OUT |
3 | I |  |  | P1_TTL_AUX(TRIG)_IN |
4 | I |  | P1_OPTO_AUX(TRIG)_IN |  |
5 | I | LVDS/TTL_AUX_IN0¹ |  |  |
6 | I | LVDS/TTL_AUX_IN1¹ |  |  |
7 | I | LVDS/TTL_AUX_IN2¹ |  |  |
8 | I | LVDS/TTL_AUX_IN3¹ |  |  |
9 | I | LVDS/TTL_AUX_IN4¹ |  |  |
10 | I | LVDS/TTL_AUX_IN5¹ |  |  |
11 | I | LVDS/TTL_AUX_IN6¹ |  |  |
12 | I | LVDS/TTL_AUX_IN7¹ |  |  |

The relationship between the MIL user-defined signal numbers and the actual user-defined signals for an M_DEV2 digitizer on Matrox Solios XA are as follows:

MIL user-defined signal # | I/O | External Auxiliary I/O Connector 0 (HD-44) | External auxiliary I/O connector 1 (DB-9) | Analog Video Input Connector (DVI-0) | Analog Video Input Connector (DVI-1)
0 | O | P2_LVDS/TTL_AUX_OUT0 |  |  |
1 | O | P2_LVDS/TTL_AUX_OUT1 |  |  |
2 | O |  |  | P2_TTL_AUX(EXP)_OUT |
3 | I |  |  | P2_TTL_AUX(TRIG)_IN |
4 | I |  | P2_OPTO_AUX(TRIG)_IN |  |
5 | I | LVDS/TTL_AUX_IN0¹ |  |  |
6 | I | LVDS/TTL_AUX_IN1¹ |  |  |
7 | I | LVDS/TTL_AUX_IN2¹ |  |  |
8 | I | LVDS/TTL_AUX_IN3¹ |  |  |
9 | I | LVDS/TTL_AUX_IN4¹ |  |  |
10 | I | LVDS/TTL_AUX_IN5¹ |  |  |
11 | I | LVDS/TTL_AUX_IN6¹ |  |  |
12 | I | LVDS/TTL_AUX_IN7¹ |  |  |

The relationship between the MIL user-defined signal numbers and the actual user-defined signals for an M_DEV3 digitizer on Matrox Solios XA are as follows:

MIL user-defined signal # | I/O | External Auxiliary I/O Connector 0 (HD-44) | External auxiliary I/O connector 1 (DB-9) | Analog Video Input Connector (DVI-0) | Analog Video Input Connector (DVI-1)
0 | O | P3_LVDS/TTL_AUX_OUT0 |  |  |
1 | O | P3_LVDS/TTL_AUX_OUT1 |  |  |
2 | O |  |  | P3_TTL_AUX(EXP)_OUT |
3 | I |  |  | P3_TTL_AUX(TRIG)_IN |
4 | I |  | P3_OPTO_AUX(TRIG)_IN |  |
5 | I | LVDS/TTL_AUX_IN0¹ |  |  |
6 | I | LVDS/TTL_AUX_IN1¹ |  |  |
7 | I | LVDS/TTL_AUX_IN2¹ |  |  |
8 | I | LVDS/TTL_AUX_IN3¹ |  |  |
9 | I | LVDS/TTL_AUX_IN4¹ |  |  |
10 | I | LVDS/TTL_AUX_IN5¹ |  |  |
11 | I | LVDS/TTL_AUX_IN6¹ |  |  |
12 | I | LVDS/TTL_AUX_IN7¹ |  |  |

¹ Note that these are shared user-defined signals between digitizers. If used by one digitizer, they can be simultaneously used by all others that share this user-defined signal.

Controlling and inquiring about user-defined signals

To control or inquire about user-defined signals on Matrox Solios, you need to use the M_USER_BIT_... control types or inquire types of MdigControl() and MdigInquire(), respectively.

To use user-defined I/O (bi-directional) signals, you must set their mode to either input or output, using the MdigControl() with M_USER_BIT_MODE.

You can set the state (on/off) of the user-defined output signals using MdigControl() with M_USER_BIT_VALUE. In addition, you can inquire about the state of the user-defined input and output signals using MdigInquire() with M_USER_BIT_VALUE.

You can control or inquire about either a specific user-defined signal or a group of user-defined signals. For an individual signal, add the MIL user-defined signal number to the control or inquire type. For a group of user-defined signals, add the M_BIT_MASK macro to the control or inquire type; the macro takes a bit-encoded mask value that identifies which user-defined signals to affect. For example on Matrox Solios XCL, adding M_BIT_MASK(45) affects user-defined signals 0, 2, 3, and 5 since the binary equivalent is equal to 101101. Note that when controlling a group of user-defined output signals, you must set the control value to a bit-encoded value that specifies the setting for each of the user-defined signals in the group. In addition, when inquiring about a group of user-defined signals, the return value is a bit-encoded value that specifies the current setting of each of the user-defined signals in the group.

Interruptible user-defined signals

To handle user-defined input signals, you can either poll their state or generate an event when they change state; all user-defined input signals can generate an event (interrupt). To generate an interrupt when there is a change in the state of a specified user-defined input signal:

  1. If bi-directional (I/O), set the user-defined signal to input mode as described above.
  2. Enable the interrupt state for the user-defined input signal, using MdigControl() with M_USER_BIT_INTERRUPT_STATE. The user-defined signal will generate an interrupt upon a rising edge.
  3. Hook a function to the user-defined signal's change of functional state, using MdigHookFunction() with M_USER_BIT_CHANGE.
  4. Within the scope of the hook function itself, inquire which user-defined signal(s) generated the interrupt, using MdigGetHookInfo() with M_USER_BIT. Then, execute according to the result of the inquiry.
USER BIT MODE USER BIT VALUE USER BIT VALUE BIT MASK USER BIT INTERRUPT STATE USER BIT CHANGE USER BIT


Matrox Solios board flow diagrams

Previous

This section contains data flow diagrams for Matrox Solios boards.

Matrox Solios XCL

The following diagram illustrates the data flow of Matrox Solios XCL.

Matrox Solios XA

The following diagram illustrates the data flow of Matrox Solios XA.

The following diagram illustrates the data flow of Matrox Solios XA single analog.


Matrox 4Sight

Chapter 11: Matrox 4Sight

This chapter discusses features of MIL that are particular to the Matrox 4Sight family of units, and ways that optimize their performance.

  • Specific features of Matrox 4Sight units
    • Matrox 4Sight-II
      • Display capabilities
      • NTSC/PAL/RGB video output
      • Frame grabbers
      • IEEE 1394 interface
      • Auxiliary I/O interface
    • Matrox 4Sight-M
      • Display capabilities
      • Frame grabbers
      • Serial ports interface
      • Auxiliary I/O interface
  • Using MIL with Matrox 4Sight
  • User-defined signals for Matrox 4Sight
    • Matrox 4Sight-II user-defined signals
    • Matrox 4Sight-M user-defined signals
    • Controlling and inquiring about user-defined signals
    • Interruptible user-defined signals
  • Matrox 4Sight board flow diagrams
    • Matrox 4Sight-II
    • Matrox 4Sight-M


Specific features of Matrox 4Sight units

See Also | Next
User Guide:
Types of displays

The Matrox 4Sight family consists of two types of MIL-supported, self-contained units that integrate image capture, storage, processing and display, along with general purpose input/output (I/O) and standard 10/100BaseT Ethernet interfacing capabilities. The Matrox 4Sight family also supports add-on boards compliant with the PC-104/Plus form factor.

This chapter outlines basic features of the Matrox 4Sight family (specifically Matrox 4Sight-II and Matrox 4Sight-M), and relates them to specific functions in MIL. However, for more detailed information on the capabilities of each member of the Matrox 4Sight family, refer to their respective user guides.

Matrox 4Sight-II

In addition to the features listed above, Matrox 4Sight-II has IEEE 1394 tree topology capabilities. Matrox 4Sight-II supports the Microsoft Windows CE, 2000, and XP operating systems.

Display capabilities

Matrox 4Sight-II integrates the Matrox G450 graphics controller for all display operations. It features a 2X, 32-bit, master AGP Host interface, a primary and secondary RAMDAC, a TV/video encoder, a transmission-minimized differential signaling (TMDS) transmitter (for output to a digital flat-panel), and 16 Mbytes of SDRAM. The controller allows for independent display on one or two display devices, which include a high-resolution monitor, an analog flat-panel, a digital flat-panel, or an NTSC/PAL/RGB device, such as a TV or VCR.

On Matrox 4Sight-II units, the graphics controller supports non-destructive graphic annotations.

NTSC/PAL/RGB video output

The video encoder in the graphics controller of Matrox 4Sight-II allows for either composite, component Y/C, or component RGB output to a TV or VCR. On Matrox 4Sight-II, such capabilities are controlled directly by MIL. For information on displaying images on an NTSC/PAL/RGB device, refer to the Types of displays section in Chapter 16: Displaying an image.

Frame grabbers

Matrox 4Sight-II supports the PC/104-Plus form factor of the Matrox Meteor-II /Standard, Matrox Meteor-II / Multi-Channel, and Matrox Meteor-II /Digital frame grabbers, and the Matrox Orion /Standard for 4Sight-II and Matrox Orion /RGB for 4Sight-II frame grabbers.

IEEE 1394 interface

The IEEE 1394 interface is a very fast external bus, which supports isochronous (real-time) digital data transfer between IEEE 1394 devices (such as, IEEE 1394 DCAM-compliant cameras) and Matrox 4Sight-II, at rates of up to 400 Mbits/sec.

Despite being an integrated component on the motherboard, the IEEE 1394 serial bus controller provides identical functionality as the Matrox Meteor-II /1394 frame grabber. For information on the particularities of MIL functions with Matrox Meteor-II /1394, refer to the IEEE 1394 serial bus-specific features section in Chapter 6: Matrox Meteor-II and the Grabbing from multiple 1394 DCS-compliant cameras section in Chapter 6: Matrox Meteor-II.

Windows 2000 and Windows XP support the IEEE 1394 interface, however you must install the MIL Matrox Meteor-II /1394 driver to use IEEE 1394 DCAM-compliant cameras through MIL. Once installed, you can still interface any IEEE 1394 device to the IEEE 1394 interface. However, you will only be able to use your IEEE 1394 DCAM-compliant cameras through MIL.

Auxiliary I/O interface

The auxiliary I/O interface is a discrete, digital interface, used for operating external devices, such as a PLC or motion control unit.

Matrox 4Sight-II can send and receive up to sixteen LVTTL signals.

All user-defined input signals have interrupt-generation capabilities. On Matrox 4Sight-II, you can assign IRQ 10 to transmit the interrupt. The IRQ is assigned by entering the BIOS Setup program, and configuring the appropriate menu item.

Your application can also poll any of the user-defined signals to determine their state, if you do not want to assign an IRQ.

For details on the auxiliary I/O interface, refer to the Matrox 4Sight-II Installation and Hardware reference manual. For more information on programming and using the user-defined signals in your applications, refer to the User-defined signals for Matrox 4Sight section later in this chapter.

Matrox 4Sight-M

Matrox 4Sight-M supports both the Microsoft Windows XP and CE operating systems.

Display capabilities

Matrox 4Sight-M uses an integrated Intel 855GME GMCH that features a 360 MHz primary display RAMDAC, a DVO port, and a connection to an integrated Chrontel 7009 video encoder (with external display interfaces). The Intel 855GME GMCH uses up to 64 Mbytes of computer memory to store display data. The GMCH can output to two display devices simultaneously. The first video output controller enables the display device connected to analog VGA connector #1. The second video output controller enables the second display device connected to the DVI connector. Matrox 4Sight-M supports inputs of composite (CVBS) and component (Y/C) video in NTSC or PAL format. It can also output component RGB video with resolutions simialr to video in NTSC/PAL formats. This feature allows you to extend your Windows desktop so that it spans across a second screen. MIL can use the second video output controller to output an auxiliary display to a second device. For more details on connecting devices to the video output controllers of your Matrox 4Sight-M, refer to the Matrox 4Sight-II Installation and Hardware reference manual.

Frame grabbers

Matrox 4Sight-M supports the PC/104-plus format of the Matrox Meteor-II /Standard, Matrox Meteor-II / Multi-Channel, and Matrox Meteor-II /Digital frame grabbers.

Serial ports interface

Matrox 4Sight-M integrates two serial ports, the driver and the receiver of which are always enabled. Each interface is controlled by a Universal Asynchronous Receiver-Transmitter (UART) device. The Matrox 4Sight-M motherboard integrates 16550/16450-compatible UARTs, which feature independently programmable baud rates (maximum baud rate = 115 200 bps) and internal 16-byte FIFO memory buffers.

Auxiliary I/O interface

Matrox 4Sight-M can send up to 16 user-defined output signals and receive up to 16 user-defined input signals (up to 24 V) through the auxiliary TTL I/O interface. All 16 user-defined input signals have interrupt-generation capabilities. The IRQ is assigned by entering the BIOS Setup program, and configuring the appropriate menu item.

Your application can also poll any of the user-defined I/O signals to determine their state, if you do not want to assign an IRQ.

For details on the auxiliary I/O interface, refer to the Matrox 4Sight-M Installation and Hardware Reference manual. For more information on programming and using the user-defined signals in your applications, refer to User defined signals for Matrox 4Sight.


Using MIL with Matrox 4Sight

Reference:
MsysAlloc

MIL treats Matrox 4Sight-II and Matrox 4Sight-M as normal computers. Accordingly, you do not allocate Matrox 4Sight-II or Matrox 4Sight-M as a system. However, to use a Matrox Orion module for 4Sight-II, or a Matrox Meteor-II frame grabber, you must first allocate the board as a MIL Orion or Meteor-II system.

To use IEEE 1394 DCAM-compliant cameras, you must allocate MIL Meteor-II /1394 systems. Then, assign a camera from the pool of IEEE 1394 DCAM-compliant cameras, to a particular system, by allocating it as a digitizer on that system. For details on allocating a Meteor-II /1394 system, allocating a Meteor-II /1394 digitizer, and managing multiple IEEE 1394 DCAM-compliant cameras, refer to Chapter 6: Matrox Meteor-II.

To use the capabilities of the auxiliary I/O interface (user-defined signals) on Matrox 4Sight units, you need to allocate a default host system using MsysAlloc() with SystemDescriptor set to M_SYSTEM_HOST.

Note that when installing a redistribution (run-time) version of MIL on Matrox 4Sight-II or Matrox 4Sight-M, the license number will be based on a hardware fingerprint on your unit. This means that you will not be able to copy the licensed version of MIL to another computer.

SYSTEM HOST


User-defined signals for Matrox 4Sight

Reference:
MsysAlloc
MsysControl
MsysGetHookInfo
MsysHookFunction
MsysInquire

Matrox 4Sight-II and Matrox 4Sight-M both support user-defined signals for synchronizing with or controlling other devices such as a strobe light.

Matrox 4Sight-II user-defined signals

The relationship between the MIL user-defined signal numbers and the actual user-defined signals on the auxiliary I/O connector and the opto-coupling module are as follows:

MIL user-defined signal # | I/O | Auxiliary I/O connector | Opto-coupling module signal
0 | I/O | LVTTL I/O 0 | Bit 0
1 | I/O | LVTTL I/O 1 | Bit 1
2 | I/O | LVTTL I/O 2 | Bit 2
3 | I/O | LVTTL I/O 3 | Bit 3
4 | I/O | LVTTL I/O 4 | Bit 4
5 | I/O | LVTTL I/O 5 | Bit 5
6 | I/O | LVTTL I/O 6 | Bit 6
7 | I/O | LVTTL I/O 7 | Bit 7
8 | I/O | LVTTL I/O 8 | Bit 8
9 | I/O | LVTTL I/O 9 | Bit 9
10 | I/O | LVTTL I/O 10 | Bit 10
11 | I/O | LVTTL I/O 11 | Bit 11
12 | I/O | LVTTL I/O 12 | Bit 12
13 | I/O | LVTTL I/O 13 | Bit 13
14 | I/O | LVTTL I/O 14 | Bit 14
15 | I/O | LVTTL I/O 15 | Bit 15

Matrox 4Sight-M user-defined signals

The relationship between the MIL user-defined signal numbers and the actual user-defined signals on the auxiliary I/O connector is as follows:

MIL user-defined signal # | I/O | Auxiliary I/O connector
0 | I | INPUT 0
1 | I | INPUT 1
2 | I | INPUT 2
3 | I | INPUT 3
4 | I | INPUT 4
5 | I | INPUT 5
6 | I | INPUT 6
7 | I | INPUT 7
8 | I | INPUT 8
9 | I | INPUT 9
10 | I | INPUT 10
11 | I | INPUT 11
12 | I | INPUT 12
13 | I | INPUT 13
14 | I | INPUT 14
15 | I | INPUT 15
0 | O | OUTPUT 0
1 | O | OUTPUT 1
2 | O | OUTPUT 2
3 | O | OUTPUT 3
4 | O | OUTPUT 4
5 | O | OUTPUT 5
6 | O | OUTPUT 6
7 | O | OUTPUT 7
8 | O | OUTPUT 8
9 | O | OUTPUT 9
10 | O | OUTPUT 10
11 | O | OUTPUT 11
12 | O | OUTPUT 12
13 | O | OUTPUT 13
14 | O | OUTPUT 14
15 | O | OUTPUT 15

Note that the user-defined signal numbers restart for the output signals.

Controlling and inquiring about user-defined signals

To control or inquire about user-defined signals on Matrox 4Sight-II and Matrox 4Sight-M, you need to use the M_USER_BIT_... control types or inquire types of MsysControl() and MsysInquire(), respectively. The system must be allocated as a Host system, using MsysAlloc() with M_SYSTEM_HOST.

To use user-defined I/O (bi-directional) signals, you must set their mode to either input or output, using MsysControl() with M_USER_BIT_MODE.

You can set the state (on/off) of the user-defined output signals using MsysControl() with M_USER_BIT_VALUE_OUT. In addition, you can inquire about the state of the user-defined input and output signals using MsysInquire() with M_USER_BIT_VALUE_IN and M_USER_BIT_VALUE_OUT, respectively.

You can control or inquire about either a specific user-defined signal or a group of user-defined signals. For an individual signal, add the MIL user-defined signal number to the control or inquire type. For a group of user-defined signals, add the M_BIT_MASK macro to the control or inquire type; the macro takes a bit-encoded mask value that identifies which user-defined signals to affect. For example on Matrox 4Sight-II, adding M_BIT_MASK(45) affects user-defined signals 0, 2, 3, and 5 since the binary equivalent is equal to 101101. Note that when controlling a group of user-defined output signals, you must set the control value to a bit-encoded value that specifies the setting for each of the user-defined signals in the group. In addition, when inquiring about a group of user-defined signals, the return value is a bit-encoded value that specifies the current setting of each of the user-defined signals in the group.

The following snippet of code shows how to set the mode and functional state of a single user-defined signal, as well as how to set the mode and functional state of two user-defined signals using a bit-encoded mask on Matrox 4Sight-II.

/* Set bit 1 to output mode */
MsysControl(M_DEFAULT_HOST,M_USER_BIT_MODE+1, M_OUTPUT);
/* Set the functional state of bit 1 to on.*/
MsysControl(M_DEFAULT_HOST,M_USER_BIT_VALUE_OUT+1, M_ON);
/* Set bits 2 and 3 to output mode. */
MsysControl(M_DEFAULT_HOST,M_USER_BIT_MODE+M_BIT_MASK(0xC), 0xC);
/* Set bit 2 to on, but bit 3 to off. */
MsysControl(M_DEFAULT_HOST,M_USER_BIT_VALUE_OUT+M_BIT_MASK(0xC), 0x4);

Interruptible user-defined signals

To handle user-defined input signals, you can either poll their state or generate an event when they change state; all user-defined signals can generate an event (interrupt). To generate an interrupt when there is a change in the state of a specified user-defined input signal:

  1. In the BIOS, assign an interrupt line to the entire group of user-defined signals. Refer to the appropriate Hardware and Installation Reference manual for more information on assigning an interrupt line to the user-defined I/O signals.
  2. If bi-directional (I/O), set the user-defined signal to input mode as described above.
  3. Specify whether the user-defined input signal should generate an interrupt upon a rising edge or falling edge, using MsysControl() with M_USER_BIT_INTERRUPT_MODE set to either M_EDGE_RISING or M_EDGE_FALLING.
  4. Enable the interrupt state for the user-defined input signal, using MsysControl() with M_USER_BIT_INTERRUPT_STATE.
  5. Hook a function to the user-defined signal's change of functional state, using MsysHookFunction() with M_USER_BIT_CHANGE.
  6. Within the scope of the hook function itself, inquire which user-defined signal(s) generated the interrupt, using MsysGetHookInfo() with M_USER_BIT. Then, execute according to the result of the inquiry.

The following snippet of code demonstrates how to hook a function and its related hook data to a particular change of state of a user-defined signal (rising edge, in this case). When the interrupt mode is set to rising edge, a user-defined signal's change of state from 0 (OFF) to 1 (ON) is required to generate the interrupt. When no longer required, the specified function is then unhooked from this event.

/* Set user bit 1 to input mode. */
MsysControl(M_DEFAULT_HOST,M_USER_BIT_MODE+1, M_INPUT);
/* Set the interrupt mode to be generated on a rising edge for bit 1. */
MsysControl(M_DEFAULT_HOST,M_USER_BIT_INTERRUPT_MODE+1, M_EDGE_RISING);

/* Enable the interrupt state of bit 1. */
MsysControl(M_DEFAULT_HOST,M_USER_BIT_INTERRUPT_STATE+1, M_ENABLE);
/* Hook your function (YourHookFunction) and any related hook data (YourHookData)
* to a change of functional state of the user bit.
*/
MsysHookFunction(M_DEFAULT_HOST,M_USER_BIT_CHANGE,YourHookFunction,
(void*)&YourHookData);
/* Perform processing operations...*/
/* Unhook the function */
MsysHookFunction(M_DEFAULT_HOST,M_USER_BIT_CHANGE+M_UNHOOK,YourHookFunction,
(void*)&YourHookData);
SYSTEM HOST USER BIT MODE USER BIT VALUE OUT USER BIT VALUE IN USER BIT VALUE OUT BIT MASK USER BIT INTERRUPT MODE EDGE RISING EDGE FALLING USER BIT INTERRUPT STATE USER BIT CHANGE USER BIT


Matrox 4Sight board flow diagrams

Previous

This section contains data flow diagrams for Matrox 4Sight-II and Matrox 4Sight-M units.

Matrox 4Sight-II

The following diagram illustrates the data flow of a Matrox 4Sight-II unit.

Matrox 4Sight-M

The following diagram illustrates the data flow of a Matrox 4Sight-M unit.


Example: mdigmultdestination.c

/* File name:  MdigMultDestination.c
 * Synopsis:   This example shows how to maintain a color continuous
 *             grab in the display and at the same time grab in
 *             a monochrome Host buffer for processing.
 *             For further information, refer to the MdigAlloc()
 *             section of the Matrox Orion Board-Specific manual.
 *
 *       Note: This example is only supported on the Matrox Orion,
 *             and the Matrox Orion for 4Sight-II.
 *             Your display depth must be in 32bpp.
*/

/* Processing operation to perform. */
#define REVERSE_IMAGE     0
#define EDGE_DETECT_IMAGE 0
#define COPY_IMAGE        1

/* Image scale. */
#define IMAGE_SCALE  0.5

#include <stdlib.h>
#include <stdio.h>
#include <conio.h>
#include "mil.h"

void main(void)
   {
   MIL_ID  MilApplication;
   MIL_ID  MilSystem;
   MIL_ID  MilDisplay;
   MIL_ID  MilDisplayContinuous;
   MIL_ID  MilDigitizer;
   MIL_ID  MilDigitizerContinuous;
   MIL_ID  MilImage[2];
   MIL_ID  MilImageDisp;
   MIL_ID  MilImageDispContinuous;
   long i=0, n=0, t=0;
   double Time = 0.0;

   /* System allocation. */
   MappAlloc(M_DEFAULT, &MilApplication);
   MsysAlloc(M_SYSTEM_ORION, M_DEF_SYSTEM_NUM, M_SETUP, &MilSystem);

   /* Allocate 2 displays, one for each digitizer. */
   MdispAlloc(MilSystem, M_DEFAULT, M_DEF_DISPLAY_FORMAT, M_DEFAULT, &MilDisplayContinuous);
   MdispAlloc(MilSystem, M_DEFAULT, M_DEF_DISPLAY_FORMAT, M_DEFAULT, &MilDisplay);
   MdispControl(MilDisplayContinuous, M_TITLE, M_PTR_TO_DOUBLE("Continuous grab on display."));
   MdispControl(MilDisplay, M_TITLE, M_PTR_TO_DOUBLE("Grab monoshot on Host and update to display."));

   /* Allocate 2 digitizers, one for the continuous grab to the display and
      one for monochrome monoshots on the Host. */
   MdigAlloc(MilSystem, M_DEV0, M_DEF_DIGITIZER_FORMAT, M_DEFAULT, &MilDigitizerContinuous);
   MdigAlloc(MilSystem, M_DEV0, M_DEF_DIGITIZER_FORMAT, M_DEFAULT, &MilDigitizer);
   MdigControl(MilDigitizer, M_GRAB_SCALE, IMAGE_SCALE);
   MdigControl(MilDigitizer, M_GRAB_MODE, M_ASYNCHRONOUS);

   /* Monoshot grab buffers. */
   MbufAllocColor(MilSystem,  1,
                  (long)(MdigInquire(MilDigitizer, M_SIZE_X, M_NULL)*IMAGE_SCALE),
                  (long)(MdigInquire(MilDigitizer, M_SIZE_Y, M_NULL)*IMAGE_SCALE),
                     8L+M_UNSIGNED,
                     M_IMAGE+M_GRAB+M_PROC, &MilImage[0]);
   MbufAllocColor(MilSystem,  1,
                  (long)(MdigInquire(MilDigitizer, M_SIZE_X, M_NULL)*IMAGE_SCALE),
                  (long)(MdigInquire(MilDigitizer, M_SIZE_Y, M_NULL)*IMAGE_SCALE),
                     8L+M_UNSIGNED,
                     M_IMAGE+M_GRAB+M_PROC, &MilImage[1]);
   MbufClear(MilImage[0],M_BLACK);
   MbufClear(MilImage[1],M_BLACK);

   /* Monochrome display buffer. */
   /* Note that the display update speed can be increased and CPU usage decreased
      if the display buffer is allocated in the VGA memory. Simply add
      M_DDRAW+M_ON_BOARD to the display buffer attributes. */
   MbufAllocColor(MilSystem,
                  1,
                  (long)(MdigInquire(MilDigitizer, M_SIZE_X, M_NULL)*IMAGE_SCALE),
                  (long)(MdigInquire(MilDigitizer, M_SIZE_Y, M_NULL)*IMAGE_SCALE),
                  8L+M_UNSIGNED,
                  M_IMAGE+M_PROC+M_DISP+M_GRAB, &MilImageDisp);
   MbufClear(MilImageDisp,M_BLACK);

   /* Continuous grab display buffer. */
   MbufAllocColor(MilSystem,
                  (long)(MdigInquire(MilDigitizerContinuous, M_SIZE_BAND, M_NULL)),
                  (long)(MdigInquire(MilDigitizerContinuous, M_SIZE_X, M_NULL)),
                  (long)(MdigInquire(MilDigitizerContinuous, M_SIZE_Y, M_NULL)),
                  8L+M_UNSIGNED,
                  M_IMAGE+M_PROC+M_DISP+M_GRAB, &MilImageDispContinuous);
   MbufClear(MilImageDispContinuous, M_BLACK);

   MdispSelect(MilDisplay, MilImageDisp);
   MdispSelect(MilDisplayContinuous, MilImageDispContinuous);

   /* Start continuous grab on the display. */
   MdigGrabContinuous(MilDigitizerContinuous, MilImageDispContinuous);

   printf("Continuous grab in progress.\n");
   printf("Press <enter> to start monoshot grabs\n");
   printf("on Host and update to display.\n");
   getchar();

   /* Reset the timer to compute the number of actual frames
      grabbed per second by monoshot digitizer. */
   MappTimer(M_TIMER_RESET, &Time);

   /* While the continuous grab is running in the display we do
      monoshot grabs with the other digitizer and copy them on
      the second display. This is done using double-buffering
      techniques. Please refer to mdbproc.c example for further
      details about double-buffering. */
   while(!kbhit())
      {
      /* Grab a frame. */
      MdigGrab(MilDigitizer, MilImage[i]);

      /* Toggle between the 2 grab buffers. */
      i = 1-i;
      n++;t++;

      /* Print frame rate. */
      if (n==30)
         {
         MappTimer(M_TIMER_READ, &Time);
         printf("\rGrabbing and processing on Host at %2.3f frames/sec.  Total frames: %d   ",n/Time,t);
         n=0;
         MappTimer(M_TIMER_RESET, &Time);
         }

      /* Process the first buffer already grabbed.
         Note: Real time only if PC is fast enough. */
      #if REVERSE_IMAGE
      MimArith(MilImage[i], M_NULL, MilImageDisp, M_NOT);
      #endif
      #if EDGE_DETECT_IMAGE
      MimConvolve(MilImage[i], MilImageDisp, M_EDGE_DETECT);
      #endif
      #if COPY_IMAGE
      MbufCopy(MilImage[i], MilImageDisp);
      #endif
      }

   /* Wait for the last queued monoshot to finish. */
   MdigGrabWait(MilDigitizer, M_GRAB_END);
   /* Stop the continuous grab. */
   MdigHalt(MilDigitizerContinuous);

   /* Free allocations. */
   MbufFree (MilImage[0]);
   MbufFree (MilImage[1]);
   MbufFree (MilImageDisp);
   MbufFree (MilImageDispContinuous);
   MdigFree (MilDigitizer);
   MdigFree (MilDigitizerContinuous);
   MdispFree(MilDisplay);
   MdispFree(MilDisplayContinuous);
   MsysFree (MilSystem);
   MappFree (MilApplication);
   }


Example: met2_1394serialbus.c

/************************************************************************************/
/*
 * File name: Met2_1394SerialBus.c
 *
 * Synopsis:  This program is an example of the Meteor-II bus-specific features
 */
#include "mil.h"
#include "stdio.h"
#include "string.h"
void main(void)
{
MIL_ID MilApplication, /* Application identifier. */
MilSystem,             /* System identifier. */
MilDigitizer;          /* Digitizer identifier. */
long NbFormats;
long MaxLength;
char * Strings;
long Offset;
long t;

/* Allocate defaults. */
MappAlloc(M_DEFAULT, &MilApplication);
MsysAlloc(M_SYSTEM_METEOR_II_1394, M_DEFAULT, M_SETUP, &MilSystem);
MdigAlloc(MilSystem, M_DEFAULT, "M_DEFAULT", M_DEFAULT, &MilDigitizer);

/* Inquire number of strings and length */
NbFormats = MdigInquire(MilDigitizer, M_FORMAT_SUPPORTED_NUM,
M_NULL);
MaxLength = MdigInquire(MilDigitizer, M_FORMAT_SUPPORTED_LENGTH,
M_NULL);

/* Allocate a buffer to receive the strings */
Strings = malloc(NbFormats*MaxLength*sizeof(MILTCHAR));
memset(Strings, 0, NbFormats*MaxLength*sizeof(char));

/* Inquire the strings */
MdigInquire(MilDigitizer, M_FORMAT_SUPPORTED, Strings);

Offset = 0;
for(t = 0; t < NbFormats; t++)
{
/* Print each string */
printf("%s\n", &Strings[Offset]);
Offset += MaxLength;
}
free(Strings);

printf("Press <Enter> to end.\n");
getchar();

/* Free MIL objects */
MdigFree(MilDigitizer);
MsysFree(MilSystem);
MappFree(MilApplication);


Example: mgenlc.c

/* File name: mgenlc.c
 * Synopsis:  This program allocates 2 grab buffers on the
 *            unused bands of the Genesis LC display and
 *            grabs in them.
 *            This technique can be used when experiencing
 *            grab over-runs on heavy loaded systems.
 *
 *            When the display is in monochrome mode, it
 *            uses only the blue surface and reserves the
 *            red and green surfaces.  This example shows
 *            how to access this unused memory for grabbing
 *            purposes.
 *            Note: This example will only work with a
 *            monochrome camera.
*/

/* Headers. */
#include <stdio.h>
#include <stdlib.h>
#include <conio.h>
#include <mil.h>

/* Main function. */
void main(void)
{
  MIL_ID   MilApplication;
  MIL_ID   MilSystem     ;
  MIL_ID   MilDigitizer  ;
  MIL_ID   MilDisplay    ;
  MIL_ID   MilImageOnBoard[2];
  MIL_ID   MilImageDisp;
  void     *UnderlayPhysicalAddress = NULL;

  /* Allocations. */
  MappAlloc(M_DEFAULT, &MilApplication);
  MsysAlloc(M_SYSTEM_GENESIS, M_DEF_SYSTEM_NUM, M_SETUP, &MilSystem);
  MdigAlloc(MilSystem, M_DEFAULT, M_DEF_DIGITIZER_FORMAT,
                                  M_DEFAULT, &MilDigitizer);
  MdispAlloc(MilSystem, M_DEFAULT, M_DEF_DISPLAY_FORMAT, M_DEFAULT, &MilDisplay);

  /* Force the display in monochrome mode on the blue plane. */
  MdispControl(MilDisplay, M_COLOR_MODE, M_BLUE);

  /* Allocate a display buffer. */
  MbufAlloc2d(MilSystem,
              (long)(MdigInquire(MilDigitizer, M_SIZE_X, M_NULL)),
              (long)(MdigInquire(MilDigitizer, M_SIZE_Y, M_NULL)),
              8L+M_UNSIGNED,
              M_IMAGE+M_PROC+M_DISP+M_NON_PAGED, &MilImageDisp);
  MbufClear(MilImageDisp, 0);

  /* Inquire the base address of the underlay surface. */
  MsysInquire(MilSystem, M_PHYSICAL_ADDRESS_UNDERLAY, &UnderlayPhysicalAddress);

  /* Create a buffer on the red surface (base address). */
  MbufCreateColor(MilSystem,
                  1,
                  (long)(MdigInquire(MilDigitizer, M_SIZE_X, M_NULL)),
                  (long)(MdigInquire(MilDigitizer, M_SIZE_Y, M_NULL)),
                  8L+M_UNSIGNED,
                  M_IMAGE+M_GRAB+M_PROC+M_ON_BOARD,
                  M_PHYSICAL_ADDRESS+M_PITCH_BYTE,
                  M_DEFAULT,
                  (void *)&(UnderlayPhysicalAddress),
                  &MilImageOnBoard[0]);

  /* Move to the green plane (base address+2MEG). */
  UnderlayPhysicalAddress = ((unsigned long) UnderlayPhysicalAddress) + 0x200000;

  MbufCreateColor(MilSystem,
                  1,
                  (long)(MdigInquire(MilDigitizer, M_SIZE_X, M_NULL)),
                  (long)(MdigInquire(MilDigitizer, M_SIZE_Y, M_NULL)),
                  8L+M_UNSIGNED,
                  M_IMAGE+M_GRAB+M_PROC+M_ON_BOARD,
                  M_PHYSICAL_ADDRESS+M_PITCH_BYTE,
                  M_DEFAULT,
                  (void *)&(UnderlayPhysicalAddress),
                  &MilImageOnBoard[1]);

  /* Enable bus master copies from the Genesis to the Host. */
  MsysControl(MilSystem, M_BUS_MASTER_COPY_TO_HOST, M_ENABLE);

  /* Display the buffer. */
  MdispSelect(MilDisplay, MilImageDisp);

  printf("Press enter to grab into the first buffer\n");
  getchar();

  /* Grab and copy to the Host. */
  MdigGrab(MilDigitizer, MilImageOnBoard[0]);
  MbufCopy(MilImageOnBoard[0], MilImageDisp);

  printf("Press enter to grab into the second buffer\n");
  getchar();

  /* Grab and copy to the Host. */
  MdigGrab(MilDigitizer, MilImageOnBoard[1]);
  MbufCopy(MilImageOnBoard[1], MilImageDisp);

  getchar();

  /* Free allocations. */
  MbufFree(MilImageOnBoard[0]);
  MbufFree(MilImageOnBoard[1]);
  MbufFree(MilImageDisp);
  MdispFree(MilDisplay);
  MdigFree(MilDigitizer);
  MsysFree(MilSystem);
  MappFree(MilApplication);
}


Example: mheliosconcurent.c

/************************************************************************************/
/*
 * File name: HelOutOfOrder.c
 *
 * Synopsis: This program shows how to optimize efficiently in the same
 *           thread by using Matrox Helios to best effect.
 */

#include <stdio.h>
#include <mil.h>

#define IMAGE_SIZE  2048

void main(void)
   {
   MIL_ID MilApplication = 0;  /* Application identifier.  */
   MIL_ID MilSystem      = 0;  /* System identifier.       */
   MIL_ID MilDisplay     = 0;  /* Display identifier.      */
   MIL_ID MilDigitizer   = 0;  /* Digitizer identifier.    */

   MIL_ID MilImageOnBoardA  = 0;
   MIL_ID MilImageOnBoardB  = 0;
   MIL_ID MilImageOnBoardC  = 0;
   MIL_ID MilImageOffBoardD = 0;

   /* Allocate defaults. */
   MappAllocDefault(M_SETUP, &MilApplication, &MilSystem, &MilDisplay, &MilDigitizer, M_NULL);

   /* Allocate buffers in the on-board memory of the Matrox Helios. */
   MbufAlloc2d(MilSystem, IMAGE_SIZE, IMAGE_SIZE, 8 + M_UNSIGNED, M_IMAGE +
    M_ON_BOARD + M_PROC + M_GRAB, &MilImageOnBoardA);
   MbufAlloc2d(MilSystem, IMAGE_SIZE, IMAGE_SIZE, 8 + M_UNSIGNED, M_IMAGE +
    M_ON_BOARD + M_PROC + M_GRAB, &MilImageOnBoardB);
   MbufAlloc2d(MilSystem, IMAGE_SIZE, IMAGE_SIZE, 8 + M_UNSIGNED, M_IMAGE +
    M_ON_BOARD + M_PROC + M_GRAB, &MilImageOnBoardC);

   /* Allocate a bufffer in the Host memory, off board. */
   MbufAlloc2d(MilSystem, IMAGE_SIZE, IMAGE_SIZE, 8 + M_UNSIGNED, M_IMAGE +
    M_OFF_BOARD + M_PROC + M_GRAB + M_NON_PAGED + M_DISP, &MilImageOffBoardD);

   /* Clear Buffer */
   MbufClear(MilImageOnBoardA, 0);
   MbufClear(MilImageOnBoardB, 0);
   MbufClear(MilImageOnBoardC, 0);
   MbufClear(MilImageOffBoardD, 0);

   /* Select image to display */
   MdispSelect(MilDisplay, MilImageOffBoardD);

   /* Put digitizer in asynchronous mode. */
   MdigControl(MilDigitizer, M_GRAB_MODE, M_ASYNCHRONOUS_QUEUED);

   printf("Press <Enter> to start.\n");
   getchar();

   /* Start of out of order execution */
   MdigGrab(MilDigitizer, MilImageOnBoardA);

   /* The 3 next operations will be executed in parallel */
   MdigGrab(MilDigitizer, MilImageOnBoardB);
   MimConvolve(MilImageOnBoardA, MilImageOnBoardC, M_EDGE_DETECT+M_OVERSCAN_DISABLE);
   MbufCopy(MilImageOnBoardA, MilImageOffBoardD);

   printf("Press <Enter> to end.\n");
   getchar();

   MbufFree(MilImageOnBoardA);
   MbufFree(MilImageOnBoardB);
   MbufFree(MilImageOnBoardC);
   MbufFree(MilImageOffBoardD);

   /* Free defaults. */
   MappFreeDefault(MilApplication, MilSystem, MilDisplay, MilDigitizer, M_NULL);


Example: mmet2dig.c

/* File name: mmet2dig.c
 * Synopsis:  This program allocates 2 grab buffers on the
 *            on-board memory of the meteor2/Dig and then
 *            grabs in them.
 *            The data is then transferred to the HOST using
 *            the bus-master copy.
 *
 *            This technique can be used when experiencing
 *            grab overruns on heavily loaded systems.
 *
 /

/* Headers. */
#include <stdio.h>
#include <stdlib.h>
#include <conio.h>
#include <mil.h>

/* Main function. */
void main(void)
{
  MIL_ID   MilApplication;
  MIL_ID   MilSystem     ;
  MIL_ID   MilDigitizer  ;
  MIL_ID   MilDisplay    ;
  MIL_ID   MilImageOnBoard[2];
  MIL_ID   MilImageDisp;

  /* Allocations. */
  MappAlloc(M_DEFAULT, &MilApplication);
  MsysAlloc(M_SYSTEM_METEOR_II_DIG, M_DEF_SYSTEM_NUM, M_SETUP, &MilSystem);
  MdigAlloc(MilSystem, M_DEFAULT, M_DEF_DIGITIZER_FORMAT,
                                  M_DEFAULT, &MilDigitizer);
  MdispAlloc(MilSystem, M_DEFAULT, M_DEF_DISPLAY_FORMAT, M_DEFAULT, &MilDisplay);

  /* Allocate a display buffer. */
  MbufAlloc2d(MilSystem,
              (long)(MdigInquire(MilDigitizer, M_SIZE_X, M_NULL)),
              (long)(MdigInquire(MilDigitizer, M_SIZE_Y, M_NULL)),
              8L+M_UNSIGNED,
              M_IMAGE+M_PROC+M_DISP+M_NON_PAGED+M_GRAB, &MilImageDisp);
  MbufClear(MilImageDisp, 0);

  /* Allocate 2 grab buffers on the on-board memory of the board. */
  MbufAlloc2d(MilSystem,
              (long)(MdigInquire(MilDigitizer, M_SIZE_X, M_NULL)),
              (long)(MdigInquire(MilDigitizer, M_SIZE_Y, M_NULL)),
              8L+M_UNSIGNED,
              M_IMAGE+M_GRAB+M_PROC+M_ON_BOARD, &MilImageOnBoard[0]);

  MbufAlloc2d(MilSystem,
              (long)(MdigInquire(MilDigitizer, M_SIZE_X, M_NULL)),
              (long)(MdigInquire(MilDigitizer, M_SIZE_Y, M_NULL)),
              8L+M_UNSIGNED,
              M_IMAGE+M_GRAB+M_PROC+M_ON_BOARD, &MilImageOnBoard[1]);

  /* Enable bus master copying from the Meteor2 to the Host. */
  MsysControl(MilSystem, M_BUS_MASTER_COPY_TO_HOST, M_ENABLE);

  /* Display the buffer. */
  MdispSelect(MilDisplay, MilImageDisp);

  printf("Press enter to grab into the first buffer\n");
  getchar();

  /* Grab and copy to the Host. */
  MdigGrab(MilDigitizer, MilImageOnBoard[0]);
  MbufCopy(MilImageOnBoard[0], MilImageDisp);

  printf("Press enter to grab into the second buffer\n");
  getchar();

  /* Grab and copy to the Host. */
  MdigGrab(MilDigitizer, MilImageOnBoard[1]);
  MbufCopy(MilImageOnBoard[1], MilImageDisp);

  getchar();

  /* Free allocations. */
  MbufFree(MilImageOnBoard[0]);
  MbufFree(MilImageOnBoard[1]);
  MbufFree(MilImageDisp);
  MdispFree(MilDisplay);
  MdigFree(MilDigitizer);
  MsysFree(MilSystem);
  MappFree(MilApplication);
}