The success of an automation system does not depend solely on the performance of the PLC processor. The programming languages used for the control programs, the locations where field signals are collected, cycle and network response times, the environmental conditions of remote I/O stations, the safety architecture, the diagnostic approaches employed, and future expansion plans are all integral components of the same overall system design. Phoenix Contact’s control technology portfolio integrates PLCnext Control controllers, PLCnext Engineer software, Axioline F, Axioline E, and Axioline P remote I/O systems, Axioline Smart Elements modules, as well as modernization options for existing Inline stations, all within a unified automation architecture.
This guide categorizes products not by their brand names, but rather according to their control, communication, and I/O functions. The technical specifications, such as the product number or the explicitly specified product family, are relevant for these classifications. The network capacity of a controller, the number of channels in an I/O module, or the temperature range of a product family should not be automatically transferred to another variant. The final configuration must be verified in conjunction with the latest product data sheets, software versions, protocol compatibility, cybersecurity policies, and machine risk assessments.
Start the control architecture with a task list
Before selecting a controller, it is necessary to determine the system’s real-time tasks, motion or process cycles, the number of digital and analog channels, any special functions, the number of devices connected to the network, and the data flow patterns. Additionally, IT considerations such as recipe management, database functionality, reporting capabilities, remote access, and cloud integration must also be taken into account. Once it has been decided whether each function will be performed by the controller, an industrial PC, an edge device, or a higher-level system, the selection of the processor and software can be based on specific requirements.
PLCnext Technology focuses on integrating traditional IEC 61131-3 programming with advanced development methods such as C/C++, C#, and MATLAB Simulink within the same automation framework. Phoenix Contact offers PLCnext Engineer as an engineering platform that combines configuration, IEC 61131-3 programming, visualization, and diagnostic functions. However, the specific programming language to be used, the runtime components required, licensing details, and support for target hardware must be confirmed at the beginning of the project. Just because an ecosystem supports a particular language does not necessarily mean that all its libraries are suitable for real-time and safe applications.
Open, scalable control with PLCnext Control
The PLCnext Control devices in the Axiocontrol series are available in various performance classes. These controllers can be expanded using I/O modules via the Axioline F local bus; in certain models, additional extensions can be connected to the left side to enable safety functions, additional Ethernet interfaces, or artificial intelligence capabilities. This modular approach enables the creation of a range of hardware options under the same technical framework—ranging from basic machine control to applications that require higher performance and functional safety features.
Openness does not mean allowing the installation of software in an uncontrolled or unrestricted manner. For every library and application to be incorporated into the project, details such as version, source code, license, update methodology, and potential cybersecurity impacts must be documented. The control program and IT components are distinguished based on their resource consumption and permission requirements. User roles, certificate management practices, secure network segmentation, as well as backup and update plans must all be established before the system is even commissioned. In particular, remote access and cloud connectivity must be approved in accordance with the facility’s security policies and network architecture.
Controller example: AXC F 2152
The AXC F 2152, with the product number 2404267, is a modular PLCnext Control controller that features a Yocto/Linux real-time operating system, compliance with IEC 61131-3 standards, and various high-level programming options. The current product page specifies that it is equipped with two 800 MHz Arm Cortex-A9 processor cores, 512 MB of DDR3 RAM, 512 MB of internal flash memory, and 48 kB of NVRAM. It should be noted that these hardware specifications apply specifically to the AXC F 2152 model and not to the entire PLCnext Control family; later models or those with higher performance may utilize different processor and memory configurations.
The product page for the AXC F 2152 states that each Axioline F station can support up to 63 local bus devices, and a maximum of 1,482 bytes of process data for inputs and outputs combined. In PROFINET mode, this device functions both as a controller and as a device; the minimum update interval for transmitting data is 1 millisecond for up to 4 devices, and 16 milliseconds for 64 devices. However, these figures do not automatically guarantee the actual operating cycle time of the system. The actual performance also depends on factors such as the program load, network topology, device configuration, and communication traffic.
The manufacturer states that the AXC F 2152 has undergone a certification process in accordance with IEC 62443-4-1 and has obtained a product certification in accordance with IEC 62443-4-2; it also refers users to the accompanying documentation for the certification requirements. While these certifications represent important aspects of the product’s specifications, they alone do not ensure the security of the entire plant network. Responsible for ensuring a secure installation are the system integrator, as well as tasks such as user management, updating software, network segmentation, backup procedures, event logging, and maintenance activities.
Axioline F: modular I/O for control panels
Axioline F is a modular I/O system used in control panels. Its portfolio includes both digital and analog input/output modules, as well as modules dedicated to specialized functions such as temperature measurement, communication, metering, and functional safety. The stations can be controlled directly via a PLCnext Control device or connected as remote I/O components to a higher-level control system via the appropriate bus module. This distinction determines whether the control functions are performed on-site or in a central location, and it also affects the system’s behavior in the event of a network interruption.
Phoenix Contact highlights the push-in connection technology, open-cable layout, and robust mechanical design of the Axioline F series. The product page specifies resistance to vibrations up to 5g, continuous impacts of 10g, and transient impacts of 30g. The wide temperature range of –40 to +70 °C is specifically stated for the XC versions; however, it should not be assumed that all Axioline F modules comply with this specification. Certifications for use in maritime applications, hazardous areas, or for functional safety requirements must also be verified for each specific product model.
Bus coupler example: AXL F BK ETH
The AXL F BK ETH with the product number 2688459 is an IP20 bus module that establishes a connection between a Modbus/TCP (UDP) network and the Axioline F local bus. The product page specifies that it supports 10/100 Mbit/s Ethernet over two RJ45 interfaces, as well as a data rate of 100 Mbit/s on the Axioline F local bus. A maximum of 63 local bus devices can be connected to each station. The nominal supply voltage is 24 V DC, while the allowable voltage range, including fluctuations, is 19.2–30 V DC. These values should only be used in conjunction with the hardware revision information and the notes on the product page.
This example demonstrates that the phrase “Ethernet bus module” alone is insufficient; the higher-level network protocol, the client-server role of the control system, IP addressing, cycle time requirements, redundancy mechanisms, connection topology, and device configuration files must all be predetermined. If PROFINET, EtherNet/IP, EtherCAT, or another protocol is to be used, the corresponding Axioline F bus module must be selected. The Modbus/TCP functionality of the AXL F BK ETH model does not automatically support other protocols.
High channel density with Axioline Smart Elements
Axioline Smart Elements are plug-in modules that do not incorporate their own bus communication capabilities; each module performs a specific I/O function. Communication is established via the backplane or carrier that connects the Smart Element to the appropriate I/O system. Phoenix Contact specifies up to 16 connections in a 15 × 62 mm Smart Element, supporting conductors up to 1.5 mm² with plastic-collared ferrules. The push-in technology ensures that signal cables remain easily accessible within a confined space.
The Axioline F backplanes are available with four or six Smart Element slots, allowing for a two-row configuration that reduces the overall station width. Different modules such as digital I/O, analog functions, temperature measurement, and serial communication can be integrated within the same system architecture. For example, the AXL SE RS485 EF with the product number 1507978 is an IP20 communication module that supports data transfer rates ranging from 100 bit/s to 230,400 bit/s over a single RS-485 interface, as well as Modbus/RTU client-server communication. The actual process data, protocol mode, and cycle requirements should be confirmed in the complete product documentation.
Which requirements do Axioline E and Axioline P address?
Moving each signal components to the control panel can increase the length of cables, the number of terminals required, and the time needed for commissioning. Axioline E is designed as a remote I/O system with modular blocks that can be installed near the machine or the process, rather than within the control panel itself. Phoenix Contact’s product page provides details on the Axioline E options, including their suitability for IP65/IP67 environments and their M12 connection technology. For field installations, factors such as the network protocol, power coding, number of ports, type of I/O components, sensor supply current, cable topology, and the proper closure of unused ports must all be carefully considered and planned.
Axioline P is designed for process applications that require high reliability. Its portfolio includes redundant PROFINET bus connections, digital and analog I/O options, an extended temperature range, as well as standard or intrinsically safe I/O modules that can be replaced while the system is still in operation. While the “hot-swappable” design facilitates maintenance, it does not mean that each module can be safely removed and reinstalled in any desired location. The classification of hazardous areas, the intrinsic-safety circuit calculations, the redundancy architecture, and the manufacturer’s procedures must all be verified specifically for the particular product and application.
Distinguish functional safety I/O from standard I/O
Safety sensors or safety stop signals cannot be selected in the same way as standard digital inputs. The AXL F PSDI8/4 1F, with the product number 2701559, is an Axioline F safety input module designed for the PROFIsafe system. This product offers four two-channel or eight single-channel safety digital inputs, a 24 V DC input, and various connection options with 2, 3, or 4 wires. The product page specifies that this module can only be used in conjunction with Phoenix Contact or Siemens controllers; this compatibility requirement must be adhered to in the project design.
The number of channels in a safety module does not alone determine the required level of safety. The overall safety performance is determined by factors such as the sensor architecture, the use of single or dual channels, the ability to detect short circuits and cross-circuits, the test signal, the response time, the cable layout, and the safe shutdown mechanism at the actuator end. Even if standard PROFINET traffic and PROFIsafe communication can coexist on the same physical network, addressing, F-parameters, validation, and change management processes must be implemented in accordance with the safety lifecycle requirements.
Compare control and I/O options
| Task or environment | Solution to consider | Key selection inputs |
|---|---|---|
| Machine or system control | PLCnext Control | Program load, language, cycle time, networks, memory, security, and expansion capabilities. |
| Modular signal acquisition on the control panel | Axioline F | Channel type, bus protocol, station limits, temperature, and special functions. |
| High I/O density in a confined space | Axioline Smart Elements | Carrier compatibility, number of slots, channel function, and cable cross-section. |
| Remote I/O without a control panel on the machine | Axioline E | IP class, M12 connectors, network protocol, power requirements, and environmental conditions |
| Process and high continuity | Axioline P | Redundancy, hot-swap, Ex/intrinsically safe channels, and temperature |
| Modernizing the existing Inline station. | PLCnext with inline adapter for transition applications | Existing modules, firmware, data mapping, interruptions, and gradual transitions. |
| Hardware-independent control approach | Virtual PLCnext Control | Host infrastructure, real-time capabilities, licensing, redundancy, OT/IT security, and maintenance. |
Modernising existing systems in stages
Phoenix Contact offers a modernization approach based on adapters for using existing Inline I/O modules with PLCnext Control. This allows for the gradual renewal of the control layer, rather than replacing the entire field wiring at once. However, it should not be assumed that all existing Inline modules, their specific functions, and firmware versions are supported. The old data maps, identification bits, analog ranges, safety functions, and spare part status must be individually documented and tracked.
Virtual PLCnext Control presents the PLCnext architecture as a software-based controller within an OCI container. PROFINET controller or device functionality, web-based management, and support for IEC 61131-3 as well as a wide range of programming languages are key features of this product family. Virtual control should not be viewed merely as a solution that eliminates the need for hardware; rather, real-time performance, supported platforms, network interfaces, host redundancy, resource allocation, licensing, backup mechanisms, and cybersecurity measures are all essential components of this architecture.
Engineering and commissioning sequence
- Classify the functions: Separate real-time control from standard I/O functions, safety measures, process control, data collection, and IT services.
- Detail the I/O list: Specify the type of channel, signal level, sensor power supply, filter, scale, and error behavior.
- Determine the physical location: Decide whether the signals will be collected within the control panel, on the machine itself, or at the process site.
- Select a protocol: Ensure that the controller, bus module, and field devices all operate within the same network and share the same update objectives.
- Calculate the capacity: Compare the number of devices, process data, cycle time, power budget, and station current with the product specifications.
- Design cybersecurity: Create policies for certificates, network segmentation, remote access, patching, and backup.
- Verify safety measures: Separate standard I/O components from safety-related ones; establish traceability for safety functions based on risk assessments.
- Record the test results: Document channel tests, network load, fault scenarios, restart, backup restoration, and safety validation.
Information required for a quotation
- Definition of machinery or processes, control cycles, and expected program execution times.
- IEC 61131-3, C/C++, C#, MATLAB Simulink, or other development requirements.
- List of all digital, analog, temperature, metering, serial communication, and safety channels
- The physical location of each station, each IP class, temperature, vibration levels, and whether it is located in a hazardous area.
- PROFINET, Modbus/TCP, EtherNet/IP, or other network protocols and topologies are required.
- Per controller and I/O station: devices, process data, power supply, and expansion options.
- Redundancy, hot-swapping, uninterrupted operation, and the allowable downtime during maintenance.
- Functional safety objectives, F-I/O channels, and controller compatibility requirements
- Requirements for cloud, upper-level systems, databases, remote access, and time synchronization.
- Inventory of existing Inline or other I/O infrastructures, as well as a phased transition plan.
Once this data set is prepared, Phoenix Contact’s control and I/O portfolio goes beyond mere component selection, enabling the creation of sustainable automation architectures. Oskon can take into account controller performance, I/O layout, communication load, safety requirements, and maintenance strategies to determine the most appropriate PLCnext Control and Axioline configuration. Before placing an order, product numbers, hardware revisions, firmware compatibility, licenses, and certifications must be confirmed in accordance with the latest Phoenix Contact documentation.
