Libraries and blocks

Generated projects may serve as a structure block library. Similar to function block libraries, projects may be loaded, removed and replaced, too. Whenever projects are linked, also the relating libraries (if not yet loaded) are opened and relevant references are stored in the project.

Additionally loaded structure blocks are displayed in the library tree. All macro and program blocks contained are indicated under the name of the project.

These blocks are basically handled as function blocks. When a project is edited, only calls can be inserted and connected with other blocks. Changing of structure blocks is not possible. To initialize instance parameters, preset values stored in the linked project are used. However, parameters can be changed in run mode.

The export and import of structure blocks offers another way to reuse existing algorithms. There the hierarchical structures are directly inserted into the project. After that they can be edited and used without reservations and dependence to other projects.

System libraries do not contain any blocks; they just contain functions, such as functions for drawing blocks, interrogating system states and performing actions. They are used by function block libraries and, usually, are not visible when working on the project.

By means of the switch REMOVE SYSLIB=ON in the [SYSTEM] section of the main configuration file (ICON.INI) they can be made visible when libraries are removed. Thus, system libraries which are no longer used can be deleted from the project.

Libraries are searched for file names during loading in the directory of the project and in the selected library directories. Library directories are defined in the configuration file of the project (*.IWS) or in the main configuration file (ICON.INI).

If a library is contained several times in the selected directories, the file found first is loaded.

If a library is not found when a project is loaded, or if it is damaged, loading is cancelled. Then, the project cannot be opened as the complete functionality of the block, such as representation, target code generation and response to certain system events are implemented in the library. For the very same reason, version conflicts may have a similarly strong impact. Interpretation of data in changed libraries may be different or block functions may respond to system events in a different way. Hence, library versions should be identifiable from their names and must only be exchanged by using the command provided to this end.

As already described, there are dependencies between libraries. Such dependencies can be displayed by using the Properties command (refer to the library tree). When a library is loaded, also all other connected libraries are loaded. While a library is used by other libraries, this specific library cannot be deleted or replaced. To this end, the dependency on other libraries must be excluded by deleting or changing the other relevant library.

Recursive dependencies between projects, i.e. loading of a project into another one and vice versa, are not permitted.

The displayed designation and the real file names of libraries do not correspond to each other. Displayed designations can be changed by using commands in the context menus for blocks and libraries in the library tree. They are stored in the configuration files. Dialogs for library operations show the real file names apart from designations.

The file names of libraries and additionally loaded project should not exceed eight characters. The file name stored in the project is restricted to the 8+3 limit known from MS-DOS. If libraries have longer file names, abbreviated names are created by system functions which might be ambiguous if there is more than one directory.

The file names of projects and libraries must not be changed via external programs (such as Windows-Explorer). To rename projects, the Save As command needs to be used. For changing the file name of a function block library, iCon-MFB is required.