Matrox Corona-II

Chapter 1: Matrox Corona-II

This chapter discusses features of ActiveMIL 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\drivers\doc (or user-specified) folder for any additions/modifications to the board specific notes in this chapter or in the ActiveMIL Reference.

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


Corona-II-specific features

Next

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 ActiveMIL

Previous | Next

To use your Matrox Corona-II board with ActiveMIL, you must allocate a Corona-II system; set the System control's SystemDescriptor property to sysSystemCoronaII. This opens communication with the Matrox Corona-II board and allows ActiveMIL 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 MILCor_II.txt file in the \Matrox Imaging\drivers\doc (or user-specified) directory for any additions/modifications to these board specific notes.


Cameras that can be connected to Matrox Corona-II

Previous | Next

The following types of camera can be connected to Matrox Corona-II. You can switch the grab between cameras of the same type using the Channel property of the Digitizer control.

Type of camera | Number supported
RGB | 2
Monochrome | 6
Digitial | 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 image 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

Previous | Next

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

The relationship between the ActiveMIL 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:

ActiveMIL 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.

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

Controlling or inquiring about user-defined signals

To control or inquire about user-defined signals on Matrox Corona-II, you use the UserBits property of the Digitizer control.

You can set the state (on/off) of the user-defined output signals using the UserBits.Item(UserBitIndex).Value property. In addition, you can inquire about the state of the user-defined input and output signals using the same property.


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 ActiveMIL that are particular to the Matrox CronosPlus board and ways that optimize the board's performance. Board-specific information regarding specific properties and methods are integrated into their reference topics. Refer to the milcronos.txt file in the \Matrox Imaging\drivers\doc (or user-specified) folder for any additions/modifications to the board specific notes in this chapter or in the ActiveMIL Reference.

  • Matrox CronosPlus specific features
  • Using Matrox CronosPlus with ActiveMIL
  • Cameras that can be connected to Matrox CronosPlus
    • Internal Buffers
  • User defined signals for the Matrox CronosPlus
    • Controlling or 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.

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

Matrox CronosPlus supports Windows 2000/XP.


Using Matrox CronosPlus with ActiveMIL

Previous | Next

To use your Matrox CronosPlus board with ActiveMIL, you must create a CronosPlus control and set the System control's SystemDescriptor property to sysSystemCronosPlus. This opens communication with the Matrox CronosPlus board and allows ActiveMIL 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\Drivers\doc (or user-specified) directory for any additions/modifications to these board specific notes.


Cameras that can be connected to Matrox CronosPlus

See Also | Previous | Next
Reference:
Digitizer.Channel
Image.Format

The following types of camera can be connected to Matrox CronosPlus. You can switch the grab between cameras of the same type using the Channel property of the Digitizer control.

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

Internal Buffers

Matrox CronosPlus uses an internal FIFO to store 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 imYUV16Packed image format instead of a imBGR24Packed, imBGR24Plannar, imBGR32Packed or imBGR32Planner image format. Using an AGP graphics controller for display instead of a PCI graphics controller will also reduce the PCI load.


User defined signals for the Matrox CronosPlus

Previous | Next

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

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

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

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

Controlling or inquiring about user-defined signals

To control or inquire about user-defined signals on Matrox CronosPlus, you use methods of the System control.

You can set the state (on/off) of the user-defined output signals using the ControlUserBits / ControlUserBitsWithMask method of the System control with sysUserBitValueOut. In addition, you can inquire about the state of the user-defined input and output signals using the InquireUserBits / InquireUserBitsWithMask method with sysUserBitValueIn or sysUserBitValueOut, respectively.

The mask version of the methods allow you to control or inquire about a group of user-defined signals. To use the ControlUserBitsWithMask method, pass the method a bit-encoded mask value that identifies which user-defined signals to affect, as well as a bit-encoded value that specifies the setting for each of these user-defined signals. The Mask parameter determines which user-defined signals will be affected. For example, the value 88 would establish a mask that affects user-defined signals 3, 4, and 6 since the binary equivalent of 88 is equal to 1011000. Similarly, to use the InquireUserBitsWithMask method, pass the method a bit-encoded mask value that identifies the user-defined signals about which to inquire. The method returns a bit-encoded value that specifies the setting for each of these user-defined signals.

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 event when user-defined input signal 0 changes state:

  1. Enable the event, using the UserBitChangedEvent property.
  2. Specify whether user-defined input signal 0 should generate an interrupt upon a rising edge or falling edge, using the ControlUserBits method with sysUserBitInterruptMode set to either sysEdgeRising or sysEdgeFalling.
  3. Enable the interrupt state for user-defined signal 0, using the ControlUserBits method with sysUserBitInterruptState.
  4. Set up a procedure to handle the System control's UserBitChanged event.


Matrox CronosPlus board flow diagrams

Previous

This section contains a data flow diagram for Matrox CronosPlus.


Matrox Genesis

Chapter 3: Matrox Genesis

This chapter discusses features of ActiveMIL 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\drivers\doc (or user-specified) folder for any additions/modifications to the board specific notes in this chapter or in the ActiveMIL Reference.

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


Genesis-specific features

See Also | Next
Board Specific Notes:
Grabbing to a Host image with Matrox Genesis-LC
Using Matrox Genesis with ActiveMIL

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 PowerPC 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.

ActiveMIL 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 ActiveMIL

See Also | Previous | Next
Board Specific Notes:
Genesis-specific features
Grabbing to a Host image with Matrox Genesis-LC

To use a Matrox Genesis-LC board, or a node on a Main or Processor board, you must create a System control, and set the System control's SystemDescriptor property to sysSystemGenesis. This opens communication with the Matrox Genesis board and allows ActiveMIL to use its resources. You can run multiple processes (executabless) on the same board simultaneously. Each process can have one allocated system.

When Matorx Genesis boards are interconnected, they form a cluster. Each Matrox Genesis board in a cluster must still be associated to a separate System control. ActiveMIL will automatically detect the interconnection. If you have several Matrox Genesis boards connected together (forming a cluster), you must create the System controls in sequential order, starting with board 00. For example, if you have a two-board cluster, you cannot create the System control for board 1 before you have created the System control for 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 a Matrox Genesis's display section without accessing the primary PCI bus, ActiveMIL will use not only the board/node's resources and Host computer memory, but also the VGA board. The use of the VGA board has been included to allow you to display grabbed images.


Cameras that can be connected to matrox Genesis

See Also | Previous | Next
Reference:
Digitizer.Channel
Image.Format

The following types of cameras can be connected to Matrox Genesis. You can switch the grab between cameras of the same type using the Channel property of the Digitizer control.

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

See Also | Previous | Next
Board Specific Notes:
Genesis-specific features
Using Matrox Genesis with ActiveMIL

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 store 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 images set up in off-screen memory. This logic toggles the grab between one temporary image and the other, transferring grabbed data from the image 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 images 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 images

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

  1. Increase the default temporary image 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 image size

You can increase the default temporary image size. Larger temporary images 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 store the data. Note, however, that larger temporary images also increase the latency before the beginning of the transfer.

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

max temp image 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 image size for each resolution.

Display Resolution | Bytes of off-screen memory/plan | Maximum temporary image 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 image size by adjusting the SizeOfTmpBufferForHostGrab field in the genesis.ini file.

Grabbing in on-board images

If increasing the size of the temporary images 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 calling the System control's Control method, and then setting the sysBusMasterCopyToHost control type to sysEnable.

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 subsection titled Other options.

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, ActiveMIL 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 create the images by setting the Image control's Location property to imOnBoard, there might not be sufficient true off-screen memory to allocate the entire image. Instead, you might need to create the grab images in the reserved frame buffer memory. To do so, use the Image control's AssignMemory method, create your two images 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.

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 are 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 store one frame. So, you can allocate the images in the off-screen memory of two planes. Since you need to create the images in off-screen memory, simply allocate the image by setting the Image control's Location property to imOnBoard; the images will automatically be created 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 images.
  • 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.


COM ports and UARTS

See Also | Previous | Next
Reference:
Digitizer.SerialPort

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, ActiveMIL can control and access the serial ports (use the SerialPort property of the Digitizer control). 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

Previous | Next

