2Structure of PLCnext Technology

Figure 2-1 PLCnext Technology is an open firmware platform executed on a Linux op­erating system with real-time patch. Different firmware components forming the core functions are called core components. These core components are a fixed part of the PLCnext Technology firmware. They cannot be mod­ified. The core components are divided into the following groups:


I/O components

Service components

System components


Figure 2-2 PLCnext Technology core components


The middleware section decouples the PLCnext Technology firmware platform from the op­erating system. The GDS (Global Data Space) is part of the middleware and forms a central component of PLCnext Technology. It enables consistent data exchange between different real-time components. You will find further information on the GDS in section GDS (Global Data Space).

I/O components /
fieldbus manager

The fieldbus manager connects the implemented fieldbus for the input and output of pro­cess data with PLCnext Technology. The following technologies are supported:

PROFINET controller


Axioline F master (local bus)

Service components

The service components provide access to the ESM (Execution and Synchronization Man­ager), GDS (Global Data Space) and to the following system components:

OPC UA server

Proficloud gateway

Web-based management

PC Worx Engineer HMI (HTML5 web visualization)

Accessible via OS






Trace controller

System components

All basic functions of PLCnext Technology are implemented in the system components.

System Manager and PLC Manager
These components load all other system components and monitor the stability of the system.

ESM (Execution and Synchronization Manager)
The ESM enables IEC 61131-3, C++ and MATLAB® Simulink® programs to be execut­ed in real time. Programming languages can be combined in any way for creating ap­plications. You will find further information on the ESM in section ESM (Execution and Synchronization Manager).

User Manager
The User Manager extends the standard Linux user management function. The various user roles are managed here. You can only execute operations in the PLCnext Technology firmware with a defined user role. You can select one or more user roles containing different permissions for each user.

ProConOS embedded CLR is the open IEC 61131 control runtime system for different automation tasks.

Real-time user programs

User programs are not supplied as standard with the PLCnext Technology firmware; these are created by the user. These user-defined programs can be created in both classic pro­gramming languages in accordance with IEC 61131-3, and also in C++ or Matlab® Sim­ulink®. It is also possible to combine different programming languages.
The easiest way to use PLCnext Technology is to create user programs in programming languages in accordance with IEC 61131-3, in C++ or using MATLAB® Simulink®, and to execute these in the real-time environment of the ESM. The user programs are downloaded to the controller and, after a cold restart of the device, executed by the firmware.

The IN and OUT ports of the GDS guarantee data consistency and ensure seamless data exchange between tasks and programs.


Figure 2-3 Task handling with ESM and GDS

Internal user components

With the modular and open PLCnext Technology control platform, users can add their own components – internal user components – to the system. The System Manager loads and monitors these internal user components (see section 2.1 “System Manager”). All available PLCnext Technology APIs can be used:

Remote Service Calls (RSC): each component (system, service, I/O components) fea­tures a selection of individual services that can be called up and used via RSC (see sec­tion RSC (Remote Service Calls)).

Component interface: the firmware calls up the implemented functions of the compo­nent interface at certain times, e.g. during program startup.

Data access: read and write access to the GDS (Global Data Space).

Common classes: easy retrieval of system functions, e.g. file operations, socket ser­vices, threading (see section Common classes).


Figure 2-4 PLCnext Technology – Internal user components

External user components

Internal user components are used to add new, internal functions. It can also be necessary to incorporate external processes. This may be the case if, for example, extensive software components such as Java® Frameworks or .Net Core® are used. External user compo­nents can be started in along with the PLCnext Technology framework. External user com­ponents are user-defined components without real-time requirements and independent startup behavior. They are not component parts of the PLCnext firmware and do not have a connection to PLCnext interfaces.


Figure 2-5 PLCnext Technology – External user component

2.1System Manager

PLCnext Technology is an open platform. This means that as a user you can integrate your own components and programs. During firmware startup, the System Manager ensures that all integrated components and programs are configured and started in the right order. Here, all system processes are generated and internal user components are supplemented. A system component is always started, shut down and configured by the System Manager.

2.2PLC Manager

The PLC Manager is a firmware component that loads the necessary PLC program code into the memory and boots up or shuts down the programs. The program code may consist of an IEC 61131-3 program that was created and sent using PC Worx Engineer or it can consist of code that has been created in C++ or MATLAB® Simulink®. C++ and MATLAB® Simulink® programs are available on the controller as program code libraries (shared object, *.so). Configuration files on the controller are used to determine which librar­ies the PLC Manager is to load and which programs in these libraries it is to instantiate. The PLC Manager is therefore superordinate to the code. It controls the boot up and shut down of the real-time system (ESM) as well as the stopping and starting of data exchange via fieldbuses. If the controller is in the “stop” state, the real-time tasks monitored by the ESM are not executed. The signals of the sensors connected to the fieldbus are no longer read as inputs, and the output signals are no longer sent to the connected actuators.

The controller can be started in three different modes.

