Mandatory allocations: allocating an application context and its systems

See also

User Guide:

Distributed MIL

Reference:

MappAlloc MappAllocDefault MappFree MbufAlloc2d MdigAlloc MdispAlloc MsysAlloc MsysFree

Availability

Available in MIL-Lite

Available in MIL

At the beginning of each application, you must:

Allocate a MIL application context using MappAlloc(). This initializes the MIL library.
Allocate a MIL system using MsysAlloc(). A MIL system typically represents a group of hardware resources capable of grabbing, storing, processing, and/or displaying images.

At the end of each application, free each system using MsysFree(), and then free the application context using MappFree().

MIL application context

A MIL application context is a data structure (specifically a MIL object) populated with the information needed to run a MIL application. You must allocate a MIL application context before calling any other MIL function (using MappAlloc() or MappAllocDefault()). Upon allocating a MIL application context, it is initialized with the information required by the MIL library. This initialization determines the type of CPU and CPU cores available, the licenses available which depend on the version of MIL installed, and the files/functions available based on the licenses. Furthermore, it sets up a MIL identification table that will hold the identifiers of all MIL objects. It initializes how errors are displayed (MappAlloc() with M_QUIET to suppress the display of error messages), and initializes and controls the creation of trace logs (MappAlloc() with M_TRACE_LOG_DISABLE to disable the creation of trace logs).

MIL system

A MIL system is a MIL object that represents a group of hardware resources that MIL can access and use. You must allocate at least one MIL system, using MsysAlloc() or MappAllocDefault(). Upon allocating a MIL system, MIL gathers information about the specified hardware and opens communication between your MIL application and the appropriate hardware drivers. Once communication has been established, you can allocate and then use the system's hardware resources. Hardware resources might include memory (MbufAlloc...()), display (MdispAlloc()), and digitizers (MdigAlloc()).

See the MsysAlloc() function reference and the MIL Hardware-specific Notes for the list of supported MIL systems and the hardware resources that they require.

Categories of MIL systems

MIL systems can be divided into three general categories with different capabilities: the Host system (which does not require specific hardware), acquisition-type systems (which provide access to image grabbing hardware), and non-acquisition-type systems (which provide access to Matrox hardware that only has non-image-grabbing functionality, such as I/O signaling).

The following table summarizes which MIL systems fall into each category, what capabilities they have, and what specific hardware they require. MIL systems that support processing usually use the Host CPU and memory.

Category of MIL Systems		Processing/display	Grabbing	Specific hardware requirements
Host system		Yes	Simulated using images from files	No
Acquisition-type system		Yes	Yes	Yes
	Matrox frame grabber-specifc system (for example, MIL Rapixo CXP system)			Specific Matrox frame grabber (for example, Matrox Rapixo CXP)
	MIL GigE Vision system			Gigabit Ethernet port (or faster)
	MIL USB3 Vision system			USB 3.0 port
	MIL GenTL Consumer system		Depends on GenTL Producer	Device that is a GenTL Producer
Non-acquisition-type system		No	No	Yes
	MIL Indio system			Matrox Indio
	MIL Concord PoE system			Matrox Concord PoE

Typically, a single system represents a single board in your computer (and some Host hardware resources). However, a few types of MIL systems represent all boards (hardware components) of that specific type in a computer. For example, a single MIL GigE Vision system represents all GigE Vision adapters in your computer. This means that once you allocate a MIL GigE Vision system, you can allocate and grab from any connected GigE Vision camera (or other device). Additionally, different functionality on one board might require the allocation of multiple different types of MIL systems. For example, to use the functionality of a Matrox Indio board, you allocate a MIL GigE Vision system to access and grab images from a GigE Vision camera (or other device), and you allocate a MIL Indio system to use all other functionality on the board (for example, the auxiliary I/O signals). For information, refer to the MIL Hardware-specific Notes for your particular hardware.

Multiple systems

You can allocate more than one system per application context and then use their identifiers to access their hardware resources. All currently supported MIL systems also support multi-processing. This means that the same board can be allocated by more than one process simultaneously; CPU and memory resources will be split between each process as needed. However, many resources (such as individual digitizers on some boards) cannot be allocated by more than one process simultaneously. Refer to the MIL Hardware-specific Notes for your particular hardware to determine which resources cannot be allocated by more than one process simultaneously.

Processing can be done using the resources of the different systems within a single process. Any operation involving more than one system will be performed by the most appropriate one. By default, if none of these systems is more appropriate than the Host, the Host is used to perform the operation.

Remote systems

During MIL system allocation, you can specify that the hardware resources are on a remote computer. This allocates a remote MIL system, which makes the resources of the specified computer available: its specified Matrox imaging board (or third-party hardware), its CPU, and its memory. Both the local and remote computers must have MIL/MIL-Lite installed with the Distributed MIL option.

A MIL application that uses remote MIL systems is called a Distributed MIL controlling application, and the remote MIL systems are called DMIL remote systems. In a Distributed MIL controlling application, multiple DMIL remote systems can collaborate with each other and with local MIL systems across a network (for example, a local area network, or a wide area network such as the internet) controlled by a single MIL application. A group of computers interacting using Distributed MIL is called a cluster.

When developing a Distributed MIL controlling application that uses functionality only available in the full version of MIL, the local computer requires a MIL development license; the remote computer(s) only require appropriate runtime licenses for Distributed MIL and the MIL modules that they actually use. When only running such an application, all computers in the cluster require appropriate runtime licenses for Distributed MIL and the MIL modules that they actually use; sending a command to another computer is not using a module so no specific license is needed in this case.

When developing or running a Distributed MIL application that uses only MIL-Lite functionality, the local and remote computers require a Distributed MIL supplemental license.

For more information on Distributed MIL, see Chapter 48: Distributed MIL.