What is a module
You can extend the functionality of openBEB by plug-ins. Plug-ins can add functionality to openBEB by two ways:
- By overwrite functions.
- By modules: Every plug-in can provide an arbitrary number of modules. The CORE program itself is a module.
Modules are program pieces that can be accessed by the macro language. Technically, they are queued state-machines of specific structure.
Structure of a module
Note that the module programming is significantly improved in 2.81 (BETA). This documentation will be adjusted during the next days.
The following components must be present on a queued state machine to classify as a module:
- Queue named with the moduleName and string as data-type.
- A semaphore with the same name as the module.
This is automatically created using the standard commands from the ApplicationSupport classes. You can also use the ModuleTemplate.vi:
A typical module looks like the following:
Note, that you should display the label of the case structure for the module commands (here labelled "commands"). Furthermore, SubDiagram labels must be activated.
Documentation of module commands
You should document every command in the module. To this end run the vi HelperEditModuleHelp.vi:
- Edit: To edit a command, First select the case structure, then press edit. A dialogue window is displayed, you can now edit the command help.
- Export: Writes down a help-cache file. This file you should export with plug-in. Note, that in the run-time environment this cache file is used. In the development environment, the help information is assembled from the source code.
- Stop: Stops the helper VI.
In order to classify as a module, the state machine must support certain commands:
Note, that different sets of commands must be present depending on the functionality.
These commands must always be present in every module.
The rendezvous command is used for the synchronization of parallel running tasks and must be always present. Include CBASMacroRendezVous.vi
For error handling, see this page.