Cold restart:
With a cold restart, all data is reset.

Warm restart: 
With a warm restart, all data is reset and all remanent data is restored (system start).
Note: In firmware version 1.x, remanent data is only located in the eCLR/IEC program­ming environment.

Hot restart: 
With a hot restart, the data is neither reset nor restored.

2.3Managing components

PLCnext Technology is based on components that are included via the “IComponentInter­face” interface (see section IComponent or ComponentBase).


Figure 2-6 PLCnext Technology components

Application Control

The Application Control Framework (ACF) is a part of the System Manager and manages the internal user components. The AFC is a framework that enables component-based plat­form development and the configurative composition of the firmware for the devices. It en­ables the dynamic and configurative integration of user functions into the system. The com­ponents managed by the ACF are thus firmware components and user components that are executed independently of the PLC program. The ACF generates the components when booting the firmware.
You will find further information on the ACF in section ACF (Application Component Framework).

PLC Manager /
Program Library Manager

One firmware component that is managed by the AFC is the PLC Manager (see PLC Manager). This manages the PLC program (real time). The associated components and libraries that are made available for these user programs are managed by the PLC Man­ager via the PLM (Program Library Manager). The configuration is executed with a file ref­erenced by /opt/plcnext/projects/Default/Plc/Plm/Plm.acf.config. The PLC manager gener­ates the components when loading the program.
You will find further information on the PLC Manager and Program Library Manager in sec­tions PLC Manager and IComponent or ComponentBase.

Delimitation ACF and PLM

ACF and PLM use the same ILibrary and IComponent interface (see section ILibrary or LibraryBase and IComponent or ComponentBase).

ACF and PLM use the same format for configuration files (see section Configuration files).

Only components that are managed via PLM can be made available for programs that can be instantiated in ESM tasks (IProgramProvider, see section IProgramComponent and IProgramProvider).

Only components that are managed via the PLM can be stopped, changed and started up via download from PC Worx Engineer. This is also the case for ESM tasks and the programs instantiated therein.

For components that are managed via the ACF, the firmware must be stopped, started or rebooted.

Components that are managed via the ACF are retained, even if the PLC program is shut down, deleted or booted.

2.4Configuration files

With PLCnext Technology, you can load programs and program instances onto the control­ler even without the PC Worx Engineer software. You can, for example, create a program in Eclipse® with C++ and transfer this directly onto the controller. All of the important and nec­essary settings can be configured directly in the controller in the configuration files. The file system of the controller is accessed via the SFTP protocol. Use a suitable SFTP client soft­ware for this, e.g. WinSCP. The configuration files are XML files. You can edit them using an editor of your choice. The configuration files are imported after the boot procedure of the PLCnext Technology firmware. If there are no configuration errors in the configuration files, the components and program instances are subsequently executed by the ESM.

When PC Worx Engineer is used, all configuration files are created by PC Worx Engineer and downloaded to the controller.

2.4.1acf, esm, gds


The acf.config configuration file contains information on the library instances, components and programs, as well as processes of shared objects (C++ programs).

The information is required by the ESM to load shared objects and to execute component instances or programs.

There are two possible components to instantiate:

Included in Default.acf.config (projects/Default/Default.acf.config)

Included in Plm.acf.config (projects/Plc/Plm/Plm.acf.config)


The esm.config file contains the task configuration, the instantiation of programs and as­signment to a processor core (one ESM per processor core). See section Configuring tasks via configuration files .


The gds.config configuration file contains the port definition as well as the assignment of IN and OUT ports. See section GDS configuration using configuration files.

2.4.2.tic file



Phoenix Contact recommends creating the .tic files with the PC Worx Engineer software.

The .tic configuration file contains information on the bus configuration with the associated I/O process data of the IN and OUT ports.


Metadata describes classes/types of components and programs that were created in a PLCnext Technology application.

The metafile for the library (*.libmeta) contains links to the metafiles for the incorporated components (*.compmeta). These, in turn, link to the metafiles of the connected programs (*.progmeta). The configuration of the GDS data ports (IN or OUT ports) is defined in the *.progmeta file. This configuration is required for using the program within the PLCnext Technology environment.
When the Eclipse® add-in creates the C++ project, the *.compmeta and *.libmeta metafiles are created automatically. However, you must modify the *.progmeta file, because the port definitions are performed here. The files are interlinked, as shown in Figure 2-7.



Figure 2-7 Overview of the metafiles

The LibraryBuilder combines the metadata and the code (*.so) into a library which is im­ported into PC Worx Engineer and which can be used as an IEC 61131-3 program. Tasks and the flow of data are configured directly in PC Worx Engineer. The Phoenix Contact add-in for Eclipse® generates the metafiles. However, you must add additional IN and OUT ports and programs manually.


Figure 2-8 Example of a component list and a shared object (*.so) in the *.libmeta file



Figure 2-9 Example of a program list in the *.compmeta file