Most of ActiveMIL's processing operations are performed by the on-board Matrox Genesis processor when a sysSystemGenesis SystemDescriptor 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 ProcessingCompensation property of the Application control to False. 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 images will be performed by the Host (the functions are not included in the following list).

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

  • In the Image control:
    • The Bayer method.
  • In the ImageProcessing control:
    • The Divide method.
    • The Convert method with impRGBToY
    • The Resize method with OverscanMode set to impOverscanDisable.
    • The Rotate method with OverscanMode set to impOverscanDisable.

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

  • In the Digitizer control:
    • The Focus method is performed by the Host only when the destination image has a depth of 1 bit.
  • In the Image control:
    • The CopyConditional method is performed by the Host if it uses floating-point images.
  • In the ImageProcessing control:
    • The methods of the WarpParameters property are performed by the Host only when 32-bit LUT images are used.
    • The Add and the Subtract methods, when the saturation parameter is set to True, are performed by the Host under the following conditions:
      • Whenever floating-point images are used.
      • Whenever a mix of 32-bit image types are used.
    • The Divide method is performed by the Host under the following conditions:
      • If either source uses fixed-point.
      • If either source is 32-bit.
      • If the source is 8-bit and the destination is 32-bit.
    • The MultiplyAndAccumulate1 method is performed by the Host under the following conditions:
      • If it uses 32-bit integer images.
      • If the Saturation parameter is set to True and float images are used.
    • The MultiplyAndAccumulate2 method is performed by the Host under the following conditions:
      • If it uses 32-bit integer images.
      • If one source image is signed and the other is unsigned.
      • If the Saturation parameter is set to True and float images are used.
    • The Binarize, Clip, CountDifferences, and LocateEvents methods are performed by the Host if they use float images.
    • The ConnectMap, Dilate, Distance, Erode, Thin, Thick, and Label methods are performed by the Host if they use images with a depth greater than 16 bits.
    • The Convolve method is performed by the Host under any one of the following conditions:
      • When using an IIR filter.
      • If the source or destination image has a depth of 1 bit or greater than 16 bits.
      • If float images 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 image is unsigned 8-bit.
        • The destination image 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.
    • The EdgeDetect1, EdgeDetect2, HorizontalEdge, VerticalEdge, LaplacianEdge1, LaplacianEdge2, Sharpen1, Sharpen2, Smooth, Deriche, and Shen methods are performed by the Host under the same conditions as the Convolve method.
    • The EdgeDetect method is performed by the Host:
      • Except with FastAngleComputation or FastGradientComputation set to True.
      • If the images have a depth greater than 16 bits.
    • The FindExtremes method is performed by the Host when dealing with float images.
    • The Flip method is performed by the Host under the following conditions:
      • When dealing with float images.
      • The source and destination images have different depths.
    • The Histogram method is performed by the Host under the following conditions:
      • When dealing with float images.
      • When dealing with source images with depths greater than 16 bits.
    • The LUTMap method is performed by the Host under the following conditions:
      • When dealing with float images.
      • When dealing with a 32-bit source image.
      • When dealing with a 32-bit signed destination image.
    • The Erode method is performed by the Host if structuring elements exceed 15x15 in size and whenever dealing with images with a depth greater than 16 bits.
    • The Dilate method is performed by the Host if structuring elements exceed 15x15 in size and whenever dealing with images with a depth greater than 16 bits.
    • The Thin method is performed by the Host if grayscale structuring elements are not 3x3 in size or if binary structuring elements exceed 15x15 in size and whenever dealing with images with a depth greater than 16 bits.
    • The Thick method is performed by the Host if grayscale structuring elements are not 3x3 in size or if binary structuring elements exceed 15x15 in size and whenever dealing with images with a depth greater than 16 bits.
    • The HitOrMiss method 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.
    • The Project method is performed by the Host under the following conditions:
      • When dealing with float images.
      • When dealing with 32-bit source images.
    • The Rank method 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 impMedian.
      • When images have a depth greater than 16 bits.
    • The Resize method is performed by the Host under the following conditions:
      • When dealing with float images.
      • When the interpolation mode is either impBilinear or impBicubic and you are using 32-bit source images.
      • When the source image is 32-bit and the destination image is 1-bit or vice-versa.
    • The Rotate method is performed by the Host under the following conditions:
      • When dealing with float images.
      • When the interpolation mode is either impBilinear or impBicubic and you are using 32-bit source images.
      • When the source image is 32-bit and the destination image is 1-bit or vice-versa.
    • The Shift method is performed by the Host when dealing with float images.
    • The FastFourierTransform method is performed by the Host except if the CenterSpectrum parameter is set to False with 32-bit signed images.
    • The Translate method is performed by the Host for fractional X or Y displacement when source and/or destination images have a depth of 1 bit or greater than 16 bits.


User-defined signals for Matrox Genesis

Previous | Next

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

The relationship between the ActiveMIL 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:

ActiveMIL 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:

ActiveMIL 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 or inquiring about user-defined signals

To control or inquire about user-defined signals on Matrox Genesis, you use the UserBits property of the Digitizer control.

You can set the state (on/off) of the user-defined output signals using the UserBits.Item(UserBitIndex).Value property. In addition, you can inquire about the state of the user-defined input and output signals using the same property.


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 ActiveMIL 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 ActiveMIL Reference.

  • Matrox Helios-specific features
    • Summary of Matrox Helios features
    • Note on nomenclature
  • Using Matrox Helios with ActiveMIL
  • Allocating independent ActiveMIL digitizers on Matrox Helios
    • Matrox Helios XA
    • Matrox Helios XCL
  • Preprocessing and formatting grabs with Matrox Helios
    • PA optimizations
      • Real-time PA Processing
    • 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 or 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 128 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 images 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, 6 that can be shared by all digitizers
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 ActiveMIL

See Also | Previous | Next
Board Specific Notes:
Preprocessing and formatting grabs with Matrox Helios

Reference:
System.SystemDescriptor

To use a Matrox Helios board, you must create a System control and set the System control's SystemDescriptor property to sysSystemHelios. This opens communication with the Matrox Helios board and allows ActiveMIL 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.


Allocating independent ActiveMIL digitizers on Matrox Helios

See Also | Previous | Next
Reference:
Digitizer.DeviceNumber
Digitizer.SyncChannel

