2. ctrlX OS 与网络栈基础
ctrlX OS 是 ctrlX AUTOMATION 平台的实时操作系统底座，它把 Linux 的通用计算能力与实时任务调度、工业网络协议栈、设备配置入口整合在同一台控制器上。理解这一层，是后续做 EtherCAT、PROFINET、EtherNet/IP、OPC UA 等网络集成的前提。本节从实时系统结构、网络接口命名、协议栈加载机制和配置入口四个角度展开，并给出可操作的观察与配置方法。
一、实时系统：Linux 内核 + 实时扩展 + 应用容器
ctrlX OS 的实时性并非来自单一内核，而是分层实现的。底层是经过裁剪和实时补丁增强的 Linux 内核，负责进程调度、内存管理和设备驱动；其上运行实时任务调度层，为运动控制、EtherCAT 主站等对周期抖动敏感的任务提供确定性执行；再上层是应用运行环境，ctrlX AUTOMATION 的 App（如 ctrlX PLC、ctrlX Motion、ctrlX Drive）以容器化或受管进程方式运行。
这种分层带来一个关键结论：实时任务与通用应用共享同一硬件，但优先级和调度策略不同。实时任务通常绑定到特定 CPU 核，并采用 SCHED_FIFO 等实时调度策略；通用应用则运行在剩余核上。因此，当网络通信出现周期性抖动时，首先要判断是实时任务本身的问题，还是通用应用占用了过多 CPU 导致实时任务被延迟。
在 ctrlX CORE 上，可以通过系统信息页面或命令行查看 CPU 负载与实时任务状态。例如使用 top 观察整体负载，使用 ps -eLo pid,tid,class,rtprio,comm 查看线程的调度类别与实时优先级。若发现实时线程的 rtprio 为 0 或调度类为 TS（分时），说明该任务未进入实时调度，需要检查对应 App 的配置。
二、网络接口：命名规则与物理映射
ctrlX CORE 通常提供多个以太网口，分别用于工程调试、实时工业网络和上层信息网络。在 ctrlX OS 中，接口命名遵循 Linux 的可预测网络接口名规则，常见形式为 eth0、eth1，部分设备上会出现 enp1s0、enp2s0 这类基于 PCI 位置的名称。不同硬件型号的端口数量和命名可能不同，因此不能死记名称，而应通过命令确认物理端口与逻辑接口的对应关系。
常用确认命令如下：
ip -br link show
ip -br addr show
ethtool eth0
ip -br link 给出接口名、状态（UP/DOWN）和 MAC 地址；ip -br addr 给出已配置的 IP 地址；ethtool 可查看链路速率、双工模式和是否支持特定工业以太网特性。对于 EtherCAT 等实时协议，通常要求接口处于独占模式，不能被 Linux 网络栈同时用于普通 IP 通信，否则会引入额外延迟和丢包。
三、协议栈加载：按需启用，而非全部常驻
ctrlX OS 不会在启动时把所有工业协议栈都加载到内核中，而是采用按需加载机制。每个协议栈通常以内核模块或用户态服务的形式存在，由对应的 App 或系统服务在需要时启动。例如 EtherCAT 主站协议栈由 ctrlX EtherCAT Master App 提供，PROFINET 控制器协议栈由相应 App 提供，OPC UA 服务器则作为独立服务运行。
这种设计的好处是减少资源占用和潜在冲突，但也意味着协议栈是否可用，取决于对应 App 是否已安装并启动。如果发现某个网络协议无法通信，第一步不是改 IP，而是确认对应协议栈服务是否处于运行状态。可以通过以下方式检查：
- 在 ctrlX CORE 的 App 管理页面查看已安装 App 及其运行状态；
- 使用
systemctl status <service-name>查看系统服务状态； - 使用
lsmod查看已加载的内核模块，确认实时以太网模块是否存在。
需要注意的是，不同协议栈对网络接口的占用方式不同。EtherCAT 主站通常直接接管某个以太网口，绕过 Linux 网络协议栈；PROFINET 和 EtherNet/IP 则可能同时使用标准 UDP/IP 和实时通道。因此，在规划端口用途时，应把“哪个口给哪个协议栈”作为一项明确的配置决策，而不是让多个协议栈争抢同一接口。
四、配置入口：Web、命令行与工程工具三条路径
ctrlX OS 提供三类配置入口，分别适合不同场景：
| 入口 | 适用场景 | 典型操作 |
|---|---|---|
| ctrlX CORE Web 界面 | 首次调试、快速查看状态 | 设置 IP、查看端口用途、启停 App |
| SSH 命令行 | 批量配置、脚本化、排障 | ip/ethtool/systemctl/lsmod 等命令 |
| 工程工具（如 ctrlX PLC Engineering） | 协议参数配置、设备组态 | 配置 EtherCAT 主站、PROFINET 设备名、OPC UA 端点 |
三条路径操作的是同一套底层配置，但抽象层级不同。Web 界面和工程工具最终会写入系统配置文件或通过服务接口下发，命令行则直接操作这些配置。实际项目中常见的做法是：用 Web 界面完成初始网络设置，用工程工具完成协议组态，用命令行做验证和排障。
五、从配置到验证：一个可复现的检查顺序
假设需要在一台 ctrlX CORE 上启用 EtherCAT 主站并连接一个伺服驱动器，可以按以下顺序检查，避免盲目试错：
- 确认物理连接：EtherCAT 从站接入哪个网口，该口在 Web 界面中是否被标记为实时口。
- 确认接口状态：
ip -br link显示该口为 UP，ethtool显示链路速率为 100 Mbps 全双工。 - 确认协议栈：EtherCAT Master App 已安装并运行，对应内核模块已加载。
- 确认组态：在工程工具中扫描从站，确认设备名称、站地址与拓扑一致。
- 观察运行状态：主站进入 OP 状态，过程数据刷新周期稳定，无丢包或同步错误。
如果第 2 步发现接口为 DOWN，应先检查网线和从站供电；如果第 3 步发现模块未加载，应先启动对应 App；如果第 5 步出现周期抖动，再回到实时系统层面检查 CPU 负载和实时线程优先级。这个顺序把“网络问题”拆解为物理层、接口层、协议栈层和实时层，便于定位。
把这张分层图记在脑子里，遇到网络问题时就能快速判断：是物理链路、接口状态、协议栈加载、实时调度，还是上层组态的问题。ctrlX OS 的配置入口虽然有三条，但它们最终都作用于同一套分层结构，理解结构比记住命令更重要。