Figure 2-10 Example of the definition of IN and OUT ports in the *.progmeta file

2.4.4Generating configuration files with PC Worx Engineer

The following description applies for all three *.config types (acf.config, esm.config, gds.config). The configuration files are automatically created when the PC Worx Engineer software is used. During the download, they are saved to the controller in the respective folder (e.g. /opt/plcnext/projects/PCWE/Esm for the PCWE.esm.config file) in the controller file system. This is intended for the download from PC Worx Engineer. The PCWE folder is automatically created and managed by PC Worx Engineer. Do not store any other files here, because PC Worx Engineer completely deletes this folder prior to the download. When the configuration in PC Worx Engineer changes and the project is once again down­loaded onto the controller, the previous configuration files are overwritten. Manual changes are thus also lost.

2.4.5Manual configuration

To make manual changes to the configuration files or to create new configuration files, you can copy the files generated by PC Worx Engineer and rename them. You can subse­quently perform your manual configuration in these files. To prevent the “PCWE” folder from being overwritten when the project is downloaded from PC Worx Engineer, create a new folder under /opt/plcnext/projects and save the files there (e.g. /opt/plcnext/projects/Exam­ple/). The folder can be used for saving additional configuration files and for the manual, configurative extension of the components.

Save your own configuration files in the controller file system.

Create a new folder for this purpose and name it accordingly. E.g. /opt/plcnext/projects/Example/.

Include the configuration files via an “Include path” command (see example Figure 2-12).

The “Include” mechanism is used to state which configuration files are to be used for the configuration. If files are to be included that are not in the folder used for inclusion, the re­spective path has to be specified. In the following example, all files that are in the same di­rectory as the “Default.gds.config” file are included, i.e. /opt/plcnext/projects/De­fault/Plc/GDS (<Include path=“*.gds.config” />). If you want to include all config files that are in the respective folder, add an * to the specific file name (e.g. *.gds.config). This results in all files with the same file extension being included.


Figure 2-11 Example: “Include path”

In the example, all GDS configuration files from the following directories are included in the configuration. “$ARP_PROJECTS_DIR$” is a PLCnext Technology environment variable with the value “/opt/plcnext”:

“Default”: /opt/plcnext/projects/Default/Plc/GDS (created by the firmware)

“PCWE”: /opt/plcnext/projects/PCWE/Plc/GDS (created by PC Worx Engineer)

“Example”: /opt/plcnext/projects/Example (created by the user)


Figure 2-12 Example: “Include path”


When editing configuration files, observe the information in sections Configuring tasks via configuration files  and GDS configuration using configuration files.

2.5ESM (Execution and Synchronization Manager)

In addition to the benefits of an open control platform, PLCnext Technology also features task handling. Until now, to benefit from the openness of the Linux operating system, func­tions such as real-time task handling, watchdog monitoring in the operating system, and process-internal communication had to be created with considerable effort by the user. The Execution and Synchronization Manager (ESM) takes over these tasks for the user. The de­veloper can now concentrate entirely on creating the application. Task handling, monitoring and the chronological sequencing of programs from different programming languages are now performed by the Execution and Synchronization Manager (ESM), one of the most im­portant PLCnext Technology components. Each processor core of a controller is managed by one ESM. One ESM is therefore assigned to one processor core. If a controller has more than one processor core, then there are also several ESMs (example: controller AXC F 2152: 2 processor cores and 2 ESMs).

The ESM features the following advantages:

Configuration and monitoring of cyclic tasks and idle tasks.

The execution times of the tasks are available as system variables and can be used for diagnostics.

System balancing.

Multicore systems are supported.

The ESM can also be used to execute programs and program parts in real time that were created in different programming environments. These can include high-level languages such as (C++), IEC 61131-3 code, and model-based tools such as MATLAB® Simulink®. Program parts that were created using different programming languages can also be com­bined and processed within a task. The EMS controls the processes and also enables the high-level language programs to be executed deterministically in the defined order. To en­sure data consistency between the tasks at all times, all data is synchronized with the GDS whenever a task is called up (see also section GDS (Global Data Space)).


Figure 2-13 Execution and Synchronization Manager

2.5.1Task configuration with PC Worx Engineer

You can use the PC Worx Engineer software to create and configure tasks conveniently. Here, the developer can proceed as in a classic IEC 61131-3 program. The IEC 61131-3 program, or the program created in a different programming environment and then imported into PC Worx Engineer, can be instantiated in a task. It does not matter whether the pro­grams were created with C/C++, IEC 61131-3 or MATLAB® Simulink®.

In the PC Worx Engineer “Tasks and Events” editor, you can instantiate a task and assign it to the desired program instances. A description of this procedure and further information on task handling with PC Worx Engineer is available in the online help, the PC Worx Engineer quick start guide (PC WORX ENGINEER 7, order no.: 1046008), and the AXC F 2152 con­troller user manual (order no.: 2404267). The documentation for the respective products is available for downloading at phoenixcontact.net/products. You can call up the online help from within PC Worx Engineer.


