Application-relevant changes 2025:
Changes of miscellaneous features

Logging

Logging API

The logging substruction was refactored completely.

Nevertheless, the public API did not change, except of the following:

• The static logging implementation using macros was removed because it was not used.
• The logging implementation using streams was removed because it was not used.
• Static class Log was moved (see next section).

Static class "Log" (root logger)

The static class Log from namespace Arp::System::Commons::Diagnostics::Logging was moved to library Arp.Base.Commons into namespace Arp::Base::Commons::Logging.

The new include path and using declaration is:

#include "Arp/Base/Commons/Logging/Log.hpp"
using Arp::Base::Commons::Logging::Log; 

There is a single major change when using this class. The static Log class shall be initialized explicitly by a reasonable logger name; e.g., the name of the application: Log::Initialize("MyApp");

If the initialization is omitted, the logging will be disabled.

Logging on class level

If logging on class level is wanted, use class Arp::System::Commons::Diagnostics::Logging::Loggable by deriving your own class from it. 

This way, a logger instance called log is inherited by your class where the logger name is the full qualified type name of the class. 

See the following examples.

Normal class

class Demo : private Loggable<Demo> 
{ 
}

This code example shows how to use the inherited logger.

void Demo::Method(void)
{
   log.Debug("Any log"); // logs: "<TimeStamp> Demo   DEBUG - Any log" 
}

Singleton class

For singleton classes inherit from class Loggable as follows:

class Demo : private Loggable<Demo, true> 
{ 
}

Pure static class

For pure static classes inherit from class Loggable as follows:

class Demo : private Loggable<Demo, false, true> 
{
}

For pure static classes, it is required to initialize the log member explicitly by once calling Demo::InitializeLogger().

Log file separation

To filter and find log messages more easily, the Output.log will be split into multiple log files.

The main log file is renamed to Arp.log:

• Size: 16 MB + 1 backup file
• All loggers starting with Arp, Eclr and CommonRemoting log to this file (see exceptions below).

For the following components, separate log files will be created:

• PROFINET: Arp.Io.ProfinetStack.log
• SPNS: Arp.Services.SpnsProxy.log
• eHMI:  Arp.Services.Ehmi.log
• Size: 2 MB each + 1 backup file

An additional log file will be created to store identification and version information at system start:

• Arp.Init.log
• Size: 1 MB + 1 backup file
• The purpose of this file is to store persistently some important information that would otherwise be overwritten by log file rotation. These include:
  • Firmware version
  • Vendor, article name, article number, hardware revision, serial number
  • FPGA version
  • SPNS firmware version
  • PCIe extensions: vendor, article name
  • File system: size, free space
  • External SD card: present, enabled, free space
  • Function and location, initial value and changes
  • Network interfaces (no IP address configuration, since it is too volatile)

An additional log file will be created for customer messages, that is every logger whose name does not start with Arp (see exceptions above):

• Custom.log
• Size: 2 MB + 1 backup file

The separated files can be merged using the tool arp-merge-logs on the controller. For information, run arp-merge-logs --help in the console.

External libraries update

CppFormat library replaced by libfmt 10.2.1

The CppFormat library has moved to libfmt, and parts of the libfmt library were adapted to the C++ standard.

PLCnext Technology does not use the std::format due to lacking compiler support and compatibility issues with already present operator<< implementations for user-defined types. But PLCnext Technology uses the libfmt code directly, which was now updated to version 10.2.1.

There are no compatibility issues expected except those listed in class String .

boost libraries updated to version 1.84

The previously used version 1.63 of the boost libraries is quite old and does not support C++ 20. To make newer features available, the boost libraries are updated to version 1.84 from the 2025.0 firmware release on.

Some of the boost::filesystem classes have minor changes regarding their behavior, but this was adapted in the PLCnext Technology firmware code. Thus, there are no compatibility issues expected, as long as the boost code was not used directly by custom code.

CMake adjustments

The PLCnext Technology SDK now provides CMake export configuration files. A virtual package Arp is provided that includes all the packages included in the SDK. This defines the target Arp::ALL that encompasses all relevant libraries and sets the basic usage requirements for the libraries. These include C++ 20 and linker flag --no-undefined.

