---
title: "milInterface: a Matrox frame grabber in LabVIEW"
description: "A small C++ DLL that lets LabVIEW grab image sequences from a camera through a Matrox frame grabber."
date: 2021-05-24T01:32:34+02:00
lastmod: 2026-10-16T18:58:52+02:00
url: https://klimek.link/projects/milinterface/
author: "Marcin Klimek"
source: https://klimek.link/projects/milinterface/
---

# milInterface: a Matrox frame grabber in LabVIEW

LabVIEW is good at instrument control, but to talk to a **Matrox** frame grabber you have to use the **Matrox Imaging Library (MIL)** from C. I wrote **milInterface** to sit in between, as a thin C++ DLL. LabVIEW calls a handful of plain C functions, and the DLL does all of the MIL work.

## The interface

| Function | What it does |
|---|---|
| `initialize(dcf_path, max_frames)` | Starts MIL, opens the frame grabber with a camera configuration file (DCF) and allocates a ring of image buffers |
| `start(n)` | Starts an asynchronous grab of `n` frames |
| `is_grabbing()`, `get_num_grabbed()` | Let LabVIEW poll the progress without blocking |
| `get_frame_size()` | Size of one frame in bytes, so LabVIEW can allocate its array |
| `get(frame, buffer, size)` | Copies one grabbed frame into a LabVIEW array (8- or 16-bit pixels) |
| `destroy()` | Frees everything |

The grab runs asynchronously (`MdigGrab` and `MdigGrabWait` into the buffer ring), which keeps LabVIEW responsive while frames arrive, and frames get copied into LabVIEW memory only when LabVIEW asks for them. I gave every MIL allocation step a separate error code, so problems with a misconfigured camera are easy to diagnose from the LabVIEW side.

*Diagram: Asynchronous grab into a ring of buffers, copied out on request*

To check the camera and the configuration outside LabVIEW, the repository also has LabVIEW test VIs and Python scripts that use the MIL Python bindings.

[Source on GitHub](https://github.com/marcinklimek/milInterface).

Source: https://klimek.link/projects/milinterface/
