做自动化项目的朋友应该都碰到过这种需求手头一台非标检测设备、AGV控制器或者机器人必须把数据送进西门子 S7-1200/1500 里可设备本身没有 PROFINET 接口。常规操作是买网关、买通讯板卡单台设备做项目无所谓可一旦要批量出货、变成产品线的一部分每台都挂一个小几百上千块的转换器无论成本、结构空间还是现场可靠性都很不划算。p-net 协议栈就是这种情况下我踩了一年多坑之后觉得最值得分享的路线它是开源的 PROFINET 从站实现能让你把自己的嵌入式设备直接变成 PROFINET IO 设备和西门子 PLC 原生通讯完全避开商业协议栈按出货量收版权费的玩法。这篇文章我按自己实际调试经历来写从下载源码到通过真实 PLC 交换数据的完整链路都会讲到适合想入行工业以太网、又不想一上来就烧钱买授权的人参考。1. 为什么用 p-net开源PROFINET从站协议栈的现实价值1.1 什么场景会需要自己造一个 PROFINET 从站先说场景否则很多人会觉得“我有网关用何必造轮子”。大体上有三类情况值得自己动手产品要批量出货网关成本叠加让整机利润变得很难看而且多一个第三方模块就多一个失效点、多一份库存管理标准市场里没有现成模块能贴进你的硬件结构比如板卡高度、接口位置、工作环境温度都对不上你对设备的数据深度有要求比如需要从 PLC 侧直接下发工艺参数而不只是交换几个 IO 字节这时候协议栈级集成比外挂网关灵活得多。我自己最典型的一次项目是一套视觉检测设备要接入某汽车厂产线。设备用的是一块 ARM 工控板原来只出 Modbus TCP客户那边明确说“要么你出 PROFINET要么换掉方案”。买一台现成的 Anybus 通讯模块价格不高但客户要求计入所有出货设备累计下来授权和模块成本完全覆盖了自研工时。这才是我真正开始研究 p-net 的原因。1.2 p-net 能覆盖的协议层次和商业栈的差距先把能力边界说清楚免得你满怀期待跳进来发现方向不对。p-net 实现了 PROFINET IO 设备角色里最核心的一整套东西循环 IO 数据交换、记录数据读写Record Data、报警上报Alarm、DCP 发现与配置协议、LLDP 拓扑发现、PROFINET 的状态机管理。对绝大部分工厂场景来说——PLC 侧读你十几个输入字节、写你几个输出字节、偶尔读一次设备参数、设备异常时发一个诊断报警——它完全够用。但它有两个硬限制不原生支持 PROFINET IRT 等时同步实时通讯。IRT 需要网卡硬件配合完成帧调度p-net 是纯软件协议栈走的是 RT时钟同步精度达不到运动控制那种微秒级。做伺服、做插补这种场合不要选它它不替你完成 PI 认证。如果你的产品最终要在市场上标称“PROFINET 兼容”还是需要把设备送到授权测试实验室过一致性测试这部分费用和时间省不掉。但相比每一台都交高额版税的商业栈认证是一次性投入摊薄下来依然划算。还有一点p-net 的工程默认是 Linux 环境虽然代码本身设计得比较平台无关但官方支持得最顺的还是嵌入式 Linux。如果你的产品是裸机 MCU 开发移植工作量会比 Linux 大不少后面会讲到底大在哪。1.3 和 EtherCAT 从站、PROFINET 总线板卡的选型对比很多人看“PROFINET 从站”这个词会跟 EtherCAT 从站弄混这里把关系理一遍。PROFINET 通讯协议工作在标准以太网之上帧的 EtherType 是 0x8892实时数据一般发到组播 MAC 地址从站本质上就是一个拥有独立 IP 和 MAC 的以太网节点。EtherCAT 则不一样主站发送一个帧帧经过每个从站时由从站里的 ESC 芯片就地读取和插入数据再传给下一个从站强调分布式时钟和极低抖动。两条技术路线各有所长西门子环境里 PROFINET 是天然主力倍福、汇川这类控制器密集的现场 EtherCAT 更占优势。至于“PROFINET 总线板卡”比如发那科机器人上的 PROFINET 板卡准确说是一种封装好的从站方案。发那科板卡让机器人控制器作为 IO 设备接入 PLC你拿到手只需要配置地址映射用 p-net 则是把同样的事情放到你自己硬件上从设备描述文件到数据区布局全部由自己定义。两者解决问题相同区别只在于你愿不愿意把“从站能力”做成自己产品的固有部分。2. 数据流和协议层次PROFINET 从站内部到底在交换什么2.1 循环 IO 机制从站不是“收到指令才反应”刚接触 PROFINET 的人最容易误解的一点是从站是不是像 Modbus 一样等主站发请求然后从站回响应完全不是。PROFINET IO 建立连接后IO 控制器会按照设定好的发送周期比如 8ms、16ms持续向组播地址发送 IO 数据帧IO 设备从这些帧里取出输出数据同时把自己的输入数据放到发送帧里带回去。这个循环是持续进行的双方都不需要等对方请求。在 p-net 里这个循环由两个层面协同完成底层协议栈每收到一帧就更新数据缓冲应用层则需要周期调用pnet_handle_periodic()来推进协议栈状态机。数据缓冲本身是分配好的静态区域你做的只是把应用数据往输入缓冲区里填再从输出缓冲区里取。这个设计对初学者特别友好——不用处理拆包组包只要关心字节怎么放。2.2 记录数据和报警非循环通道不能忽略除了循环 IOPROFINET 还有两条非循环通道做实际设备时躲不开。记录数据通道用于读写设备参数比如 PLC 通过“写记录”指令下发一组工艺配方或者从站上报固件版本。p-net 里对应的是 Record Data API你需要按记录索引注册读回调和写回调协议栈会把 PLC 发来的记录请求分发给正确索引。报警通道则是设备主动上报的重要手段。设备掉线、传感器故障、温度超限这些都能通过进程报警发给 PLCPLC 侧不用轮询就能及时感知。p-net 的报警 API 要求你先定义报警源状态再调用报警发送函数参数里要带报警类型、严重程度和相关的诊断数据。实际做产品时我建议尽早把报警通道设计进去否则后续加报警要动 GSDML 和槽位配置比一开始就设计好麻烦得多。2.3 DCP、LLDP 和设备名IP 怎么来的设备怎么被认出来PROFINET 从站和普通以太网设备一个很大区别是PLC 找从站时优先依赖“设备名”而不是 IP 地址。设备名在网络里的唯一性由 DCP 协议保证。首次上电时从站可以没有 IPPLC 或调试工具用 DCP 发送广播帧按设备名找到从站然后给它分配 IP。这里有个关键点p-net 初始化时你会配置一个name_of_station这个名字必须和 TIA Portal 里的设备名完全一致否则 PLC 永远找不到设备。LLDP 则用于拓扑识别让交换机、PLC 知道这个端口对端接了什么设备。它不直接参与数据交换但现场维护时很有用很多高级诊断界面依赖 LLDP 画网络拓扑。p-net 默认支持 LLDP 发送建议保持开启不要为了省几个字节的数据关闭它。3. 搭建工程下载源码、移植层和编译3.1 源码目录结构哪些文件该改哪些不该动从 GitHub 拉下 p-net 源码后你会看到它分成大致三块一是src/里是协议栈核心实现这部分正常不需要动它实现 DCP、LLDP、IO 状态机、报警等协议细节二是src/ports/是平台相关层p-net 叫pnalp-net abstraction layer里面有 Linux 下对网络接口、操作系统时钟、互斥锁的适配三是配置解析层较新版本用 JSON 描述设备配置运行时会解析成内部配置结构体。我的建议是协议栈核心碰都不要碰那里面有太多协议时序细节改错了你排查三天都不知道问题在哪。你需要改的就是 ports 目录里的网络接口实现以及应用层调用代码。如果是全新硬件核心精力一定集中在让 pnal 层跑通。3.2 pnal 层到底在适配什么pnal 层在 Linux 里主要做两件事发收以太网帧、提供操作系统服务。网络接口这块p-net 使用 Linux 的原始套接字AF_PACKET直接收发 PROFINET 帧它绕过了 TCP/IP 协议栈才能保证实时性。你需要做的是把网卡的名字、MAC 地址、VLAN 配置交给 pnal 初始化函数。操作系统服务则是线程、时钟、互斥锁这些基本功Linux 下大多已经有默认实现。如果你是第一次移植先用一块常见的 USB 网卡或者板载千兆网卡在普通 Linux 上跑通官方 demo确认能收到 PLC 帧再考虑换到特定工控网卡。工控网卡有时会有厂商私有驱动影响帧收发这点后面实测部分细说。3.3 交叉编译和第一次运行验证p-net 支持 CMake 构建本地编译最简单cmake -B build cmake --build build就能出可执行文件。交叉编译时额外指定工具链文件即可比如-DCMAKE_TOOLCHAIN_FILE../toolchain-arm.cmake。依赖很少基本就是 pthread 和标准库对老 ARM 平台也很友好。第一次上板跑不要着急接 PLC先在终端里看启动日志有没有打印出设备名、MAC、IP 和槽位配置。没有异常就继续下一步。如果你手上有西门子官方的 PSTPrimary Setup Tool直接扫描网络能看到一个 DCP 设备出现在列表里名字和你在配置里写的一致说明协议栈底层已经活了。4. 把设备建模成 PROFINET 从站槽位、子槽位与数据区4.1 模块化设备模型从站不是“一块裸板”PROFINET 设备模型采用插槽概念类似机架式 PLC 的导轨插槽。一个从站设备由若干插槽Slot组成每个插槽里可以插入一个模块模块下又有子模块。子模块才是真正承载 IO 数据的实体每个子模块有独立的输入数据长度、输出数据长度和子模块标识号。这样设计的好处是GSDML 描述文件和 PLC 组态可以灵活组合同一台硬件通过插槽配置就能呈现不同的 IO 布局。p-net 的配置里你要定义每个模块的module_ident和每个子模块的submodule_number、输入长度、输出长度、子模块标识。这些编号必须和 GSDML 里的ModuleIdentNumber、SubmoduleIdentNumber严格对应差一个字节 PLC 都会报组态错误。4.2 JSON 配置和 pnet_api 代码骨架p-net 的设备配置我用过的是 JSON 方式核心内容大致如下{ station_name: pnet-demo-device, ip: 192.168.1.20, netmask: 255.255.255.0, mac_address: 02:00:00:aa:bb:01, vendor_id: 0x0002, device_id: 0x0001, modules: [ { module_ident: 1, submodules: [ { subslot_number: 1, input_length: 8, output_length: 8, ident: 1 } ] } ] }字段含义很直观input_length是从站往 PLC 方向发送的数据长度output_length是 PLC 往从站方向写的数据长度。多少字节完全看你的实际数据量常见的数字量 IO 也就几个字节模拟量或编码器数据会到几十字节。应用启动后你通过 pnet_api 的接口拿到某个子模块的输入输出数据指针然后拷贝应用数据即可。4.3 IO 数据区和 PLC 地址的映射逻辑这一步是很多人卡住的地方p-net 里一个子模块有 8 字节输出PLC 侧到底地址是多少答案不取决于你的 JSON而取决于 TIA Portal 里给这个设备分配的“IO 起始地址”。比如你在 TIA 里给设备分配输出起始地址为 IW64那么这个子模块的第 1、2 字节就是 IW64第 3、4 字节就是 IW66依次类推。注意 PROFINET 的字节序是大端还是小端问题。p-net 里一般按字节数组给你PLC 侧如果按字读高低字节顺序必须测一遍再定属于最容易踩的隐性坑。我的习惯是第一个字节放一个固定值如 0xAA第二个字节放 0x55接上 PLC 看一眼读出来哪个在前一次就能确认字节序。5. GSDML、TIA Portal 和地址对应实战5.1 手工写一份最小可用的 GSDMLGSDML 是 PROFINET 设备的“身份证”本质上是一份 XML 文件记录厂商 ID、设备 ID、模块列表、数据长度、设备访问参数。TIA Portal 靠它知道怎么组态你的从站。p-net 的 demo 里通常带一份示例 GSDML你可以改厂商 ID、设备 ID、站名和模块长度来适配自己设备。关键字段就那几个VendorID和DeviceID要和 p-net JSON 配置一致ModuleList和SubmoduleList列出插槽里的模块和子模块标识号、输入输出长度MinDeviceInterval最小通讯周期写 8ms 或 16ms 比较稳妥NameOfStation默认站名TIA 里可以改但第一次联调用默认值最省事。我不建议第一版就做一大堆模块先一个槽位、一个子模块、几个字节数据跑通后面再扩充。5.2 在 TIA Portal 里安装和组态TIA Portal 安装 GSDML 的路径是“选项—管理通用站描述文件GSD”选中你的 XML 文件安装然后网络视图里会多出一个设备条目。拖进网络后双击设备在“以太网地址”里填上设备名比如你自己定义的pnet-demo-deviceIP 地址会自动分配或者手动填。再进设备视图把对应模块拖到插槽上系统会显示每个子模块的输入输出地址。这一步如果 GSDML 和 p-net 配置有出入TIA 会直接提示组态不一致回去检查 JSON 里的module_ident或者 GSDML 里的模块编号就行。5.3 西门子 PLC 与安川机器人地址对应的现实问题现场最常被问到的问题是“西门子 PLC 和安川机器人 PROFINET 通讯地址怎么对应”。其实原理一致机器人侧有一个 PROFINET 从站接口PLC 侧安装机器人厂家的 GSDML 后在 TIA 里组态。机器人控制器里比如安川 YRC1000 的工业网络设置界面你设置从站设备名、IP、输入输出数据长度还会有一个“内部寄存器/IO 映射表”决定机器人内部变量对应到 PROFINET 数据区的哪个字。PLC 侧则根据 GSDML 模块布局分配 IO 起始地址。实际操作时把两边看成“字节管道”PLC 的输出地址对应机器人的输入区机器人的输出区对应 PLC 的输入地址。对齐方式就是 PLC 起始地址和偏移量加上机器人内部映射地址两边必须按同一份字节序和长度表核对。经常出问题的是“字/字节顺序”因为机器人控制器的 CPU 和西门子 PLC 的字节序不同字数对不上就得在映射表里做高低字节交换。我的建议是先用一个 100 字节左右的测试块在机器人内部写一串固定的 0x01、0x02 计数PLC 读回来对比把正确的字节顺序确定后再做正式数据。发那科板卡也是同一个套路发那科机器人里配置好 PROFINET 板卡的 IP 和设备名在 PLC 侧按板卡 GSDML 组态IO 地址由模块布局决定机器人内部用“端口映射”把物理 IO 或寄存器对到 PROFINET 数据区。6. 联调排错真实 PLC 上的完整排查链路6.1 先过 DCP 和 PingIP 层面的确认拿到一个还没接通过从站不要直接上 PLC 诊断先把底层确认了。用西门子 PST 扫描能看到设备名、MAC、IP说明 DCP 层正常。随后 ping 一下设备 IP网络通至少说明以太网链路没问题。我调试时发现一个很常见的“假故障”PLC 网络里如果开了 VLANPROFINET 帧默认带 VLAN 标签和优先级而 p-net 的网卡如果不处理 VLAN部分帧会收不到。先关掉交换机端口的 VLAN 再试是排除网络环境干扰最快的方法。6.2 用 Wireshark 抓包看连接建立过程协议栈层面对不对最可信的判据是抓包。PC 上用 Wireshark抓网卡流量过滤条件写profinet先看有没有周期性 RT 帧和 DCP 帧。然后启动 PLC 执行观察有没有 AR应用关系建立请求。建立过程大概分几步PLC 发送“连接建立”请求从站返回确认双方参数协商然后 PLC 下发写记录数据配置模块和期望的槽位最后进入周期数据交换。如果抓包停在“连接建立请求没有确认”基本是你 p-net 状态机没转起来检查有没有周期调pnet_handle_periodic()或者设备名和组态名不一致。如果停在写记录阶段大概率是 GSDML 和实际槽位不匹配回到第 5 节核对标识号。6.3 从站亮红灯的典型排查方向实际现场里最让人头大的是设备红灯乱闪PLC 报“设备故障”或“Station not reachable”。按经验排查顺序很重要先看 IP设备 IP 是否和 PLC 网段一致注意 PROFINET 用的是网卡物理口不是虚拟网卡再看设备名TIA 组态的设备名必须和 p-net 配置完全一致大小写都算斜杠、空格也算然后看连接周期TIA 里设置的更新时间要和 GSDML 允许的MinDeviceInterval匹配你 GSDML 写最小 16msTIA 里设了 8ms就会反复断连最后看防火墙、交换机PROFINET RT 帧是多播帧有些安全交换机默认拦截多播必须在交换机上放行 0x8892。这些方向我从实践里筛了一遍绝大多数问题出现在第二和第三点上。6.4 把通讯周期压到 1ms 时的工程限制如果你的设备对实时性有要求想把发送周期设到 1ms就要面对一个现实p-net 是纯软件栈在一颗普通 ARM 处理器上做到 1ms 稳定周期并不是必然达标。影响因素有几个CPU 调度抖动、网卡驱动的中断延迟、以及应用代码本身有没有在循环里做耗时操作。我的经验是先把周期设 4ms 或 8ms 跑稳定再尝试往下压。同时打开 Wireshark 看 IO 帧的实际到达间隔如果抖动超过 0.5ms优先检查驱动和中断合并设置。极端情况下可以配合 Linux 的 PREEMPT_RT 实时补丁或者把业务逻辑搬到另一个 CPU 核心上把协议栈线程绑在独立核。p-net 在 1ms 周期下不是不可行而是你要把整个平台调优到够格。最后想说的一点经验从我自己的项目经历来说p-net 最吸引人的地方不是“免费”而是它把 PROFINET 从站的完整协议细节摊在你面前调试过程逼着你去理解 DCP、LLDP、报警、记录数据这些概念这些东西一旦搞懂以后接任何工业以太网项目心里都有底。真正开始之前建议先在普通 Linux PC 上跑通 demo再移植到嵌入式板子分阶段调试会省非常多时间。最后分享一个小技巧所有 p-net 配置里的编号、长度、设备名我会单独建一个对照表把 GSDML 里的标识号、JSON 配置的字段、TIA 组态的设定列成三列联调时任何一端改配置先回表格确认三边一致。这个习惯帮我避开了很多明明两边都配对、却因为第三处不一致浪费整整一天的坑。
开源p-net协议栈：将嵌入式设备变为PROFINET从站对接西门子PLC
做自动化项目的朋友应该都碰到过这种需求手头一台非标检测设备、AGV控制器或者机器人必须把数据送进西门子 S7-1200/1500 里可设备本身没有 PROFINET 接口。常规操作是买网关、买通讯板卡单台设备做项目无所谓可一旦要批量出货、变成产品线的一部分每台都挂一个小几百上千块的转换器无论成本、结构空间还是现场可靠性都很不划算。p-net 协议栈就是这种情况下我踩了一年多坑之后觉得最值得分享的路线它是开源的 PROFINET 从站实现能让你把自己的嵌入式设备直接变成 PROFINET IO 设备和西门子 PLC 原生通讯完全避开商业协议栈按出货量收版权费的玩法。这篇文章我按自己实际调试经历来写从下载源码到通过真实 PLC 交换数据的完整链路都会讲到适合想入行工业以太网、又不想一上来就烧钱买授权的人参考。1. 为什么用 p-net开源PROFINET从站协议栈的现实价值1.1 什么场景会需要自己造一个 PROFINET 从站先说场景否则很多人会觉得“我有网关用何必造轮子”。大体上有三类情况值得自己动手产品要批量出货网关成本叠加让整机利润变得很难看而且多一个第三方模块就多一个失效点、多一份库存管理标准市场里没有现成模块能贴进你的硬件结构比如板卡高度、接口位置、工作环境温度都对不上你对设备的数据深度有要求比如需要从 PLC 侧直接下发工艺参数而不只是交换几个 IO 字节这时候协议栈级集成比外挂网关灵活得多。我自己最典型的一次项目是一套视觉检测设备要接入某汽车厂产线。设备用的是一块 ARM 工控板原来只出 Modbus TCP客户那边明确说“要么你出 PROFINET要么换掉方案”。买一台现成的 Anybus 通讯模块价格不高但客户要求计入所有出货设备累计下来授权和模块成本完全覆盖了自研工时。这才是我真正开始研究 p-net 的原因。1.2 p-net 能覆盖的协议层次和商业栈的差距先把能力边界说清楚免得你满怀期待跳进来发现方向不对。p-net 实现了 PROFINET IO 设备角色里最核心的一整套东西循环 IO 数据交换、记录数据读写Record Data、报警上报Alarm、DCP 发现与配置协议、LLDP 拓扑发现、PROFINET 的状态机管理。对绝大部分工厂场景来说——PLC 侧读你十几个输入字节、写你几个输出字节、偶尔读一次设备参数、设备异常时发一个诊断报警——它完全够用。但它有两个硬限制不原生支持 PROFINET IRT 等时同步实时通讯。IRT 需要网卡硬件配合完成帧调度p-net 是纯软件协议栈走的是 RT时钟同步精度达不到运动控制那种微秒级。做伺服、做插补这种场合不要选它它不替你完成 PI 认证。如果你的产品最终要在市场上标称“PROFINET 兼容”还是需要把设备送到授权测试实验室过一致性测试这部分费用和时间省不掉。但相比每一台都交高额版税的商业栈认证是一次性投入摊薄下来依然划算。还有一点p-net 的工程默认是 Linux 环境虽然代码本身设计得比较平台无关但官方支持得最顺的还是嵌入式 Linux。如果你的产品是裸机 MCU 开发移植工作量会比 Linux 大不少后面会讲到底大在哪。1.3 和 EtherCAT 从站、PROFINET 总线板卡的选型对比很多人看“PROFINET 从站”这个词会跟 EtherCAT 从站弄混这里把关系理一遍。PROFINET 通讯协议工作在标准以太网之上帧的 EtherType 是 0x8892实时数据一般发到组播 MAC 地址从站本质上就是一个拥有独立 IP 和 MAC 的以太网节点。EtherCAT 则不一样主站发送一个帧帧经过每个从站时由从站里的 ESC 芯片就地读取和插入数据再传给下一个从站强调分布式时钟和极低抖动。两条技术路线各有所长西门子环境里 PROFINET 是天然主力倍福、汇川这类控制器密集的现场 EtherCAT 更占优势。至于“PROFINET 总线板卡”比如发那科机器人上的 PROFINET 板卡准确说是一种封装好的从站方案。发那科板卡让机器人控制器作为 IO 设备接入 PLC你拿到手只需要配置地址映射用 p-net 则是把同样的事情放到你自己硬件上从设备描述文件到数据区布局全部由自己定义。两者解决问题相同区别只在于你愿不愿意把“从站能力”做成自己产品的固有部分。2. 数据流和协议层次PROFINET 从站内部到底在交换什么2.1 循环 IO 机制从站不是“收到指令才反应”刚接触 PROFINET 的人最容易误解的一点是从站是不是像 Modbus 一样等主站发请求然后从站回响应完全不是。PROFINET IO 建立连接后IO 控制器会按照设定好的发送周期比如 8ms、16ms持续向组播地址发送 IO 数据帧IO 设备从这些帧里取出输出数据同时把自己的输入数据放到发送帧里带回去。这个循环是持续进行的双方都不需要等对方请求。在 p-net 里这个循环由两个层面协同完成底层协议栈每收到一帧就更新数据缓冲应用层则需要周期调用pnet_handle_periodic()来推进协议栈状态机。数据缓冲本身是分配好的静态区域你做的只是把应用数据往输入缓冲区里填再从输出缓冲区里取。这个设计对初学者特别友好——不用处理拆包组包只要关心字节怎么放。2.2 记录数据和报警非循环通道不能忽略除了循环 IOPROFINET 还有两条非循环通道做实际设备时躲不开。记录数据通道用于读写设备参数比如 PLC 通过“写记录”指令下发一组工艺配方或者从站上报固件版本。p-net 里对应的是 Record Data API你需要按记录索引注册读回调和写回调协议栈会把 PLC 发来的记录请求分发给正确索引。报警通道则是设备主动上报的重要手段。设备掉线、传感器故障、温度超限这些都能通过进程报警发给 PLCPLC 侧不用轮询就能及时感知。p-net 的报警 API 要求你先定义报警源状态再调用报警发送函数参数里要带报警类型、严重程度和相关的诊断数据。实际做产品时我建议尽早把报警通道设计进去否则后续加报警要动 GSDML 和槽位配置比一开始就设计好麻烦得多。2.3 DCP、LLDP 和设备名IP 怎么来的设备怎么被认出来PROFINET 从站和普通以太网设备一个很大区别是PLC 找从站时优先依赖“设备名”而不是 IP 地址。设备名在网络里的唯一性由 DCP 协议保证。首次上电时从站可以没有 IPPLC 或调试工具用 DCP 发送广播帧按设备名找到从站然后给它分配 IP。这里有个关键点p-net 初始化时你会配置一个name_of_station这个名字必须和 TIA Portal 里的设备名完全一致否则 PLC 永远找不到设备。LLDP 则用于拓扑识别让交换机、PLC 知道这个端口对端接了什么设备。它不直接参与数据交换但现场维护时很有用很多高级诊断界面依赖 LLDP 画网络拓扑。p-net 默认支持 LLDP 发送建议保持开启不要为了省几个字节的数据关闭它。3. 搭建工程下载源码、移植层和编译3.1 源码目录结构哪些文件该改哪些不该动从 GitHub 拉下 p-net 源码后你会看到它分成大致三块一是src/里是协议栈核心实现这部分正常不需要动它实现 DCP、LLDP、IO 状态机、报警等协议细节二是src/ports/是平台相关层p-net 叫pnalp-net abstraction layer里面有 Linux 下对网络接口、操作系统时钟、互斥锁的适配三是配置解析层较新版本用 JSON 描述设备配置运行时会解析成内部配置结构体。我的建议是协议栈核心碰都不要碰那里面有太多协议时序细节改错了你排查三天都不知道问题在哪。你需要改的就是 ports 目录里的网络接口实现以及应用层调用代码。如果是全新硬件核心精力一定集中在让 pnal 层跑通。3.2 pnal 层到底在适配什么pnal 层在 Linux 里主要做两件事发收以太网帧、提供操作系统服务。网络接口这块p-net 使用 Linux 的原始套接字AF_PACKET直接收发 PROFINET 帧它绕过了 TCP/IP 协议栈才能保证实时性。你需要做的是把网卡的名字、MAC 地址、VLAN 配置交给 pnal 初始化函数。操作系统服务则是线程、时钟、互斥锁这些基本功Linux 下大多已经有默认实现。如果你是第一次移植先用一块常见的 USB 网卡或者板载千兆网卡在普通 Linux 上跑通官方 demo确认能收到 PLC 帧再考虑换到特定工控网卡。工控网卡有时会有厂商私有驱动影响帧收发这点后面实测部分细说。3.3 交叉编译和第一次运行验证p-net 支持 CMake 构建本地编译最简单cmake -B build cmake --build build就能出可执行文件。交叉编译时额外指定工具链文件即可比如-DCMAKE_TOOLCHAIN_FILE../toolchain-arm.cmake。依赖很少基本就是 pthread 和标准库对老 ARM 平台也很友好。第一次上板跑不要着急接 PLC先在终端里看启动日志有没有打印出设备名、MAC、IP 和槽位配置。没有异常就继续下一步。如果你手上有西门子官方的 PSTPrimary Setup Tool直接扫描网络能看到一个 DCP 设备出现在列表里名字和你在配置里写的一致说明协议栈底层已经活了。4. 把设备建模成 PROFINET 从站槽位、子槽位与数据区4.1 模块化设备模型从站不是“一块裸板”PROFINET 设备模型采用插槽概念类似机架式 PLC 的导轨插槽。一个从站设备由若干插槽Slot组成每个插槽里可以插入一个模块模块下又有子模块。子模块才是真正承载 IO 数据的实体每个子模块有独立的输入数据长度、输出数据长度和子模块标识号。这样设计的好处是GSDML 描述文件和 PLC 组态可以灵活组合同一台硬件通过插槽配置就能呈现不同的 IO 布局。p-net 的配置里你要定义每个模块的module_ident和每个子模块的submodule_number、输入长度、输出长度、子模块标识。这些编号必须和 GSDML 里的ModuleIdentNumber、SubmoduleIdentNumber严格对应差一个字节 PLC 都会报组态错误。4.2 JSON 配置和 pnet_api 代码骨架p-net 的设备配置我用过的是 JSON 方式核心内容大致如下{ station_name: pnet-demo-device, ip: 192.168.1.20, netmask: 255.255.255.0, mac_address: 02:00:00:aa:bb:01, vendor_id: 0x0002, device_id: 0x0001, modules: [ { module_ident: 1, submodules: [ { subslot_number: 1, input_length: 8, output_length: 8, ident: 1 } ] } ] }字段含义很直观input_length是从站往 PLC 方向发送的数据长度output_length是 PLC 往从站方向写的数据长度。多少字节完全看你的实际数据量常见的数字量 IO 也就几个字节模拟量或编码器数据会到几十字节。应用启动后你通过 pnet_api 的接口拿到某个子模块的输入输出数据指针然后拷贝应用数据即可。4.3 IO 数据区和 PLC 地址的映射逻辑这一步是很多人卡住的地方p-net 里一个子模块有 8 字节输出PLC 侧到底地址是多少答案不取决于你的 JSON而取决于 TIA Portal 里给这个设备分配的“IO 起始地址”。比如你在 TIA 里给设备分配输出起始地址为 IW64那么这个子模块的第 1、2 字节就是 IW64第 3、4 字节就是 IW66依次类推。注意 PROFINET 的字节序是大端还是小端问题。p-net 里一般按字节数组给你PLC 侧如果按字读高低字节顺序必须测一遍再定属于最容易踩的隐性坑。我的习惯是第一个字节放一个固定值如 0xAA第二个字节放 0x55接上 PLC 看一眼读出来哪个在前一次就能确认字节序。5. GSDML、TIA Portal 和地址对应实战5.1 手工写一份最小可用的 GSDMLGSDML 是 PROFINET 设备的“身份证”本质上是一份 XML 文件记录厂商 ID、设备 ID、模块列表、数据长度、设备访问参数。TIA Portal 靠它知道怎么组态你的从站。p-net 的 demo 里通常带一份示例 GSDML你可以改厂商 ID、设备 ID、站名和模块长度来适配自己设备。关键字段就那几个VendorID和DeviceID要和 p-net JSON 配置一致ModuleList和SubmoduleList列出插槽里的模块和子模块标识号、输入输出长度MinDeviceInterval最小通讯周期写 8ms 或 16ms 比较稳妥NameOfStation默认站名TIA 里可以改但第一次联调用默认值最省事。我不建议第一版就做一大堆模块先一个槽位、一个子模块、几个字节数据跑通后面再扩充。5.2 在 TIA Portal 里安装和组态TIA Portal 安装 GSDML 的路径是“选项—管理通用站描述文件GSD”选中你的 XML 文件安装然后网络视图里会多出一个设备条目。拖进网络后双击设备在“以太网地址”里填上设备名比如你自己定义的pnet-demo-deviceIP 地址会自动分配或者手动填。再进设备视图把对应模块拖到插槽上系统会显示每个子模块的输入输出地址。这一步如果 GSDML 和 p-net 配置有出入TIA 会直接提示组态不一致回去检查 JSON 里的module_ident或者 GSDML 里的模块编号就行。5.3 西门子 PLC 与安川机器人地址对应的现实问题现场最常被问到的问题是“西门子 PLC 和安川机器人 PROFINET 通讯地址怎么对应”。其实原理一致机器人侧有一个 PROFINET 从站接口PLC 侧安装机器人厂家的 GSDML 后在 TIA 里组态。机器人控制器里比如安川 YRC1000 的工业网络设置界面你设置从站设备名、IP、输入输出数据长度还会有一个“内部寄存器/IO 映射表”决定机器人内部变量对应到 PROFINET 数据区的哪个字。PLC 侧则根据 GSDML 模块布局分配 IO 起始地址。实际操作时把两边看成“字节管道”PLC 的输出地址对应机器人的输入区机器人的输出区对应 PLC 的输入地址。对齐方式就是 PLC 起始地址和偏移量加上机器人内部映射地址两边必须按同一份字节序和长度表核对。经常出问题的是“字/字节顺序”因为机器人控制器的 CPU 和西门子 PLC 的字节序不同字数对不上就得在映射表里做高低字节交换。我的建议是先用一个 100 字节左右的测试块在机器人内部写一串固定的 0x01、0x02 计数PLC 读回来对比把正确的字节顺序确定后再做正式数据。发那科板卡也是同一个套路发那科机器人里配置好 PROFINET 板卡的 IP 和设备名在 PLC 侧按板卡 GSDML 组态IO 地址由模块布局决定机器人内部用“端口映射”把物理 IO 或寄存器对到 PROFINET 数据区。6. 联调排错真实 PLC 上的完整排查链路6.1 先过 DCP 和 PingIP 层面的确认拿到一个还没接通过从站不要直接上 PLC 诊断先把底层确认了。用西门子 PST 扫描能看到设备名、MAC、IP说明 DCP 层正常。随后 ping 一下设备 IP网络通至少说明以太网链路没问题。我调试时发现一个很常见的“假故障”PLC 网络里如果开了 VLANPROFINET 帧默认带 VLAN 标签和优先级而 p-net 的网卡如果不处理 VLAN部分帧会收不到。先关掉交换机端口的 VLAN 再试是排除网络环境干扰最快的方法。6.2 用 Wireshark 抓包看连接建立过程协议栈层面对不对最可信的判据是抓包。PC 上用 Wireshark抓网卡流量过滤条件写profinet先看有没有周期性 RT 帧和 DCP 帧。然后启动 PLC 执行观察有没有 AR应用关系建立请求。建立过程大概分几步PLC 发送“连接建立”请求从站返回确认双方参数协商然后 PLC 下发写记录数据配置模块和期望的槽位最后进入周期数据交换。如果抓包停在“连接建立请求没有确认”基本是你 p-net 状态机没转起来检查有没有周期调pnet_handle_periodic()或者设备名和组态名不一致。如果停在写记录阶段大概率是 GSDML 和实际槽位不匹配回到第 5 节核对标识号。6.3 从站亮红灯的典型排查方向实际现场里最让人头大的是设备红灯乱闪PLC 报“设备故障”或“Station not reachable”。按经验排查顺序很重要先看 IP设备 IP 是否和 PLC 网段一致注意 PROFINET 用的是网卡物理口不是虚拟网卡再看设备名TIA 组态的设备名必须和 p-net 配置完全一致大小写都算斜杠、空格也算然后看连接周期TIA 里设置的更新时间要和 GSDML 允许的MinDeviceInterval匹配你 GSDML 写最小 16msTIA 里设了 8ms就会反复断连最后看防火墙、交换机PROFINET RT 帧是多播帧有些安全交换机默认拦截多播必须在交换机上放行 0x8892。这些方向我从实践里筛了一遍绝大多数问题出现在第二和第三点上。6.4 把通讯周期压到 1ms 时的工程限制如果你的设备对实时性有要求想把发送周期设到 1ms就要面对一个现实p-net 是纯软件栈在一颗普通 ARM 处理器上做到 1ms 稳定周期并不是必然达标。影响因素有几个CPU 调度抖动、网卡驱动的中断延迟、以及应用代码本身有没有在循环里做耗时操作。我的经验是先把周期设 4ms 或 8ms 跑稳定再尝试往下压。同时打开 Wireshark 看 IO 帧的实际到达间隔如果抖动超过 0.5ms优先检查驱动和中断合并设置。极端情况下可以配合 Linux 的 PREEMPT_RT 实时补丁或者把业务逻辑搬到另一个 CPU 核心上把协议栈线程绑在独立核。p-net 在 1ms 周期下不是不可行而是你要把整个平台调优到够格。最后想说的一点经验从我自己的项目经历来说p-net 最吸引人的地方不是“免费”而是它把 PROFINET 从站的完整协议细节摊在你面前调试过程逼着你去理解 DCP、LLDP、报警、记录数据这些概念这些东西一旦搞懂以后接任何工业以太网项目心里都有底。真正开始之前建议先在普通 Linux PC 上跑通 demo再移植到嵌入式板子分阶段调试会省非常多时间。最后分享一个小技巧所有 p-net 配置里的编号、长度、设备名我会单独建一个对照表把 GSDML 里的标识号、JSON 配置的字段、TIA 组态的设定列成三列联调时任何一端改配置先回表格确认三边一致。这个习惯帮我避开了很多明明两边都配对、却因为第三处不一致浪费整整一天的坑。