Link at least one of the Arp libraries to enable these preparations.

In CMakeLists.txt:

find_package(Arp REQUIRED)
target_link_libraries(YourTarget PRIVATE Arp::ALL)

Individual libraries are exported in the namespace Arp. For example, to explicitly link the GDS, use Arp::Arp.Plc.Gds.

For cross-compiling on Windows®, the mingw SDK includes a CMake toolchain file in sysroots\x86_64-w64-mingw32\usr\share\cmake\OEToolchainConfigStandalone.cmake.

The function arp_add_tracing from cmake/ArpTracing.cmake was moved to the export package. It is available after find_package(Arp).

API documentation

The API documentation is provided as an HTML-based online help system for each firmware release from 2020.0 LTS up to the latest releases. Each online help system is publicly available at PLCnext Technology C++ API documentation.

PLCnext CLI adaption

The templates of PLCnext CLI 2025.0 (download at PLCNEXT TECHNOLOGY TOOLCHAIN | Phoenix Contact) have been reworked to support the application-relevant changes.

Therefore, in order to re-use an existing project, a new project needs to be created by means of PLCnext CLI 2025.0. All Components and Programs have to be created newly, too. Their old source code needs to be merged into the new files. All other files of the src folder may be copied into the new project.

Due to changes in the Library and Component class, the existing code has to be merged manually (member/method by member/method).

Changing the initialization system

Every Linux® system has an initialization system which is responsible for starting the daemons and the system configuration (e.g., network configuration) when the system boots. Up to now, PLCnext Technology firmware has used SysV initialization. Due to the increasing complexity of the PLCnext Runtime System and the growing importance of container technology (e.g., Podman or Docker®), it is necessary to switch to the more modern and complex systemd.

Users who intervene directly in the Linux® OS to start their own daemons, or to integrate additional scripts into the system start, will have to convert their start scripts from SysV init to systemd service files. Since container apps from the PLCnext Store currently initialize and start their containers via a special init script, these apps must also be adapted accordingly.

Another impact is the network configuration, as systemd has its own integrated network management. Therefore, the Linux® tools ifup and ifdown no longer exist, and the file /etc/network/interfaces will also no longer exist.

This affects all users who manually intervene in the network configuration via the /etc/network/interfaces file. If a user only uses Arp mechanisms for network configuration (e.g., PLCnext Engineer or the Web-based Management), no adjustments are necessary.

Rework of network management

With the change of the Linux® initialization system (details see Changing the initialization system), the Linux® network management is also changed from the ifup/ifdown procedure with /etc/network/interfaces to the network management integrated in systemd via networkd.

This change allows to implement functions such as multiple IPs per interface, multiple gateways, VLANs, and more in the medium term. It also increases the stability of the system when the IP is changed using Linux® tools.

The network configuration is now handled by the networkd daemon, which is part of systemd. The Linux® tools ifup and ifdown no longer exist, and the file /etc/network/interfaces will no longer be evaluated. This affects all users who manually intervene in the network configuration via the /etc/network/interfaces file. How the conversion of the IP configuration is to be done can be found in the change notes for firmware 2025.0.

If a user only uses Arp mechanisms for network configuration (e.g., PLCnext Engineer or the Web-based Management), no adjustments are necessary.

Activation of Usrmerge

Since 2012, some Linux® distributions have been implementing the project Usrmerge which has the goal to remove the folders /bin, /lib and /sbin by "merging" their contents into the folders /usr/bin, /usr/lib and /usr/sbin. The reason for this is that this duplication of directories is historical and no longer necessary today. The result is a clearer and simpler directory structure. For compatibility reasons, only symbolic links are created for /bin, /lib and /sbin. In addition, the home directory of the root user is no longer /home/root but just /root.

Since 2022, major Linux® distributions like Debian have activated Usrmerge, and since 2024 also the Yocto Project® which is used to generate the PLCnext Linux OS did that. Newer versions of systemd now require Usrmerge, so that there is no longer an alternative to activation.