Figure 2-14 Example: Tasks and program instances in PC Worx Engineer

2.5.2Configuring tasks via configuration files



When a project is downloaded from PC Worx Engineer to the controller, the existing con­figuration files are overwritten with the new configuration files. Section Manual configuration describes how you can safely store your manually modified configuration on the controller file system, thus preventing the loss of data.

You can also modify the task configuration, the instantiation of programs and the assign­ment to a processor core (one ESM per processor core) without PC Worx Engineer via con­figuration files in XML format. All of the important settings can be configured directly in the configuration file on the controller. To modify the configuration manually, the XML file can be edited using any editor.


Figure 2-15 Example of a configuration file

To configure tasks for execution in the Execution and Synchronization Manager (ESM) using the *.esm.config configuration file, proceed as follows:

Defining a task

A task is defined between the tags <Tasks> and </Tasks>


Figure 2-16 Defining a task

Definition of the task starts with the task type.

Here, enter the type:

“CyclicTask” = Cyclic task

“IdleTask” = Idle task

Define the tasks using the attributes from the following table:




The “name” attribute defines the task name.

Enter the task name.

The name must be unique. It may only be used once per controller.


The “priority” attribute defines the task priority.

Enter a value to specify the task priority.

0: Highest priority

31: Lowest priority

32: Reserved for idle task


The “cycleTime” attribute defines the duration of the task (for cyclic tasks only).

Enter the value in nanoseconds.

The minimum value of the AXC F 2152 controller is 500000 ns = 500 µs


The watchdog monitors whether the task was executed within the specified time.

Enter the value in nanoseconds. The value “0” means that there is no monitoring.

The “watchdogTime” attribute can be used for cyclic and idle tasks.


Assigning a task

Once the task has been defined, it must be assigned to the desired ESM. The assignment is defined between the tags <EsmTaskRelations> and </EsmTaskRelations>.


Figure 2-17 Assigning a task to an ESM

Assign the task using the attributes from the following table:




The “esmName” attribute defines the name of the ESM to which the respective task is to be assigned.

Enter the task name.

Example: “ESM1” or “ESM2” for a controller with dual core proces­sor.


The “taskname” attribute defines the task to be assigned.

Enter the name of the task to be assigned.

Instantiating programs

Once the task is defined and assigned to an ESM, programs can be instantiated. Programs are defined between the tags <Programs> and </Programs>. The definition of a program in­stance is introduced with the tag <Program>. Programs that have been programmed in IEC 61131-3 can only be sent and configured with PC Worx Engineer. The figure originates from a config file generated with PC Worx Engineer.


Figure 2-18 Example: Instantiating programs

Instantiate programs using the attributes from the following table:




The “name” attribute defines the name of the program instance.

Enter the name of the program instance.

The name must be unique within the controller.


The “programType” attribute defines the program type.

Enter the program type.


The name of the component that contains the program is stored in the “componentName” attribute.

Enter the name of the component as it is defined in the *.acf.config configuration file. The “Arp.Plc.Eclr” component is reserved for IEC 61131-3 programs that were instantiated with PC Worx Engineer.

See section 4.3 “Creating a program”

Assigning program in­stances to a task

The program instances must be assigned to a task. The assignment is made between the tags <TaskProgramRelations> and </TaskProgramRelations>.


Figure 2-19 Assigning program instances to a task

Assign the program instance to a task using the attributes from the following table.




The “taskname” attribute specifies the name of the task to which the program instance is to be assigned.

Enter the name of the desired task to which the program in­stance is to be assigned.


The “programName” attribute defines the name of the program in­stance with the prefixed library and component names. The name is used to select the program instance to be processed in the task.

Enter the full name into the program instance to be processed.


The “order” attribute determines the order in which program in­stances are processed within a task, starting with 0.

Enter a number to determine the processing sequence.

The program instance with the digit 0 is processed first. Use a num­ber once only for each task.

2.6GDS (Global Data Space)

While tasks are being processed and data is being exchanged directly between tasks, read and write access can overlap due to different cycles and intervals. In the example in Figure 2-20, task 1 – with medium priority – begins processing and once completed outputs a value. This value is used by task 2 as an input value. Task 2 starts processing using this input value, and then the processing is interrupted by another start of task 1. Task 1 has a higher priority and is processed again, while task 2 is paused. At the end of processing, task 1 outputs a new value that is again sent to task 2 as an input value. Once task 1 is fin­ished, the processing of task 2 is continued. However, because the input value has changed in the meantime, there is a data inconsistency which may lead to problems.


Figure 2-20 Example of data inconsistency

PLCnext Technology is equipped with the Global Data Space (GDS) to ensure seamless processing during data exchange between user programs, fieldbus systems, and system programs. This is used as a central point for storing all data that is exchanged between the programs. All data is stored centrally in the GDS. The tasks refer to GDS variables that do not change while a task cycle is being processed. This means that at the beginning and during the ongoing execution of a task, the same value is available. This approach ensures that each task always uses consistent values.


