Structure of a C++ program

PLCnext Technology follows an object-oriented approach.  The following base classes are relevant for creating a C++ program running on a PLCnext Control. Depending on the functional needs, such a program can be integrated as either ACF component or PLM component.

Library LibraryBase class The LibraryBase class is the smallest unit that can be downloaded. It represents an *.so file (shared object). One library can instantiate one or more components.
Component ComponentBase class The ComponentBase class is a collection of functions (programs) within the PLCnext Technology platform.
One component can instantiate one or more programs. The program instances can interact via their shared component instance.
Program ProgramBase class With PLCnext Technology, instances of the ProgramBase class can be performed in real time.
Here, the IN and OUT ports are published. Programs are only applicable for PLM components.

The base classes are stored in the Phoenix Contact SDK. Derive from these base classes to create your application. 

  • If you want to consult the PLCnext Technology SDK C++ header files in parallel while reading this section, first install the necessary tools as described in Required Installations.
  • Sample applications programmed in C++ can be found at

ILibrary and LibraryBase

Using the PLCnext CLI the toolchain generates the corresponding library object as well as the main entry function of the shared object (*.so).

In a shared object, there can be exactly one library class (singleton pattern). The PLCnext Technology firmware initializes the *.so after it has been loaded by calling the following function:

extern "C" ARP_CXX_SYMBOL_EXPORT ILibrary& ArpDynamicLibraryMain(AppDomain& appDomain);

This function is implemented in such a way that the library class is created and returned as an interface. The library object implements the ILibrary interface by means of derivation from the LibraryBase class. ILibrary is defined in header Arp/System/Acf/ILibrary.hpp, and LibraryBase in Arp/System/Acf/LibraryBase.hpp. The LibraryBase class especially implements a ComponentFactory with the IComponentFactory interface. The PLCnext Technology firmware can thus create instances of the components when loading the PLC program.

The library class also has to implement the IMetaLibrary interface (#include "Arp/Plc/Commons/Meta/IMetaLibrary.hpp") for the PLCnext Technology firmware to be able to determine the necessary information (names of components and program types, program ports).

This interface then requires the implementation of the ITypeInfoProvider interface (#include "Arp/Plc/Commons/Meta/TypeInfoProvider.hpp"), whereby the firmware learns the names of the components and program types as well as their IN and OUT ports.

The MetaLibraryBase (#include "Arp/Plc/Commons/Meta/MetaLibraryBase.hpp") therefore expands the LibraryBase class by these interfaces.

The component instances the PLCnext Technology firmware creates are defined in the *.acf.config and *.plm.config files.

AppDomain and IApplication

If you use the Eclipse® add-in the required header files are included automatically.

  • AppDomain: Arp/System/Core/AppDomain.hpp
  • IApplication: Arp/System/Acf/IApplication.hpp

The PLCnext Technology firmware is distributed among several operating system processes.


An AppDomain represents such an operating system process. If a library is to be used in several processes, singleton implementation is performed for each process. The AppDomain class is used for this. Since the PLCnext Technology firmware uses the same mechanism for instantiation, initialization and administration of user components as it does for core components, the AppDomain is also used here.


The operating system process is represented by the IApplication interface.

IComponent and ComponentBase

Within on library there can exist on or more components. The component object implements the IComponent interface by means of derivation from the ComponentBase class. For more details see IComponent and ComponentBase.

Several component types in the same library

Using the PLCnext CLI,  the Eclipse® add-in, or the Visual Studio® extension, during compiling the metadata configuration files (*.libmeta, *.compmeta, *.progmeta) required for PLCnext Engineer are created. Also, the functions described in this segment are created with a functional implementation. If you have special requirements that go beyond this, the following descriptions will help you understand the functions.

Initially, the toolchain creates exactly one component type in a library. If several component types are to be instantiated in the same library, each component type must be added to the factory. To this end, every component type is introduced to the factory by calling the AddFactoryMethod() function in the constructor of the library object. The PLCnext CLI generates the required code if the //#component directive is prefixed in the header of the class definition:

class SampleComponent : public ComponentBase,

There are two ways to instantiate components:

  • "Function Extensions", managed by the ACF, are instantiated through the *.acf.config file 
    (find it in /opt/plcnext/projects/Default/*.acf.config).
  • "User Programs", managed by the PLM, are instantiated through the *.plm.config file
    (find it in /opt/plcnext/projects/Default/Plc/Plm/*.plm.config).
    When used as PLCnext Engineer library, this is performed automatically by PLCnext Engineer, but it can also be done manually.
Note: There may be several components in a library, but they must all be either a "Function Extension" (based on the ACF) or a "User Program" (based on the PLM). Mixing these types in a library is not possible.




• Published/reviewed: 2024-05-06   ★  Revision 068 •