Depending on the frame grabber, you can allocate several independent ActiveMIL 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 one of two cameras, therefore all digitizers have 2 data channels. You can switch between them using the Channel property of the Digitizer control.

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 a digitizer as an external analog synchronization signal renders that digitizer "occupied" and not available for allocating another digitizer. For example, when allocating a 3-tap RGB camera on acquisition paths 0, 1 and 2 (with the DeviceNumber property of the Digitizer control set to 0) you can set your external synchronization signal on acquisition path 3 (using the SyncChannel property set to digCh3). 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 (as customized in the DCF using Matrox Intellicam), a digitizer for monochrome camera could allocate and use 3 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 (the Digitizer control's DeviceNumber property must be set to 0) with only one data channel (digChannel0).
  • Dual-Base. The dual-Base version has two acquisition paths (the Digitizer control's DeviceNumber property must be set to 0 or 1), but each only has one channel (digChannel0).


Preprocessing and formatting grabs with Matrox Helios

See Also | Previous | Next
Reference:
Application
Application.Timer
Digitizer
Digitizer.GrabMode
Image
Image
Image.Copy
Image.Get
Image.Location
ImageProcessing
ImageProcessing.Resize
Threading.Threads.Item.BusMasterCopy

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 into an image located in on-board memory.
  2. Process the grabbed data on-board. Refer to HeliosPA.txt for a list of available functions.
  3. Copy the image located in on-board memory to an image located in the Host memory.
  4. Process the image located in Host memory.

Note that when timing a PA-supported function, you must wait until the function finishes. Use the Wait method of the Threading control 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 image located in an on-board memory (the Location property of the Image control set to imOnBoard), 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 images is not located in on-board memory, then the processing will be performed by the Host. This will result in all the on-board images first being transferred to the Host before processing begins. Once processing completes, the data is then transferred back to on-board memory. There are, however, 2 exceptions: the Resize and the Flip methods of the ImageProcessing control. These can both have destination images on the Host without forcing all associated images being transferred to the Host.

When grabbing into an image located in off-board memory, 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 the MultipleBuffering.Process method of the Digitizer control for real-time processing and grabbing. It acquires images and store them sequentially in a list of Image controls. It also enables the ProcessModifiedImage event so that the modification to the content of any image in the specified list will trigger the event. So every time a new frame is grabbed to an image in the list, the procedure handling the event is called.

The MultipleBuffering.Process method is optimized for Matrox Helios. The properties of the MultipleBuffering property return statistics regarding the number of frames missed, number of frames processed, and the frame rate. The Matrox Helios driver queues commands into an interrupt service routine (ISR), giving them a higher execution priority. Note that any synchronous method forces the Host to wait until the method finishes; this stops real-time processing. For more information, refer to the Asynchronous and synchronous functionality subsection, later in this section.

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 images are allocated in the on-board memory location.
  • 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 the Timer property of the Application control. 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.

Methods that copy data (such as the Get method and the Copy method of the Image control) are synchronous by default. In addition, the Resize and the Flip methods of the ImageProcessing control are synchronous by default if one image is allocated on-board and the other is off-board. Note that the Copy method of the Image control and the Resize and the Flip methods of the ImageProcessing control can all be used asynchronously by setting the Threads.Item(ThreadIndex).BusMasterCopy property of the Threading control to thrAsynchronousCopy.

Some methods can be performed synchronously if they are configured appropriately (using the ThreadMode property of the System control, the GrabMode property of the Digitizer control, or the Wait method of the Threading control).

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, enable the ContentModifiedEvent property of the Image control, and enable multi-threading by setting the ModifiedBufferHookMode property of the System control to sysMultiThreaded; depending on the workload of the CPU, the operating system uses the available CPUs to dispatch the event procedure when the content of an image changes. ActiveMIL cannot guarantee the order in which the dispatched event procedure is performed on any frame on such a computer because they are executed concurrently. Instead, you can synchronize the threads, using native Windows threads. For more information on ActiveMIL and multi-threading, refer to the Multi-threading section of the Using ActiveMIL with multi-processing and under multi-thread systems chapter.

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. ActiveMIL 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 ActiveMIL's Threading control. Note that when ActiveMIL is running on Matrox Helios, every Host (Windows) thread that sends ActiveMIL methods has an equivalent Matrox Helios on-board thread that executes them.

For more information on ActiveMIL and multi-threading, refer to the Multi-threading section of the Using ActiveMIL with multi-processing and under multi-thread systems chapter.

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 images at the same time.

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, set the Bayer.ConversionEnabled property of the Digitizer control to True. During conversion, the image can be white balanced if white balancing is enabled using the Bayer.WhiteBalanceMode property.

The white balance coefficients can be set explicitly using the Bayer.WhiteBalanceCoefficients property or calculated automatically using the Bayer.CalculateCoefficients method.

The automatic Bayer conversion 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 the Bayer method of the Image control. 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 the Specifying and managing your data buffers chapter.

Memory

By default, all images are allocated in off-board memory. If allocated in Host memory, the images can be in either paged or non-paged memory. If on-board, the image 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 images are allocated in shared memory, they have both a physical address and a logical address on the Host. Images 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 ActiveMIL properties and methods, with the exception of the AssignMemory method of the Image control.

Note that you can only use the AssignMemory method of the Image control with shared or Host memory because it relies on having a physical address recognized by the Host.

To force a image to be allocated in shared memory, set the OnBoardMemoryLocation property of the Image control to imShared.

Note that images 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 image that you could allocate in either type of memory would be 128 Mbytes. If you need to allocate a image 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 image, an error is returned.


Minimum latency and grabbing all frames

See Also | Previous | Next
Reference:
Digitizer.MultipleBuffering.FrameRate
Digitizer.MultipleBuffering.NumberOfFrameMissed
Digitizer.MultipleBuffering.NumberOfFrameProcessed
Digitizer.MultipleBuffering.Process

When grabbing with either the Grab method or the MultipleBuffering.Process method of the Digitizer control, 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 image (either on-board or to the Host). This allows the image to be available for processing with a minimum amount of delay.

By default, Matrox Helios grabs into images located in off-board memory. When grabbing into off-board images, 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 the MultipleBuffering.Process method, use the NumberOfFrameMissed property. Use the NumberOfFrameProcessed property to determine the total number of frames grabbed in the sequence. Use the FrameRate property to return the estimate of the number of frames grabbed.


COM ports and UARTS

See Also | Previous | Next
Reference:
Digitizer.SerialPort

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, ActiveMIL can control and access the serial ports (use the SerialPorts property of the System control). 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 the SerialPorts.Item(SerialPortIndex).COMPortNumber property.

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.


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 images 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

Previous | Next

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

ActiveMIL 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 these 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

When the digitizer's DeviceNumber property is set to 0 on Matrox Helios XCL, the relationship between the ActiveMIL user-defined signal numbers and the actual user-defined signals are as follows:

ActiveMIL 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²

When the digitizer's DeviceNumber property is set to 1 on Matrox Helios XCL, the relationship between the ActiveMIL user-defined signal numbers and the actual user-defined signals are as follows:

ActiveMIL 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 that shares this user-defined signal.

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

Analog

When the digitizer's DeviceNumber property is set to 0 on Matrox Helios XA, the relationship between the ActiveMIL user-defined signal numbers and the actual user-defined signals are as follows:

ActiveMIL 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¹ |  |  |

When the digitizer's DeviceNumber property is set to 1 on Matrox Helios XA, the relationship between the ActiveMIL user-defined signal numbers and the actual user-defined signals are as follows:

ActiveMIL 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¹ |  |  |

When the digitizer's DeviceNumber property is set to 2 on Matrox Helios XA, the relationship between the ActiveMIL user-defined signal numbers and the actual user-defined signals are as follows:

ActiveMIL 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¹ |  |  |

When the digitizer's DeviceNumber property is set to 3 on Matrox Helios XA, the relationship between the ActiveMIL user-defined signal numbers and the actual user-defined signals are as follows:

ActiveMIL 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 the others that share this user-defined signal.

Controlling or inquiring about user-defined signals

To control or inquire about user-defined signals on Matrox Helios, you use the UserBits property of the Digitizer control.

To use user-defined I/O (bi-directional) signals, you must set their mode to either input or output mode, using the UserBits.Item(UserBitIndex).Mode property or the UserBits.SetModeMask method.

You can set the state (on/off) of the user-defined output signals using the UserBits.Item(UserBitIndex).Value property or the UserBits.SetValueMask method. In addition, you can inquire about the state of the user-defined input and output signals using the UserBits.Item(UserBitIndex).Value property or the UserBits.GetValueMask method.

The mask version of the methods allow you to control or inquire about a group of user-defined signals. For example, to use the UserBits.SetValueMask method, pass the method a bit-encoded mask value that identifies which user-defined signals to affect, as well as a bit-encoded value that specifies the setting for each of these user-defined signals. The Mask parameter determines which user-defined signals will be affected. For example on Matrox Helios XCL, the value 45 would establish a mask that affects user-defined signals 0, 2, 3, and 5 since the binary equivalent of 45 is equal to 101101. Similarly, to use the UserBits.GetValueMask method, pass the method a bit-encoded mask value that identifies the user-defined signals about which to inquire. The method returns a bit-encoded value that specifies the setting for each of these user-defined signals.

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 event when there is a change in the state of a user-defined input signal:

  1. Enable the event, by setting the UserBitChangedEvent property to True.
  2. If bi-directional (I/O), set the user-defined signal to input mode as described above.
  3. Enable the interrupt state for the user-defined signal, by setting the UserBits.Item(UserBitIndex).InterruptEnabled property to True. The user-defined signal will generate an interrupt upon a rising edge.
  4. Set up a procedure to handle the Digitizer control's UserBitChanged event.

    5. The UserBitChanged event's UserBit parameter returns the user-defined signal(s) that generated the interrupt. Accordingly, in a series of case statements, specify the course of action for the appropriate user-defined signal.


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 Matrox Helios XCL.

The following diagram illustrates the data flow of Single-Full Camera Link Frame Grabber.

Matrox Helios XA

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


Matrox Meteor-II

Chapter 5: Matrox Meteor-II

This chapter discusses features of ActiveMIL 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\drivers\doc (or user-specified) folder for any additions/modifications to the board specific notes in this chapter or in the ActiveMIL Reference.

  • Matrox Meteor-II-specific features
    • UART
  • Using Matrox Meteor-II with ActiveMIL
  • Cameras that can be connected to Matrox Meteor II.
    • Matrox Meteor-II /Camera Link
  • Grabbing to a Host image with Matrox Meteor-II /Digitial and /Camera Link
    • Optimizing the use of the frame buffers
    • Increasing the default temporary image size
    • Grabbing in on-board images
    • Grabbing large frames of data
  • IEEE 1394 serial bus-specific features
    • Video formats and modes
    • Read/write capabilities
    • Grab images with Matrox Meteor-II /1394
  • Grabbing from multiple 1394 DCAM-compliant cameras
    • In general
    • Establishing a pool of IEEE 1394 DCAM-compliant cameras
    • Assigning a camera/digitizer to a system
    • Important points to consider
  • Setting 1394 DCAM-compliant camera features
    • Setting general camera controls
    • Setting 1394 DCAM-specific camera controls
  • 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 or 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 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
On-board UART (PCI form factor) | X | X | X |  | X
VMChannel (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
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 ActiveMIL

Previous | Next

To use your Matrox Meteor-II board with ActiveMIL, you must create a Meteor-II system and set the System control's SystemDescriptor property to one of the following:

  • sysSystemMeteorII
  • sysSystemMeteorII_Dig
  • sysSystemMeteorII_1394
  • sysSystemMeteorII_Cl

Setting the SystemDescriptor property establishes an ActiveMIL system environment in which ActiveMIL not only uses the Matrox Meteor-II board and Host computer memory, but also any available graphics controller. The graphics controller board has been included to allow you to display grabbed images (none of the Matrox Meteor-II boards has 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, refer to the IEEE 1394 serial bus-specific features section, later in this chapter.

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


Cameras that can be connected to Matrox Meteor II.

Previous | Next

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 betwen cameras of the same type using the Channel property of the Digitizer control.

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.

¹ Also, note that 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. 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 digChannel0 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.


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

Previous | Next

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 images created within the video transfer memory. This logic toggles the grab between one temporary image and the other, transferring grabbed data from the image 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 images 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 image 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 image size

You can increase the default temporary image size. Larger temporary images 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 images also increase the latency before the beginning of the transfer.

You can increase the default temporary image 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 images 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 enabling the BusMasterCopy property of the thread item in the Threading control.

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 image. This restriction does not apply to Matrox Meteor-II /Camera Link, since 32 Mbytes of video transfer memory are available.


IEEE 1394 serial bus-specific features

See Also | Previous | Next
Board Specific Notes:
Grabbing from multiple 1394 DCAM-compliant cameras

Reference:
Digitizer.Allocate

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

In ActiveMIL, to access and acquire data from an IEEE 1394 DCAM-compliant camera, assign it as a digitizer (Digitizer control's Allocate method) on a Matrox "Meteor_II_1394" system. To access and acquire data from multiple IEEE 1394 DCAM-compliant cameras, refer to the subsection titled " Grabbing from multiple 1394 DCAM-compliant cameras ".

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 x1200)
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, ActiveMIL 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. These video formats are standard on most cameras.

Note that the Matrox Meteor-II /1394 driver does not support native RGB and YUV 4:4:4 camera modes.

At design-time, you can set the data format/mode for your 1394-based camera using the list of all supported formats that is available on the Property page of the Digitizer control. This list is also available through the property browser for the digitizer.

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

Read/write capabilities

The read and write capabilities of Matrox Meteor-II /1394 in ActiveMIL are supported through specific digitizer properties, as well as through the Digitizer control's Control and Inquire methods.

Use the appropriate digitizer property, or the digitizer's Inquire method, to read the actual, minimum, or maximum value of any status register feature. Similarly, use the appropriate digitizer property, or the digitizer's Control method, to modify the actual value of a status or control register feature.

Grab images with Matrox Meteor-II /1394

Grabbing, 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 image allocation time. To resolve this issue, temporary images are internally created a grab image is created; the grab occurs to an internal image and then copied to the allocated grab image, converting the data, if necessary. Note that by default, the allocation format of the grab image 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 the GrabContinuous method of the Digitizer control than to use the Grab method with a displayable image. This is because if the grabbed data is in the format of the display, the data does not undergo conversion.


Grabbing from multiple 1394 DCAM-compliant cameras

Previous | Next

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 (by setting each control's OwnerSystem property to a "Meteor_II_1394" (Meteor-II /1394) system. With each call, the Digitizer control's DeviceNumber property must be set to the camera number, starting from 0. You can then perform simultaneous grabs from each of these cameras, hardware permitting, by making multiple grabs with the appropriate AcitveMIL digitizer (camera) identifiers.

Establishing a pool of IEEE 1394 DCAM-compliant cameras

All IEEE 1394-compliant cameras that are attached to a Matrox Meteor-II /1394 board are detected when the first "Meteor_II_1394" System control is created. This establishes a "pool" of 1394-based cameras. Any camera attached after the pool has been established cannot be accessed (allocated as digitizers).

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

When it is necessary to manage multiple systems, the System control's order or rank can be set using the System control's DeviceNumber property.

Assigning a camera/digitizer to a system

Although cameras in the pool are detected, these cameras are not associated with a System control. To be used on a system, a camera from the pool must be assigned to one of the available "Meteor_II_1394" systems (by creating a Digitizer control for the camera and set the control's OwnerSystem property setting appropriately).

A camera in the pool has no fixed device number. Accordingly, you need to set the Digitizer control's DeviceNumber property appropriately. To accomplish this:

  1. Inquire the number of cameras (digitizers) that can be assigned to the System control using the NumberOfDigitizers property. This returns the number of cameras (Digitizer controls) already assigned 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. Set the DeviceNumber property to a number that is less than this inquired value (from step 1), and that has not already been used for another camera (Digitizer control) on the system.

Important points to consider

Once a camera is assigned as a digitizer on an ActiveMIL system, the camera (digitizer) then belongs to the system, until it is freed with the Digitizer control's Free method. When a camera (digitizer) is freed, it is returned to the common pool of available cameras (digitizers).

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

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


Setting 1394 DCAM-compliant camera features

Previous | Next

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

Setting general camera controls

The general camera features include brightness, hue, saturation and (input) gain. For portability, you should set/control these standard camera features in the conventional way using the corresponding feature property. That is, use the Digitizer control's Brightness, Hue, Saturation, Contrast, and InputGain properties to set the corresponding camera feature.

On a Matrox Meteor-II /1394, the relevant digitizer properties will map the smallest value supported by the camera to digMinLevel, and map the largest value supported by the camera to digMaxLevel. The number of values supported by your camera can differ such that consecutive reference-level settings might produce the same result. See the Reference Level section in the ActiveMIL On-line User Guide for more details on reference levels.

If you need more flexibility when setting these features, you can use the method described below for 1394 DCAM-specific camera controls.

Setting 1394 DCAM-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 the minimum and maximum possible values of a required control feature using the Digitizer control's Inquire method.

    2. To do so, add digMinimumValue or digMaximumValue to the specified inquire type, respectively. For example, to inquire the minimum sharpness value, use digSharpness + digMinimumValue.

  2. Once you have determined the range of possible values, you can set or adjust the 1394 camera feature-option by using the Digitizer control's Control method and specifying the control type feature. See the list of Matrox Meteor-II /1394-specific control types that can be used with the digitizer's Control method.

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


User-defined signals for Matrox Meteor-II

Previous | Next

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 ActiveMIL user-defined signal numbers and the actual user-defined signals on the digital interface connector are as follows:

ActiveMIL 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 ActiveMIL user-defined signal numbers and the actual user-defined signals on the auxiliary synchronization and control connector are as follows:

ActiveMIL user-defined signal # | I/O | Auxiliary synchronization and control signal
0 | I | USER0 INPUT (RS-422/LVDS) signal.
0 | O | Group 0 of the CAMCTRLn¹ OUTPUT (TTL only) signals.³
1 | I | USER1 INPUT (RS-422/LVDS only) signal.
1 | O | Group 1 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 in the DCF. Otherwise, use the Digitizer's control Control method with digCameraControlOutputxSource to identify which CAMCTRL signal (0 through 4) you wish to effect. Using digCameraControlOutputxSource with digUserBit0 or digUserBit1 to associate with group 0 and group 1 (where digUserBit0 is user-defined signal 0 and digUserBit1 is user-defined signal 1).

² 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 value of the user-defined input signal for the same user-defined signal number is returned.

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

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

ActiveMIL 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 or inquiring about user-defined signals

To control or inquire about user-defined signals on Matrox Meteor-II, you use the UserBits property of the Digitizer control.

You can set the state (on/off) of the user-defined output signals using the UserBits.Item(UserBitIndex).Value property. In addition, you can inquire about the state of the user-defined input and output signals using the same property.


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 6: Matrox Morphis

This chapter discusses features of ActiveMIL 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 ActiveMIL Reference.

  • Matrox Morphis-specific features
    • Acquisition features
    • Compression/decompression
    • Additional functionality
    • Data transfer
  • Using Matrox Morphis with ActiveMIL
    • JPEG2000 support
  • Cameras that can be connected to Matrox Morphis
  • COM ports and UARTS
  • Matrox Morphis JPEG2000
    • Compression/decompression
    • Warming up
  • Matrox Morphis watchdog functionality
  • Matrox Morphis utilities
    • Usage Meter
    • Matrox Morphis Bench
  • User defined signals for Matrox Morphis
    • Controlling or 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 two frame grabbers capable of acquiring standard, monochrome/color, analog video. It 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 Dual, Matrox Morphis PC/104-Plus, and Matrox Morphis Quad), and relates them to specific properties and methods in ActiveMIL.

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 any two connected, supported, asynchronous cameras, using its two independent acquisition paths. In addition, it can switch the capture (channel switch) between cameras of the same type. If not simultaneously capturing from two cameras, Matrox Morphis family of frame grabbers can perform ultra-fast switching. Matrox Morphis Dual and Matrox Morphis PC/104-Plus has two independent acquisition paths and Matrox Morphis Quad has four independent acquisition paths.

The Matrox Morphis family of frame grabbers 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 base board, and the Matrox Morphis Video and I/O module and the Matrox Morphis Video Input module are mutually exclusive.

Formatting features of the Matrox Morphis family of frame grabbers include cropping (ROI capture), arbitrary downscaling 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 supports real-time performance for standard video rates, lossy (9/7 wavelet) and lossless (5/3 wavelet) modes. In addition, Matrox Morphis supports up to 12 bits 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 has 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 incorporates 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 devices user inputs. These signals can be internally accessed, or accessed externally using the Matrox Morphis Video and I/O module. ¹
  • 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 frame grabbers allows continuous grabbing to Host memory or video memory. They also features 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 ActiveMIL

Previous | Next

To use a Matrox Morphis board, you must create a Morphis system and set the System control's SystemDescriptor property to sysSystemMorphis. This opens communication with the Matrox Morphis board and allows ActiveMIL 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-board Matrox Morphis. This provides a royalty-free run-time compression/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.

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


Cameras that can be connected to Matrox Morphis

Previous | Next

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 have up to two independent digitizers on Matrox Morphis Dual and Matrox Morphis PC/104-Plus, or up to 4 independent digitizers on Matrox Morphis Quad.

Each acquisition path supports input from a total of 15 data channels. You can switch the grab between cameras of the same type using the Digitizer control's Channel property.


COM ports and UARTS

Previous | Next

Matrox Morphis 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). For more information, refer to the Matrox Morphis Installation and Hardware Reference manual. Alternately, ActiveMIL can control and access the serial ports (use the SerialPorts property of the System control). To learn which UART is associated to which Microsoft Windows COM port, use the SerialPorts.Item(SerialPortsIndex).COMPortNumber property.


Matrox Morphis JPEG2000

Previous | Next

The Matrox Morphis can optionally perform JPEG2000 compression/decompression when integrated with a JPEG2000 accelerator. Matrox Morphis has 2 independent 16 Mbyte memory banks: one for general acquisiton 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, buffers allocated on Matrox Morphis are compressed/decompressed 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 (using the Image control's Location property set to imOnBoard). Compression is done when the grab buffer is copied from an uncompressed to a compressed buffer using the Copy method of the Image control.

The following buffer formats are supported for compression:

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

The following buffer formats are supported for decompression:

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

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 the JPEG2000Algorithm.DecompositionLevel property of the Image control..
  • The quantification tables (inquired using the JPEG2000Algorithm.Quantization property of the Image control) cannot be changed when dealing with on-board compression/decompression. Instead, they are ignored.
  • The width of the image must be a multiple of 64. To set it, use the SizeX property of the Image control.
  • The height of the image must be a multiple of 8. To set it, use the SizeY property of the Image control.

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

Warming up

The Matrox Morphis JPEG2000 accelerator, once configured to either compress or decompress, provides a faster rate of compression/decompression than if it must change its mode before compressing (or decompressing). 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.


Matrox Morphis watchdog functionality

Previous | Next

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 Matrox Morphis PC/104-Plus does not have Watchdog functionality.

When enabled, using the Watchdog.Enabled property of the System control, your application should send a reset signal within the time specified by the timeout timer. Each time the reset signal is received, Watchdog resets its timeout 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 the Watchdog.Timeout property. 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 the Watchdog.Reset method.

If the Watchdog warning does not receive a response within the specified time allotted by the warning timer, the Watchdog will perform the event procedure specified by the WatchdogWarning event. 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 event procedure should be examined to assure that it completes before the Watchdog reboot timer expires.

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 the Watchdog.RebootTimeout property. The Watchdog also keeps a count of the number of times your computer reboots. Use the Watchdog.NumberOfReboots property. To reset the counter that records how often your computer has rebooted use the Watchdog.ClearNumberOfReboots method.

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


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 Imagaing\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

Previous | Next

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 ActiveMIL user-defined signal numbers and the actual user-defined signals on the external video & I/O connector 0 are as follows:

ActiveMIL 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 or inquiring about user-defined signals

To control or inquire about user-defined signals on Matrox Morphis, you use methods of the System control.

You must set the mode of the required user-defined signals to either input or output mode, using the ControlUserBits / ControlUserBitsWithMask method of the System control with sysUserBitMode.

You can set the state (on/off) of the user-defined output signals using the ControlUserBits / ControlUserBitsWithMask method with sysUserBitValueOut. In addition, you can inquire about the state of the user-defined input and output signals using the InquireUserBits / InquireUserBitsWithMask method with sysUserBitValueIn or sysUserBitValueOut, respectively.

The mask version of the methods allow you to control or inquire about a group of user-defined signals. To use the ControlUserBitsWithMask method, pass the method a bit-encoded mask value that identifies which user-defined signals to affect, as well as a bit-encoded value that specifies the setting for each of these user-defined signals. The Mask parameter determines which user-defined signals will be affected. For example, the value 45 would establish a mask that affects user-defined signals 0, 2, 3, and 5 since the binary equivalent of 45 is equal to 101101. Similarly, to use the InquireUserBitsWithMask method, pass the method a bit-encoded mask value that identifies the user-defined signals about which to inquire. The method returns a bit-encoded value that specifies the setting for each of these user-defined signals.

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 event when there is a change in the state of a user-defined input signal:

  1. Enable the event, using the UserBitChangedEvent property.
  2. 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 the ControlUserBits method with sysUserBitInterruptMode set to either sysEdgeRising or sysEdgeFalling.
  4. Enable the interrupt state for the user-defined input signal, using the ControlUserBits method with sysUserBitInterruptState.
  5. Set up a procedure to handle the System control's UserBitChanged event.

    6. The UserBitChanged event's UserBit parameter returns the user-defined signal(s) that generated the interrupt. Accordingly, in a series of case statements, specify the course of action for the appropriate user-defined signal.


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 Quad base board.

The following diagram illustrates the video & I/O module of a Matrox Morphis.

The following diagram illustrates the video input module of a Matrox Morphis.


Matrox Odyssey

Chapter 7: Matrox Odyssey

This section discusses features of ActiveMIL 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 ActiveMIL 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 ActiveMIL
    • MIL on-board
  • Allocating independent ActiveMIL 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 or inquiring about user-defined signals
    • Interruptible user-defined signals
  • Matrox Odyssey board flow diagrams
    • 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 the 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 a cache, and up to 1 Gbyte 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 Odyssey Xpro/Xpro+ offers 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 operatiors, large LUT mapings, 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+ offers 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 (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 in that they each have 256 Mbytes of memory, no L3 cache, and no link ports. They are not scalable through the link ports, and have a lower processor speed. Matrox Odyssey XCL has an integrated Camera Link frame grabber section rather than a PMC site. Note that the integrated acquistion section is almost identical in functionality to the associated frame grabber module fro the Matrox Odyssey XPro/Xpro+.

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

¹ Note that the integrated analog acquistion section is alost identical to the Analog module. The acqusition 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 Odyssey link ports, allowing image transfers from a Matrox Odyssey 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 Gbyte¹ | 2 Gbyte¹ | 2 Gbyte¹ | 512 Mbyte | 512 Mbyte | 512 Mbyte
Cache | Yes² | Yes² | Yes² | No | No | No
Scalable through link ports | Yes¹ | Yes¹ | Yes¹ | No | No | No
Matrox Oasis ASIC | Yes¹ | Yes¹ | Yes¹ | Yes | Yes | Yes
Acquisition section | Camera Link PMC 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. | 8/digitzer, 8 that can be shared by all digitizers. | 2/digitizer, 2 that can be shared by all digitizers. | 2/digitizer, 2 that can be shared by all digitizers. | 8/digitzer, 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/digitzer | 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, 4 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, 4 in, 1 I/O) / digitizer, 8 that can be shared by all digitizers.

¹ On Matrox Odyssey XPro.

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

³ This item lists the values for both dual-Base and single-Full.

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+ is not listed in the ActiveMIL reference. When using Matrox Odyssey Xpro/Xpro+, refer to the following table for more information:

Reference in ActiveMIL reference | Matrox Odyssey Xpro
Matrox Odyssey XA | Refers to Matrox Odyssey Xpro with or without an Analog module¹ and to Matrox Odyssey XA.
Matrox Odyssey XCL | Refers to Matrox Odyssey Xpro with or without a Camera Link module and to Matrox Odyssey XCL
Matrox Odyssey XD | Refers to Matrox Odyssey 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 in the cluster has an acquisition module.

Special mention is made in the ActiveMIL 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 ActiveMIL

Previous | Next

To use any Matrox Odyssey board, you must allocate it as a Odyssey system; set the System control's SystemDescriptor property to sysSystemOdyssey. This allocation opens communication with the Matrox Odyssey board and allows ActiveMIL 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. ActiveMIL 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 Xpro/Xpro+ boards with only one frame grabber, a digitizer can be allocated on both ActiveMIL systems). It is, however, more efficient to allocate the digitizer on the system where the frame grabber resides.

Refer to the MilOdyssey.txt file in the \Matrox Imaging\drivers\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 an ActiveMIL method, or set an ActiveMIL property, that uses Matrox Odyssey as a system, the corresponding MIL function on-board is called, ensuring optimum performance. This provides a royalty-free run-time environment when used exclusively with Matrox Odyssey. If your application also uses other ActiveMIL systems that run their algorithms on the Host however, you will need to purchase separate redistribution (run-time) licenses.

When grabbing with either the Grab method or the MultipleBuffering.Process method of the Digitizer control, 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 image (either on-board or to the Host). This allows the image to be available for processing with a minimum amount of delay.

Note that it is possible to exceed teh amount of memory allcoated for applications (heap size) on your Matrox Odyssey. Use MIL Config to change the heap size to better suit your application. See the MilOdyssey.tx t file for more details.


Allocating independent ActiveMIL digitizers on Matrox Odyssey

Previous | Next

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

One ActiveMIL 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 one of two sources, therefore all digitizers have 2 signal channels. You can switch between them using Digitizer.Channel.

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 single dedicated for synchronization either on the same acquisition path or another acquisition path. For example, when allocating a 3-tap RGB camera on acquisition paths 0, 1 and 2 (with Digitizer.DeviceNumber property) you can set your external synchronization signal on acquisition path 3 (using the Digitizer.SyncChannel property set to digCh3). This results in acquisition path 3 not being available for allocation for another camera. Alternatively, if using an external digitizer synchronization signal on acquisition path 3 (by customizing the DCF using Matrox Intellicam), a digitizer for a monochrome camera could be allocated and use digCh3 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 numbers that you should use when connecting asynchronous cameras of different types.

Each available acquisition path can consist of multiple signals. Synchronization signals can come only combined with the data. Note that the Digitizer.SyncChannel property is not supported on Matrox Odyssey XD.

Matrox Odyssey XCL

The number of independent digitizers available 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 (Digitizer.DeviceNumber set to digNum0) with only one data channel (digCh0).
  • Dual-Base. The Dual-Base version has two acquisition paths Digitizer.DeviceNumber set to digNum0 or digNum1), but each only has one data channel (digCh0).

Matrox Odyssey Xpro/Xpro+ frame grabber modules

When frame grabber modules are present in a cluster, you can control and inquire digitizers that use the acquisition paths of any of the modules within the cluster. In a cluster, the acquisition path of all modules present are associated with sequential device numbers, determined by ActiveMIL. 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, ActiveMIL has numbered the acquisition paths of the Analog module fore those of the Camera Link module. Note that the position of each module within a cluster is determined by ActiveMIL and not the user. The acquisition paths on the Analog module are associated with digNum0 to digNum3. The acquisition paths on the. Camera Link module are associated with digNum4 to digNum5.

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 styles.

To determine which device number associates with which board, use the Inquire method of the System control with the acquisition path in question. Use the NumberOfDigitizers property of the System control to return the total number of available acquisition paths available to the specified system.


Optimizing performance

Previous | Next

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

Transferring an image between two boards

The Image.Copy method provides the best possible use of system resources, including speed in transferring data. The Image.Copy method will determine if the source and destination images are on different systems that are in the same cluster, and 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 (applications) can run simultaneously on Matrox Odyssey. 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. ActiveMIL applications are autonomous processes (or executables) and therefore can profit from multi-processing by executing independently. For more information, see the Multiple Systems section in the Building an Application chapter of the ActiveMIL User Guide.

Multi-threaded applications are possible with Matrox Odyssey. To control the threads and manage events, use ActiveMIL's Threading control. Note that when ActiveMIL is running on Matrox Odyssey, every Host (Windows) thread that sends ActiveMIL functions has an equivalent Matrox Odyssey on-board thread that executes them. For information on ActiveMIL and multi-threading, see the Multithreading section in the Using ActiveMIL with multi-processing and under multithread systems chapter of the ActiveMIL 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. ActiveMIL functions that are compute-intensive, such as convolution functions, benefit from the PA's speed and reliability. The PA considerably reduces the time required by I/O-intensive operations since it has faster access to on-board memory when compared to the G4 PowerPC.

Refer to the OdysseyPA.txt file in the \Matrox Imaging\ActiveMIL\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 Matrox Odyssey for execution. The Host-driven mode is the easiest to implement but can be 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. 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 both asynchronous and synchronous processing. When Matrox Odyssey is in Host-driven mode, if the function is listed in the OdysseyPA.txt file, the function is executed asynchronously, otherwise it is synchronous. When Matrox Odyssey is in fully embedded mode, all functions are asynchronous.

Refer to the OdysseyPA.txt for more information.

Note that some functions can perform synchronously if they are configured appropriately (using System.ThreadMode property, the Digitizer.GrabMode property, and the Threading.Wait method.

Bayer conversion

Matrox Odyssey 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, set the Bayer.ConversionEnabled property of the Digitizer control to True. During conversion, the image can be white balanced if white balancing is enabled using the Bayer.WhiteBalanceMode property.

The white balance coefficients can be set explicitly using the Bayer.WhiteBalanceCoefficients property or calculated automatically using the Bayer.CalculateCoefficients method.

The automatic Bayer conversion 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 the Bayer method of the Image control. 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 the Specifying and managing your data buffers chapter.

Memory

By default, all images are allocated in on-board, unshared memory. If allocated in Host memory, the images can be in either paged or non-paged memory. If on-board, the image 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 images are allocated in shared memory, they have both a physical address and a logical address on the Host. Images 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 ActiveMIL properties and methods, with the exception of the AssignMemory method of the Image control.

Note that you can only use the AssignMemory method of the Image control with shared or Host memory because it relies on having a physical address recognized by the Host.

To force a image to be allocated in shared memory, set the OnBoardMemoryLocation property of the Image control to imShared.

Note that images 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 image you could allocate in either type of memory would be 128 Mbytes. If you need to allocate a image 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 image, 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 image to be allocated in shared memory, set the OnBoardMemoryLocation property of the Image control to imFastMemory.

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.


COM ports and UARTS

See Also | Previous | Next
Reference:
Digitizer.SerialPort

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, ActiveMIL can control and access the serial ports (use the Digitizer.SerialPort property). For more information, refer to the Matrox Odyssey Installation and Hardware Reference manual. To learn which UART is associated to which Microsoft Windows COM port, use Digitizer.SerialPort.Number.

With 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

Previous | Next

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

ActiveMIL 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 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

When the digitizer's DeviceNumber property is set to 0 on Matrox Odyssey XCL, the relationship between the ActiveMIL user-defined signal numbers and the actual user-defined signals are as follows:

ActiveMIL 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²

When the digitizer's DeviceNumber property is set to 1 on Matrox Odyssey XCL, the relationship between the ActiveMIL user-defined signal numbers and the actual user-defined signals are as follows:

ActiveMIL 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 |
6 | I/O | P1_TTL_AUX_IO_0 |
7 | I/O | P1_TTL_AUX_IO_1 |
8 | I/O | TTL_AUX_IO_0¹ |
8 | I/O | TTL_AUX_IO_1¹ |
9 | I | LVDS_AUX_IN0¹ |
10 | I | LVDS_AUX_IN1¹ |
11 | I | OPTO_AUX_IN0¹ |
12 | 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 digitzers. 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

When the digitizer's DeviceNumber property is set to 0 on Matrox Odyssey XA, the relationship between the ActiveMIL user-defined signal numbers and the actual user-defined signals are as follows:

ActiveMIL 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(EXP)_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¹ |  |  |

When the digitizer's DeviceNumber property is set to 1 on Matrox Odyssey XA, the relationship between the ActiveMIL user-defined signal numbers and the actual user-defined signals are as follows:

ActiveMIL 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(EXP)_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¹ |  |  |

When the digitizer's DeviceNumber property is set to 2 on Matrox Odyssey XA, the relationship between the ActiveMIL user-defined signal numbers and the actual user-defined signals are as follows:

ActiveMIL 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(EXP)_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¹ |  |  |

When the digitizer's DeviceNumber property is set to 3 on Matrox Odyssey XA, the relationship between the ActiveMIL user-defined signal numbers and the actual user-defined signals are as follows:

ActiveMIL 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(EXP)_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 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

When the digitizer's DeviceNumber property is set to 0 on Matrox Odyssey XD, the relationship between the ActiveMIL user-defined signal numbers and the actual user-defined signals are as follows:

ActiveMIL 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¹ |

When the digitizer's DeviceNumber property is set to 1 Matrox Odyssey XD, the relationship between the ActiveMIL user-defined signal numbers and the actual user-defined signals are as follows:

ActiveMIL 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¹ |

When the digitizer's DeviceNumber property is set to 2 on Matrox Odyssey XD, the relationship between the ActiveMIL user-defined signal numbers and the actual user-defined signals are as follows:

ActiveMIL 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¹ |

When the Digitizer.DeviceNumber property is set to 3 on Matrox Odyssey XD, the relationship between the ActiveMIL user-defined signal numbers and the actual user-defined signals are as follows:

ActiveMIL 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 user-defined signals 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 or inquiring about user-defined signals

To control or inquire about user-defined signals on Matrox Odyssey, you use the UserBits property of the Digitizer control.

To use user-defined I/O (bi-directional) signals, you must set their mode to either input or output mode, using the UserBits.Item(UserBitIndex).Mode property or the UserBits.SetModeMask method.

You can set the state (on/off) of the user-defined output signals using the UserBits.Item(UserBitIndex).Value property or the UserBits.SetValueMask method. In addition, you can inquire about the state of the user-defined input and output signals using the UserBits.Item(UserBitIndex).Value property or the UserBits.GetValueMask method.

The mask version of the methods allow you to control or inquire about a group of user-defined signals. For example, to use the UserBits.SetValueMask method, pass the method a bit-encoded mask value that identifies which user-defined signals to affect, as well as a bit-encoded value that specifies the setting for each of these user-defined signals. The Mask parameter determines which user-defined signals will be affected. For example on Matrox Odyssey XCL, the value 45 would establish a mask that affects user-defined signals 0, 2, 3, and 5 since the binary equivalent of 45 is equal to 101101. Similarly, to use the UserBits.GetValueMask method, pass the method a bit-encoded mask value that identifies the user-defined signals about which to inquire. The method returns a bit-encoded value that specifies the setting for each of these user-defined signals.

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 event when there is a change in the state of a specified user-defined input signal:

  1. Enable the event, by setting the UserBitChangedEvent property to True.
  2. If bi-directional (I/O), set the user-defined signal to input mode as described above.
  3. Enable the interrupt state for the user-defined signal, by setting the UserBits.Item(UserBitIndex).InterruptEnabled property to True. The user-defined signal will generate an interrupt upon a rising edge.
  4. Set up a procedure to handle the Digitizer control's UserBitChanged event.

    5. The UserBitChanged event's UserBit parameter returns the user-defined signal(s) that generated the interrupt. Accordingly, in a series of case statements, specify the course of action for the appropriate user-defined signal.


Matrox Odyssey board flow diagrams

Previous

This section contains data flow diagrams for Matrox Odyssey boards.

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 8: Matrox Orion

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

  • Orion-specific features
    • Display features
  • Using Matrox Orion with ActiveMIL
  • 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 or inquiring about user-defined signals
  • Matrox Orion board flow diagram
    • Matrox Orion
    • 4Sight-II add-on boards


Orion-specific features

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 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/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 ActiveMIL

See Also | Previous | Next
Board Specific Notes:
Orion-specific features

To use your Matrox Orion board with ActiveMIL, you must create a System control, and set the System control's SystemDescriptor property to sysSystemOrion. This allocation opens communication with the Matrox Orion board and allows ActiveMIL to use its resources.

Refer to the MILOrion.txt file in the \Matrox Imaging\drivers\doc folder for an addtions/modifications to these board specific notes.


Cameras that can be connected to Matrox Orion

Previous | Next

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 the Channel property of the Digitizer control.

Board | Type of camera | Number of cameras
Matrox Orion (for AGP/PCI) | Monochrome RS-170/CCIR | 6 (using the RGB path)
 |  | 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)
 |  | 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, you can set the signal and synchronization separately (using the Channel property and the SyncChannel property of the Digitizer control) to control the channel of the data and synchronization signals, respectively.


Simultaneous real-time grab transfer to the display and Host

Previous | Next

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 an image selected on the display and at the same time, grab in a monochrome Host image for processing.

To use this feature, create two Digitizer controls. Both digitizers must have the same device number (set the DeviceNumber property of the Digitizer control to 0) and the same DCF because physically, the same acquisition paths are used.

After the digitizers are allocated, you can then use the GrabContinuous method of one Digitizer control to grab into an image selected on the display and use the Grab method of the second Digitizer control to grab into a Host image. This results in the same grabbed image being transferred to each image in their respective destination formats.

Both the image selected to the display and the Host image need not be in the same format or the same size. In addition, the GrabMode, ScaleX, and ScaleY properties can be independently set for each digitizer. Changing any other property for one digitizer, will affect the other.


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 image 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 Orion

Previous | Next

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

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

ActiveMIL user-defined signal # | I/O | Expanded video I/O connector signal
1 | I | USER1 INPUT (TTL only) signal.
2 | I | USER2 INPUT (TTL only) signal.
3 | O | USER1 OUTPUT (TTL only) signal.
4 | O | USER2 OUTPUT (TTL only) signal.

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

Controlling or inquiring about user-defined signals

To control or inquire about user-defined signals on Matrox Orion, you use the UserBits property of the Digitizer control.

You can set the state (on/off) of the user-defined output signals using the UserBits.Item(UserBitIndex).Value property. In addition, you can inquire about the state of the user-defined input and output signals using the same property.


Matrox Orion board flow diagram

Previous

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

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 board.

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

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


Matrox Solios

Chapter 9: Matrox Solios

This section discusses features of ActiveMIL 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 ActiveMIL Reference.

  • Matrox Solios-specific features
    • Summary of Matrox Solios features
    • Note on nomenclature
  • Using Matrox Solios with ActiveMIL
  • Allocating independent ActiveMIL 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 or inquiring about user-defined signals
    • Interruptible user-defined signals
  • Matrox Solios board flow diagrams
    • Matrox Solios XCL
    • Matrox Solios XA


Matrox Solios-specific features

Next

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, 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 allocating a Digitizer control (using either the Allocate method, or enabling the AutomaticAllocation property of the Digitizer control) will result in an error.

Matrox Solios 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 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 images 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, 4 in) /digitizer, 6 that can be shared by all digitizers. | 3 out, 10 in.
LUT | Yes | Yes | Yes

¹ Matrox Solios XA single analog has only 1 acquisition path. It uses the same user-defined signals as Matrox Solios XA with a DeviceNumber property of the Digitizer control set to 0.

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 ActiveMIL

Previous | Next

To use a Matrox Solios board, you must create a System control and set the System control's SystemDescriptor property to sysSystemSolios. This opens communication with the Matrox Solios board and allows ActiveMIL 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.


Allocating independent ActiveMIL digitizers on Matrox Solios

Previous | Next

Depending on the frame grabber, you can allocate several independent ActiveMIL 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's device number to use when connecting asynchronous cameras of different types.

Each acquisition path supports one of two cameras, therefore all digitizers have 2 data channels. You can switch between them using the Channel property of the Digitizer control.

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 a digitizer as an external analog synchronization signal renders that digitizer "occupied" and not available for allocating another digitizer. For example, when allocating a 3-tap RGB camera on acquisition paths 0, 1 and 2 (with the DeviceNumber property of the Digitizer control set to 0) you can set your external synchronization signal on acquisition path 3 (using the SyncChannel property set to digCh3). 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 (as customized in the DCF using Matrox Intellicam), a digitizer for monochrome camera could allocate and use 3 simultaneously.

Matrox Solios XCL

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

  • Single-Medium. The single-Medium version has only one acquisition path (the Digitizer control's DeviceNumber property must be set to 0) with only one data channel (digChannel0).
  • Dual-Base. The dual-Base version has two acquisition paths (the Digitizer control's DeviceNumber property must be set to 0 or 1), but each only has one channel (digChannel0).


Minimum latency and grabbing all frames

Previous | Next

When grabbing with either the Grab method or the MultipleBuffering.Process method of the Digitizer control, 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 image (either on-board or to the Host). This allows the image to be available for processing with a minimum amount of delay.

By default, Matrox Solios grabs into images located in off-board memory. When grabbing into off-board images, 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 the MultipleBuffering.Process method, use the NumberOfFrameMissed property. Use the NumberOfFrameProcessed property to determine the total number of frames grabbed in the sequence. Use the FrameRate property to return the estimate of the number of frames grabbed.


COM ports and UARTS

Previous | Next

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, ActiveMIL can control and access the serial ports (use the SerialPorts property of the System control). For more information, refer to the Matrox Solios Installation and Hardware Reference manual. To learn which UART is associated to which Microsoft Windows COM port, use the SerialPorts.Item(SerialPortIndex).COMPortNumber property.

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, PA and the transfer section is being used. This rate of utilization is expressed as a percentage.


User-defined signals for Matrox Solios

Previous | Next

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

ActiveMIL 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 these 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

When the digitizer's DeviceNumber property is set to 0 on Matrox Solios XCL, the relationship between the ActiveMIL user-defined signal numbers and the actual user-defined signals are as follows:

ActiveMIL 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²

When the digitizer's DeviceNumber property is set to 1 on Matrox Solios XCL, the relationship between the ActiveMIL user-defined signal numbers and the actual user-defined signals are as follows:

ActiveMIL 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 that shares this user-defined signal.

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

Analog

When the digitizer's DeviceNumber property is set to 0 on Matrox Solios XA, the relationship between the ActiveMIL user-defined signal numbers and the actual user-defined signals are as follows:

ActiveMIL 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 ActiveMIL user-defined signal numbers as a Matrox Solios XA when the Digitizer.DeviceNumber property is set to 0.

When the digitizer's DeviceNumber property is set to 1 on Matrox Solios XA, the relationship between the ActiveMIL user-defined signal numbers and the actual user-defined signals are as follows:

ActiveMIL 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¹ |  |  |

When the digitizer's DeviceNumber property is set to 2 on Matrox Solios XA, the relationship between the ActiveMIL user-defined signal numbers and the actual user-defined signals are as follows:

ActiveMIL 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¹ |  |  |

When the digitizer's DeviceNumber property is set to 3 on Matrox Solios XA, the relationship between the ActiveMIL user-defined signal numbers and the actual user-defined signals are as follows:

ActiveMIL 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 the others that share this user-defined signal.

Controlling or inquiring about user-defined signals

To control or inquire about user-defined signals on Matrox Solios, you use the UserBits property of the Digitizer control.

To use user-defined I/O (bi-directional) signals, you must set their mode to either input or output mode, using the UserBits.Item(UserBitIndex).Mode property or the UserBits.SetModeMask method.

You can set the state (on/off) of the user-defined output signals using the UserBits.Item(UserBitIndex).Value property or the UserBits.SetValueMask method. In addition, you can inquire about the state of the user-defined input and output signals using the UserBits.Item(UserBitIndex).Value property or the UserBits.GetValueMask method.

The mask version of the methods allow you to control or inquire about a group of user-defined signals. For example, to use the UserBits.SetValueMask method, pass the method a bit-encoded mask value that identifies which user-defined signals to affect, as well as a bit-encoded value that specifies the setting for each of these user-defined signals. The Mask parameter determines which user-defined signals will be affected. For example on Matrox Solios XCL, the value 45 would establish a mask that affects user-defined signals 0, 2, 3, and 5 since the binary equivalent of 45 is equal to 101101. Similarly, to use the UserBits.GetValueMask method, pass the method a bit-encoded mask value that identifies the user-defined signals about which to inquire. The method returns a bit-encoded value that specifies the setting for each of these user-defined signals.

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 event when there is a change in the state of a user-defined input signal:

  1. Enable the event, by setting the UserBitChangedEvent property to True.
  2. If bi-directional (I/O), set the user-defined signal to input mode as described above.
  3. Enable the interrupt state for the user-defined signal, by setting the UserBits.Item(UserBitIndex).InterruptEnabled property to True. The user-defined signal will generate an interrupt upon a rising edge.
  4. Set up a procedure to handle the Digitizer control's UserBitChanged event.

    5. The UserBitChanged event's UserBit parameter returns the user-defined signal(s) that generated the interrupt. Accordingly, in a series of case statements, specify the course of action for the appropriate user-defined signal.


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 folw of a Matrox Solios XA single analog.


Matrox 4Sight

Chapter 10: Matrox 4Sight

This chapter discusses features of ActiveMIL 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 port interface
      • Auxiliary I/O interface
  • Using ActiveMIL with Matrox 4Sight
  • User-defined signals for Matrox 4Sight
    • Matrox 4Sight-II user-defined signals
    • Matrox 4Sight-M user-defined signals
    • Controlling or 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

Next

The Matrox 4Sight family consists of two types of ActiveMIL-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 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 properties and methods in ActiveMIL. However, for more detailed information on the capabilities of each member of the Matrox 4Sight family, you should 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. These capabilities are controlled directly by ActiveMIL. For information on displaying images on an NTSC/PAL/RGB device, refer to the Types of display section in the Display chapter of the ActiveMIL user guide.

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 more information on the particularities with Matrox Meteor-II /1394, refer to IEEE 1394 serial bus-specific features and Grabbing from multiple 1394 cameras in the Matrox Meteor-II chapter of the Board Specific Notes.

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 ActiveMIL. 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 ActiveMIL.

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.

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

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 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-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 and a DVO port, and a connection to the integrated Chrontel 70009 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 similar to video in NTSC/PAL formats. This feature allows you to extend your Windows Desktop so that it spans across a second monitor. ActiveMIL can use the second CRT 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, Matrox Meteor-II /Digital, and Matrox Morphis PC/104-Plus frame grabbers.

Serial port 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 auxiliary 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 the User defined signals for Matrox 4Sight section, later in this chapter.


Using ActiveMIL with Matrox 4Sight

Previous | Next

ActiveMIL treats Matrox 4Sight-II as a normal computer. Accordingly, you only create System controls to specify which physical devices in the unit you need to access. For example, to use a Matrox Orion module for 4Sight-II or a Matrox Meteor-II frame grabber, create a System control, and set the System control's SystemDescriptor property to sysSystemOrion or sysSystemMeteorII.

To use 1394 DCAM-compliant cameras, create a System control and set its SystemDescriptor property to sysSystemMeteorII_1394. Then, assign a camera from the pool of 1394 cameras to the system, by allocating the camera as a digitizer on that system, using a Digitizer control and setting its OwnerSystem property to the name of your system. For more details, refer to IEEE 1394 serial bus-specific features.

To use the capabilities of the auxiliary I/O interface (user defined signals) on the Matrox 4Sight-II units, you need to create a System control and set its SystemDescriptor property to sysSystemHost. For more details on using the interface, refer to User-defined signals for Matrox 4Sight.

Note that when installing a redistribution (run-time) version of ActiveMIL 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.


User-defined signals for Matrox 4Sight

Previous | Next

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 ActiveMIL user-defined signal numbers and the actual user-defined signals on the auxiliary I/O connector and the opto-coupling module are as follows:

ActiveMIL 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 ActiveMIL user-defined signal numbers and the actual user-defined signals on the Auxiliary I/O connector are as follows:

ActiveMIL 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.

The previous 32 independent signals are used to connect TTL or non-TTL devices up to 24 V.

Controlling or inquiring about user-defined signals

To control or inquire about user-defined signals on Matrox 4Sight-II and Matrox 4Sight-M, you use methods of the System control; the System control must have its SystemDescriptor property set to sysSystemHost.

To use user-defined I/O (bi-directional) signals, you must set their mode to either input or output mode, using the ControlUserBits / ControlUserBitsWithMask method of the System control with sysUserBitMode.

You can set the state (on/off) of the user-defined output signals using the ControlUserBits / ControlUserBitsWithMask method with sysUserBitValueOut. In addition, you can inquire about the state of the user-defined input and output signals using the InquireUserBits / InquireUserBitsWithMask method with sysUserBitValueIn or sysUserBitValueOut, respectively.

The mask version of the methods allow you to control or inquire about a group of user-defined signals. To use the ControlUserBitsWithMask method, pass the method a bit-encoded mask value that identifies which user-defined signals to affect, as well as a bit-encoded value that specifies the setting for each of these user-defined signals. The Mask parameter determines which user-defined signals will be affected. For example on Matrox 4Sight-II, the value 45 would establish a mask that affects user-defined signals 0, 2, 3, and 5 since the binary equivalent of 45 is equal to 101101. Similarly, to use the InquireUserBitsWithMask method, pass the method a bit-encoded mask value that identifies the user-defined signals about which to inquire. The method returns a bit-encoded value that specifies the setting for each of these user-defined signals.

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 event when there is a change in the state of a user-defined input signal:

  1. In the BIOS, assign an interrupt line to the entire group of user-defined input signals. Refer to the appropriate Installation and Hardware Reference manual for more information on assigning an interrupt line to the user-defined I/O signals.
  2. Enable the event, using the UserBitChangedEvent property.
  3. If bi-directional (I/O), set the user-defined signal to input mode as described above.
  4. Specify whether the user-defined input signal should generate an interrupt upon a rising edge or falling edge, using the ControlUserBits method with sysUserBitInterruptMode set to either sysEdgeRising or sysEdgeFalling.
  5. Enable the interrupt state for the user-defined input signal, using the ControlUserBits method with sysUserBitInterruptState.
  6. Set up a procedure to handle the System control's UserBitChanged event.

    7. The UserBitChanged event's UserBit parameter returns the user-defined signal(s) that generated the interrupt. Accordingly, in a series of case statements, specify the course of action for the appropriate user-defined signal.


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 Matrox 4Sight-II.

Matrox 4Sight-M

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