With the GDS, it is easy to establish communication relationships between different pro­grams. This communication between the PLCnext Technology programs is realized via ports. A port presents an end point of a component within a PLCnext Technology applica­tion. Via a port, data can be exchanged with other components (e.g. program instances and I/O systems). To enable such a data exchange, the program variables to be exchanged or process data of the I/O components are defined as IN or OUT ports.
The data that is written from the tasks into the GDS is written via OUT ports. Tasks that re­ceive input data read this data from the GDS via IN ports. Using the ports ensures the con­sistency of data and functioning communication relationships at all times.


Figure 2-21 Inter-task communication with ESM and GDS

The IN and OUT ports are coupled via buffer mechanisms and synchronized during execu­tion.

Start of a task cycle (OnTaskExecuting): The IN ports are read from the GDS buffer storage units by the program instances to be called up in the task.

End of a task cycle (OnTaskExecuted): The OUT ports are written to the GDS buffer storage units by the program instances to be called up in the task.

Figure 2-22 “ Example: Port communication with task 1 buffer storage unit” shows the be­havior of task 1:


Figure 2-22 Example: Port communication with task 1 buffer storage unit

Data exchange for IN ports and OUT ports takes place at the beginning and at the end of each task execution. This only concerns the data exchange of IN and OUT ports whose pro­grams have been instantiated in different tasks. Ports within the same task are exchanged within the task. Furthermore, a data exchange is only implemented if the program instances are coupled via IN and OUT ports. This ensures that the data is stable and consistent during execution.
Figure 2-23 “ Example: Port communication with task 1 and task 2 buffer storage units” shows the behavior of task 1 and task 2:


Figure 2-23 Example: Port communication with task 1 and task 2 buffer storage units

In addition to the communication between different tasks, process data from and to field­buses is also exchanged via IN and OUT ports. Fieldbus systems also have buffer storage units, whereby these are arranged logically within the I/O component itself. Values are writ­ten to and read from these buffer storage units by the GDS. The fieldbus performs further handling.

Figure 2-24 “ Example: Fieldbus communication via IN and OUT ports” shows the behavior of the fieldbus communication via ports.


Figure 2-24 Example: Fieldbus communication via IN and OUT ports

The following applies to the connection of IN and OUT ports:

OUT ports can be shared within an application. One OUT port can be connected to sev­eral IN ports.

An IN port can only be connected to one OUT port.



You will find further information on connecting ports in the PC Worx Engineer online help (see “Role mapping: Assigning PLCnext ports”).

All components of a PLCnext Technology application that are part of the data exchange and I/O components must be connected via IN and OUT ports.

There are two methods of configuring the GDS:

With PC Worx Engineer

With configuration files

GDS configuration with PC Worx Engineer

Configure the GDS using the PC Worx Engineer software (see section 4.4 “Importing generated libraries into PC Worx Engineer”).

In the PC Worx Engineer editor, simply select the desired use as IN or OUT ports in the “Data List” of the node “PLCnext” for the respective process data. You can see an overview of all IN and OUT ports available in GDS in the “Data List” editor. The programs communi­cate via the IN and OUT ports of the GDS. Communication is also possible between IEC 61131-3 programs and programs that were created using other programming languages (e.g. C++). For this purpose, the IN and OUT ports must be assigned to one another.



IN and OUT ports are only displayed in the “Data List” editor of the “PLCnext” node.



Figure 2-25 Example: List of all available IN and OUT ports

You will find a detailed description of the procedure and additional information on GDS con­figuration with PC Worx Engineer in the online help, the PC Worx Engineer quick start guide (PC WORX ENGINEER 7, order no.: 1046008) and the AXC F 2152 controller user manual (order no.: 2404267). The documentation for the respective products are available for downloading at phoenixcontact.net/products.

GDS configuration using configuration files



When a project is downloaded from PC Worx Engineer to the controller, the previous con­figuration files are overwritten with the new configuration files. Section Manual configuration describes how you can safely store your manually modified configuration on the controller file system, thus preventing the loss of data.

You can also modify the GDS configuration without PC Worx Engineer, using configuration files. All of the important settings can be configured directly in the configuration file *.gds.config on the controller. All configuration files (except *.libmeta) are created by PC Worx Engineer. The configuration can be modified by editing the XML file with any edi­tor. You will find the file in the directory “/opt/plcnext/projects/.../Plc” of your controller (see Section 2.8.1 “Directories of the firmware components in the file system”). The file system is accessed via the SFTP protocol. Use a suitable SFTP client software for this, e.g. Win­SCP.

The individual connections with their respective IN and OUT ports are defined between the <Connectors> and </Connectors> tags. An OUT port is entered as a “startPort” attribute and an IN port as an “endPort”. Within the *.gds.config, each of the ports has its own unique name that has the following structure:

“ComponentInstanceName/GroupName: VariableName.”


Components of a PLCnext Technology application can be programs, PROFINET controllers (for instance Arp.Io.FbIo.PNControllerComponent), the IEC 61131-3 runtime (for instance Arp.Plc.Eclr.EclrComponent) and also a C++ application (for instance CppCounterCom­ponent).
Names that start with “Arp...” are specified by the PLCnext Technology firmware.
The names of the C++ applications are specified by the user during instantiation.
Exception: When instantiating C++ or MATLAB® Sim­ulink® programs in PC Worx Engineer, the name of the component instance is specified by PC Worx Engineer.

There can be one or multiple instances of each compo­nent.

In the case of a PROFINET device, it is possible to gain access by entering the product node ID (for more infor­mation, refer to the online help within PC Worx Engineer).

Enter the name of the instance here.


A local bus device is defined based on the position of the device in the local bus. The position numbering starts with the digit 0.

Enter this information instead of the GroupName.

With program instances, the name is specified.

Enter the name of the program instance.

Variable name

Enter the name of the IN and OUT ports or the pro­cess data here, depending on the component type.

There are various types of ports that can be used for data exchange. The port concept can be used with the following process data.


Code with example

Data of the runtime system of the controller

Enter the name of the program instance as the port and the variable name in the fol­lowing form. Global variables as well as IN and OUT ports can be used:
“runtime system/program instance: Variable name”
(e.g.: Arp.Plc.Eclr/MainInstance:OUT_PORT_A)

Data of a high-language project on the controller

Enter the name of the program instance as the port and the variable names in the fol­lowing form (in accordance with the form in the *.acf.config file):
“library name.component instance/program instance: variable name”
(e.g.: CppCounterLibrary.CppCounterComponent-1/CppCounterProgram1:IP_Cp­pEnable)

PROFINET process data

Enter the name of the PROFINET controller as the port and the process data names in the following form:
“PROFINET Controller/Node-ID: process data name”
(e.g.: Arp.Io.FbIo.PnC/46:~DI8)

Local bus process data

Enter the name of the local bus controller as the port and the process data names in the following form:
“Local bus controller/module position: process data name”
(e.g.: Arp.Io.FbIo.AxlC/0:~DO8)

Example excerpt from a GDS.config.xml file. Here, the IN and OUT ports of an application are assigned to each other.


Figure 2-26 Example *.gds.config

2.6.1Notes on designating GDS ports

When designating GDS ports, please observe the following conventions. Correct func­tioning can only be ensured if you adhere to the following specifications:

A designation

May not start with a number.

May not be empty.

Must consist of at least two characters.

May not exceed 128 characters.

May not contain spaces or tabulators.

May not start or end with “.”.

May contain “.”.

May start or end with “_”.

2.6.2Supported data types

The programs of a PLCnext Technology application communicate via IN ports and OUT ports. The combination of the following data types is supported.



When setting the IN and OUT ports with PC Worx Engineer, you can only enter permitted combinations of data types.
If you implement the configuration without PC Worx Engineer, but via the XML configura­tion file, you must ensure that only the data type combinations listed in Table 2-1 are used. If an invalid combination is configured, the startup process of the PLCnext Technology firmware is interrupted.
Information on the startup behavior of the firmware is available in the Output.log diagnos­tic file. The file contains status and error messages as well as warning notes that help you find the source of error. The Output.log file is stored in the controller file system in the “/opt/plcnext/logs” directory. The file system is accessed via the SFTP protocol. Use a suitable SFTP client software for this, e.g. WinSCP (see section Template Loggable).

Table 2-1Supported data type combinations of C++, Simulink® and PC Worx Engineer programs



PC Worx Engineer

Use in data type Array

Use in data type Struct












































































Array of primitive data types


*Only supported between C++ and C++ programs and between IEC 61131-3 and IEC 61131-3. Not between C++ and IEC 61131-3.

The following data type combinations between C++ programs are supported:

Table 2-2Supported combinations of IN and OUT ports between C++ programs

















































































2.7RSC (Remote Service Calls)

Internal user components can communicate with the PLCnext Technology core compo­nents via the RSC interface. You can access various functions and data items via the inter­faces. For example, you can gain read and write access to the GDS data using the “IData­AccessService” RSC service.


Figure 2-27 PLCnext Technology – RSC services

You have the option of using the already registered RSC services of the SDK (Software De­velopment Kit) via the ServiceManager. The ServiceManager acts as the RSC API and is used to request services. Embed the “ServiceManager” class into the header file via the “#include” command.


Figure 2-28 Example header file: #include ServiceManager.hpp

Request a service instance via the “SubscribeServices” command. With the “GetService” method, you can define the interface that you want to use. An RSC service is called up by the ServiceManager as follows:


Figure 2-29 Example: Calling up an RSC service



Please note that the execution of RSC services can take up a large amount of time (in par­ticular Axioline and PROFINET services). For this reason, avoid direct call up from ESM tasks.