The folders /bin, /lib and /sbin do not exist anymore in the PLCnext Linux OS. Instead, symbolic links are created:

/bin --> /usr/bin
/lib --> /usr/lib
/sbin --> /usr/sbin

Special care should be taken by users who have stored files in one of the directories mentioned, as these could then overlay the symbolic links in the file system after an update to firmware version 2025.0 which would lead to unpredictable behavior.

Web-based Management 2 (WBM 2)

The previous Web-based Management (WBM) is completely replaced by a new development, called WBM 2. The reasons for the new development are, on the one hand, a new work standard for the definition of web interfaces for Phoenix Contact devices, which describes the design in a new way and considers contemporary features such as mobile views or responsive design. As well, the previous web technology used internally was no longer up to date.

The WBM 2 is set up with the help of a framework (Angular.io), offering many more options and futureproofing. In addition, it will be possible for users to seamlessly integrate their own pages into the controller's WBM, e.g., via apps from the PLCnext Store.

The look and feel as well as the user operation of the WBM 2 are new. Functionally, little to nothing has changed on the pages. 

Removal of Linux packages/tools/libraries

Removal of the vim editor

In addition to the nano editor, the vim editor is also integrated in PLCnext Linux.

In the recent past, security vulnerabilities (CVEs reported to the Phoenix Contact Product Security Incident Response Team (PSIRT) ) have frequently been discovered in vim, so that the editor had to be updated frequently. As the security reports continue to be more frequent, the vim editor is to be removed from the system. This will make the system more secure.

Only users who intervene directly in the Linux system and use the vim editor there are affected by this change. These users must switch to the nano editor, or alternatively translate the vim editor themselves with the SDK and integrate it into PLCnext Linux. It would also be conceivable to provide an app that contains the vim editor.

Removal of the busybox package

Every Linux® system has a set of elementary basic tools such as cp, mount, or grep. These tools are provided by program collections such as GNU core-utils, util-Linux or net-tools. One collection that is optimized in terms of resource requirements is busybox, which was originally developed with a focus on use on embedded systems. The resource requirements have been reduced by omitting features of the tools.

However, many advanced Linux® technologies (e.g., container engines) require the basic tools in their full configuration, which is only provided by the mentioned collections. Over the years, PLCnext Linux has seen a difficult to understand coexistence of tools from collections such as core-utils or util-Linux on the one hand and busybox on the other.

To regain order and future-proof the basic tools, it was decided to no longer integrate busybox but to rely exclusively on the standard tools of the larger collections.

The impact on the user should be very small or even imperceptible. All tools that were previously provided via busybox can still be found in the system under the same name. As the busybox tools each support a subset of the features of the "big" tools, previous calls should continue to work as expected.

Restriction: If users have developed parsers that evaluate the output on stdout of the tools, these parsers will no longer work in many cases, as the output of the busybox tools differs from that of the tools from the larger collections. Users who call the busybox binary directly are also affected, although this should very rarely be the case.

Change of NTP daemon

The currently used ntpd provides a basic set of functions. However, for more complex time synchronization tasks like those mandatory for the implementation of Time-Sensitive Networking (TSN) this function set is not sufficient anymore.

Therefore, the ntpd daemon will be replaced by the chrony daemon. All configuration files will be invalidated or removed from the system.

All configuration files will be invalidated/removed from the system. This change will only affect users who intervene with the Linux® system by means of the ntpd daemon itself and/or its configuration.

Removal of strongSwan legacy configuration interface

The strongSwan Team declared the stroke plug-in as deprecated and it is disabled by default in strongSwan 6.0: 

The legacy stroke management interface has been deprecated for many years and has been replaced by the versatile vici management interface. Thus with strongSwan 6.0, the stroke plugin is not enabled by default anymore and has to be built separately.

To avoid a forced removal of this deprecated plug-in in later PLCnext Technology firmware versions, it is removed from the firmware release 2025.0 and newer. Existing configuration files (ipsec.conf) from 2024.6 or earlier firmware must be migrated to the new swanctl.conf syntax (read the strongSwan wiki article). 

Also the ipsec script was removed. To control an ipsec connection, the swanctl commands must be used.