Skip to end of metadata
Go to start of metadata

Plug-in types and class hierarchy

openBEB plug-ins are dynamically loaded during start-up. The must be a child-class of the the CORE plugin-manager. The hierarchy of an importer plug-in is shown below:

openBEB knows different types of plug-ins. A table and description can be found here.

Note, that some plug-ins depend on each other and build "plug-in families". For example, ViewportType plug-ins provide a datatype definition. Importers depend on this type definition, since the CORE program itself is data-agnostic. The same is true for viewports. Viewports are used for data visualisation, and therefore also depend on the type definition. Note, that a ViewportType can have several viewports as child.

Structure of a plug-in family:

  • ViewportType: data type definition.
    • Importers: Imports a specifific file type compatible with the type definition.
    • Viewports: data visualisation.
    • (Libraries): Can, but must not depend on a type definition.

Plug-in load order

Plug-in families are hierarchical and importers and viewports depend on a data-type definition. Other plug-ins can be dependent on libraries. Plug-ins are loaded in following order:

  1. ViewportTypes
  2. Libraries
  3. "Plug-ins": All other plug-ins.

This is reflected by the folder hierarchy of exported plug-ins, as shown in the screen-shot below:

Plug-in projects file and export of plug-ins

The LabView projects file assemblies the source code and also contains compile instructions. It is a local file and does not belong under version control, however, most plug-ins contain a template project. This template should be copied into place without version control. and relinked.

A typical project file of an importer plug-in is shown below:

The CORE-class is included (1). Since it is an importer plug-in, it depends on a type definition (2). The actual plug-in (3) contains on a "plugin.ini" file. This file contains loading information for the plug-in and is read by the core program before loading. Every plug-in must provide a set of override functions, which are called by the CORE program during execution (4). To be loaded into openBEB, the plug-in must be exported as "source code" into the openBEB extension folder (5).

Typical export instructions are shown below. Note, currently the vi.lib libraries are included in the export. This might change in the future, however, included libraries are name-space protected and backwards compatibility will be maintained.

Build options to export plug-ins. (A) General setting. The plug-ins are exported in their own sub-folder of the extension-folder (1). (B) In the source file panel, select all files which must be exported. Note, that the plug-ini file is included (2). The COREclasses library and the ViewportType definition library must be excluded (3). (C) In the additional exclusion library, select ''Remove unused members''. Do not select ''exclude files from vi.lib'' (4). They are not installed along with the runtime library. 

opeBEB DevCenter

Exporting and/or compiling many plug-ins is very time consuming. Therefore, a openBEB DevCenter is provided here. This vi allows batch compilation of different plug-ins and also provides a graphical user interface for the maintenance of the plugin.ini files.

Programming plug-ins

Plug-ins are programmed in object oriented G. See the following pages:

LabView provides a very rich environment for data-acquisition, data-processing and data-visualization. The openBEB CORE provides house-keeping facilities, and all data specific tasks are provided by plug-ins.


To start programming plug-ins, it's best to start with templates.


Note, that you can provide modules in a plug-in. These modules can be addressed by the macro-language used to coordinate modules and plug-ins. Modules must follow certain rules as outlined here.

Note, that the CORE program interacts with plug-ins via standard override functions, macros via text based modules.


  • No labels
Write a comment…