RSC services are available for the following areas. You will find more detailed descriptions in the sections specified:

Axioline services: Read and write access to data and information from Axioline devices (see section RSC Axioline services)

PROFINET services: Read and write access to data and information from PROFINET devices (see section RSC PROFINET services)

Device interface services: Access to information and properties of the operating system and controller hardware (see section RSC Device Interface services)

GDS services: Read and write access to the GDS data (see section RSC GDS services)

2.8Operating system

The PLCnext Technology control platform is based on a Linux operating system with real-time patch. Linux is a highly reliable open source operating system suitable for applications that require a high stability. A wide range of open source software is available for the Linux operating system, which is supported by a large community of users and developers. You can also use this open software, software blocks, and technologies for your PLC applica­tions (e.g. SQL server). PLCnext Technology uses this operating system and extends it by the functions of a PLC such as the cyclic processing of tasks and cycle-consistent data ex­change. Core changes or extensions are not possible. To add functions to the system, the user must compile and, if necessary, execute installations with “root” rights.

The operating system features the following components and services:







2.8.1Directories of the firmware components in the file system

PLCnext Technology controllers work with a Linux operating system. You can access the controller via SFTP or via SSH, view the directories and files on the file system (on the inter­nal parameterization memory and on the SD card), and modify them if necessary. Directo­ries and files that are provided by Phoenix Contact (also through firmware updates) are stored on the internal parameterization memory of the controller. Settings that you have configured yourself (e.g. network configuration, project bus configuration, PC Worx Engineer project, etc.) are stored as directories and files on the SD card. Directo­ries and files that you modify on the internal parameterization memory are stored on the SD card. The Linux operating system generates an overlay filesystem on the SD card from the directories changed on the internal parameterization memory and files.

Table 2-3Storage of the FW components in the root file system

Directory in the root file system



Directory for storing additional open source librar­ies that are used by customized C++ programs.

You will find further information on programming the AXC F 2152 with C++ in the PLCnext Com­munity at plcnext-community.net


License information for the individual Linux pack­ages of the AXC F 2152


Home directory of the Linux user “admin” and working directory of the device firmware

Files written by the application program are stored in this directory if the specified file name does not contain a memory path.


Log files of the diagnostic logger
You will find the Output.log file here. This con­tains information on the startup behavior of the firmware, status and error messages as well as warning notes that help you find the source of er­ror.


Directory for storing PC Worx Engineer projects.
All files and subdirectories in this directory are managed exclusively by PC Worx Engineer.

Do not make any changes to this directory.

Using SFTP to access the file system

The file system is accessed via the SFTP protocol. SFTP client software is required for this (e.g. WinSCP).

Access to the file system via SFTP requires authentication with a user name and password. The following access data is set by default with administrator rights:

User name: admin
Password: Printed on the controller.




The firewall is deactivated by default.


Activate the firewall

Please note:

If you use the AXC F 2152 as a PROFINET controller, you must authorize all incoming connections via all UDP ports if the firewall is enabled. Otherwise, establishing a connec­tion to certain PROFINET devices is not possible.

The firewall of the PLCnext Technology controller is based on internal Linux mechanisms (network filters) and is configured in the shell using nftables. Access is via SSH (Secure Shell).

Access via SSH requires authentication with a user name and password.



Please note:

Authentication with user name and password is always required for SSH access and can­not be deactivated.

Administrator rights are required for SSH access.

The following access data is set by default with administrator rights:

User name: admin
Password: Printed on the controller.

You can control the firewall with the following shell commands:

Table 2-4Shell commands for controlling the firewall

Shell command


sudo /etc/init.d/firewall start

Temporarily activates firewall

This setting is no longer active after a re­start.

sudo /etc/init.d/firewall stop

Temporarily deactivates firewall

This setting is no longer active after a re­start.

sudo /etc/init.d/firewall activate

Permanently activates firewall

The firewall remains activated even after the AXC F 2152 is restarted.

sudo /etc/init.d/firewall deactivate

Permanently deactivates firewall

The firewall remains deactivated even after a restart of the AXC F 2152.

The following controller firewall rules are stored in the “plcnext-filter” file in the /etc/nftables upon delivery:

Permitted packets/connections

Blocked packets/connections

Outgoing ICMP echo requests and the as­sociated ICMP echo replies

Ping commands can be issued by the con­troller.

Incoming ICMP echo requests

The controller cannot be reached using a ping command.

Incoming connections via SSH (port 22)
(e.g. for SSH or SFTP connection)

All incoming connections via TCP ports (ex­cept for explicitly approved ports, see left column of table)

Incoming HTTPS connections (port 443)

Access to the web server
(PC Worx Engineer HMI and WBM)

All incoming connections via UDP ports

Incoming connections via HTTP (port 80)

The connections are diverted directly to port 443.


Incoming connections via TCP port 41100

Common remoting (TLS-encoded), e.g. via PC Worx Engineer


Incoming connections via TCP port 17725

The TCP port 17725 is the standard port for the external mode of MATLAB® Simulink®.


Incoming connections via TCP port 4840

Standard port for connections to the OPC UA server of the controller


Incoming connections via any TCP and UDP port


2.8.3NTP (Network Time Protocol)


An ntpd (Network Time Protocol daemon) is included in the operating system for time syn­chronization. It is possible to connect to other NTP servers or to start your own server.


The NTP service from ntp.org (Network Time Protocol Project) is integrated into the operat­ing system. This service can be configured via the /etc/ntp.conf configuration file. As an admin user, you have sufficient rights to modify the data. The changes are adopted after re­starting the ntpd. Execute the script “sudo /etc/init.d/ntpd” and the changes made in the con­figuration file will be active after the next controller boot up.

In the standard configuration, the operating system time is synchronized with the RTC (Real-Time Clock) installed in the hardware.
You have the option of specifying IP addresses and names in the configuration.


You will find a general introduction to the Network Time Protocol (NTP) Demon at https://www.eecis.udel.edu/~mills/ntp/html/ntpd.html.

You will find a detailed description of the configuration options at

Changing the system time manually

As an alternative to synchronization with an NTP server, you can also change the system time manually via the shell. Authentication with user name and password is necessary for access with PC Worx Engineer and SSH access to the shell. The following access data is set by default with administrator rights:

User name: admin
Password: Printed on the controller.

Open the shell.

Requesting the system time

Request the system time via the “date” command.

Setting the system time

Enter the shell command “sudo date -s “YYYY-MM-DD hh:mm:ss”.

YYYY: Year

MM: Month

TT: Day

hh: Hours

mm: Minutes

ss: Seconds

Setting the system time in PC Worx Engineer

You can also set the system time using the PC Worx Engineer software.

Click on the “PLCnext” node in the “PLANT” area.

Select the “Online Parameters” editor.

Enter the desired values for the date and time in the corresponding input fields.


Figure 2-30 Setting the system time in PC Worx Engineer

2.8.4OpenVPN™ client

With the OpenVPN™ software, you have the option of establishing a virtual private network (VPN) and therefore a secure connection via an unsecured network. The data is encrypted with suitable protocols.

You will find a description on how to set up a VPN tunnel using openVPN™ in the PLCnext Community at plcnext-community.net.

2.8.5IPsec (StrongSwan)

IPsec is an encryption and authentication protocol with which VPN connections (Virtual Pri­vate Networks) can be established. StrongSwan is an implementation of the IKE (Internet Key Exchange) protocol and can be used for VPN connections via IPsec.

You will find further details at http://www.strongswan.org.

AXC F 2152 configuration notes

You can edit the /etc/ipsec.conf configuration file with admin user rights.

Use the following commands for starting, stopping and restarting the demon:

Start: “sudo ipsec start”

Stop: “sudo ipsec stop”

Restart: “sudo ipsec restart”

Use the following command to call up the status: “sudo ipsec status”

Configuration examples

You will find configuration examples at https://wiki.strongswan.org.

2.8.6Text editors

“Nano” and “Vim” are installed on the controller as text editors. When you are connected to the controller via SSH console, you can call up the desired editor via the command line. To do so, enter “nano <file name>” or “vim <file name>”.


The “Nano” text editor is easy to use and is therefore recommended for inexperienced us­ers.


The “Vim” text editor has an extended range of functions and is a popular editor in the Linux environment.

2.8.7User rights

When a PLCnext user logs into the SSH console with the “admin” user role, he is also rec­ognized with the same name and password by the Linux system. The user is thus assigned to the “plcnext” Linux group. Files that this user may read, write to and/or execute are as­signed to the “plcnext” group file system.

Executing Linux commands that require higher rights is made possible for the users via sudo. Which Linux commands the PLCnext users are allowed to execute via sudo is config­ured in the Linux system.

The following rights are possible:

Table 2-5User rights


PLCnext group


sudo required

Setting and inspecting IP settings (incl. ifconfig, ping, netstat etc.)



x (ifconfig)

Configuring the firewall




Starting/stopping the firewall (init script)




Inspecting the firewall with nft




Configuring VPN (IPsec and OpenVPN™)




Starting/stopping VPN services (IPsec and OpenVPN™)




Editing the “Default” PLCnext folder for individual ACF, ESM, GDS configurations, and *.so




Starting/stopping the PLCnext Technology firmware processes




Reading PLCnext log files




Calling up and configuring TOP/HTOP




Updating firmware (via RAUC)




Updating firmware via update script




Configuring the NTP server




Setting the root password with “passwd”




Requesting the system time with “date”




Setting the system time with “sudo date -s”




Restarting/shutting down the controller with “reboot” or “shutdown”




Write access to /opt/plcnext and /opt/plcnext/projects




Recording network traces with “tcpdump”




Starting the gdbserver with root rights
(see also PLCnext Community)