单片机+PHY芯片+Powerlink协议实现高效数据采集探究（工业总线485和CAN的升级）

特立独行的猫a

已于 2023-05-13 10:09:31 修改

阅读量3.2k

点赞数 5

分类专栏：运动控制文章标签：网络 powerlink 工业互联网总线技术

于 2023-05-06 22:15:00 首次发布

本文链接：https://blog.csdn.net/yyz_1987/article/details/130491759

版权

运动控制专栏收录该内容

11 篇文章 15 订阅

订阅专栏

CAN总线和RS-485总线作为常用的工业通信总线，在许多工业领域中得到广泛使用。但随着工业应用的不断扩展和网络化的需求增加，它们面临着一些局限性。例如CAN总线虽然具有较高的通信速率和可靠性，但存在节点数量受限、数据传输距离短等问题。而RS-485总线虽然具有较长的传输距离和大量节点的优势，但通信速率较低、实时性差等问题。因此，寻找新的总线技术来升级已经成为当今的趋势之一。

前言

如今的网络芯片越来越便宜，单片机性能逐步提高，嵌入式终端设备网路化是趋势。

长期以来，作为汽车“神经系统”的CAN总线技术曾是汽车厂商宣传的技术亮点。然而，随着汽车科技、尤其是汽车电子科技的发展，现有的汽车“神经系统”难以满足行业发展需求。于是，不少汽车厂商开始把目光聚焦到以太网。

一方面，车联网时代的到来，让以太网在汽车领域里的应用成为一种趋势；另一方面，随着车载电子系统的日益精密，在具备自动驾驶、摄像头和信息娱乐系统等功能之后，以太网成为将其融合在一起的最佳选项。有专家预言，以太网技术在汽车上的应用，不仅会带来汽车“神经系统”的革命，也会带来整个汽车应用的变革。

常见的汽车总线一般包括LIN、K、CAN、CAN-FD、FlexRay、Ethernet 、MOST、VAN等,由于汽车行业有其特殊性（安全和干扰等因素），Powerlink协议需要一定的安全措施来保证通信数据的安全性。因此Powerlink协议的应用在汽车领域可能有一定的挑战和限制，需要进一步的研究和改进来适应汽车行业的需求。但是在其他一些安全性要求不太高的场合，如IO数据采集和控制，传统的使用485总线和can总线的场合，使用单片机+PHY芯片+Powerlink协议也是一种不错的尝试。

为何要花力气让单片机也实现互联网总线？当然是因为需求。如果对速度要求不高则现有的485总线和can总线完全满足需要，没必要折腾。但是如果对速度要求苛刻，则非工业互联网总线莫属。

为何选择Powerlink而不是其他总线？似乎其他一些总线如EtherCAT,ProflNet,M3等更流行，但这些都是不开放且需要授权，没办法改造，且造不如买的拿来主义思想很害人，假如被卡脖子的话，不知道会不会倒下一大片。

为啥powerlink感觉不火像过气了一样？一是推广不利，资料不多。二是跟商业利益有关，EtherCAT专用从站芯片一片也不到一百元，造不如买的思想，且EtherCAT生态系统相对完善，靠芯片垄断了大量市场，有众多供应商提供相关产品和服务。相比之下，Powerlink的生态系统支持仍有待提高。其实在一些大厂用的也很多，只是行业不同，不知道而已。

在伺服驱动器这块儿，Powerlink的市场份额虽然没有EtherCAT大，但它仍然是一个成熟、可靠的实时以太网协议，并在某些特定应用领域得到了广泛应用。

注：

1.CAN 的传输周期 1ms 是一个完整的数据的平均传递时间。
2.CAN 的节点数在确保可靠性的情况下，实际可达到 110 个。

powerlink中国区的推广官网地址：POWERLINK开放自动化

Ethernet POWERLINK中国用户组织

研究学习的意义？至少可以看下powerlink是如何通过以太网基础来实现的CanOpen协议？如何用UDP、TCP来实现SDO、PDO的。

powerlink协议怎么样？还有没有研究价值？看下2020年中国科技大学的研究论文就知道了，从中可以看到一些实验数据和性能指标。国产化，国人当自强不息。参见：

实时以太网POWERLINK在加速器控制系统中的应用研究 - 搜索

有篇硕士论文文献中做过一个实践，使用stm32F407ZGT6+PHY芯片DP83848CVV,采用RMII接口与stm32单片机连接，采用FreeRTOS进行轻量级任务调度，最终实现的通信周期波动区间为1~4ms,抖动约为25us的效果，满足了一些工业现场的实时性要求。论文参见：

Powerlink在热网监控系统中的应用设计 - 百度文库

如果对你有用，还是值得研究挖掘的。已经有这方面的相关专利，如：

一种用于安全控制器的Powerlink通信服务组件的制作方法

一种基于POWERLINK的工业机器人运动控制系统 - 百度学术

Powerlink协议介绍

Powerlink 是一种工业以太网现场总线协议。Ethernet POWERLINK标准化组织(EPSG)是一个独立的组织，由驱动和自动化行业的领袖企业创建于2003年。其宗旨是标准化并进一步研发POWERLINK。POWERLINK于2001年由贝加莱首先研发推出。高性能实时通信系统是IEEE 802.3以太网标准协议的扩展，确保实时数据微秒级传输。

Powerlink 协议对标准的以太网数据链路层进行了简单的修改，将 CSMA/CD 机制禁用，从而由主站完全控制网络上数据的收发过程，从而保证了严格的时间特性，实现实时通讯功能。它是一种新兴的工业总线技术，它基于以太网技术，通过使用实时以太网技术和IEEE 1588时间同步协议，实现了高可靠性、高速率、高精度和实时性的数据传输。Powerlink协议可以满足工业应用领域对数据带宽和实时性的需求，同时提供高度灵活和可扩展的网络架构。

Powerlink对比EtherCAT

这个问题经常会被人问及。总的来说，POWERLINK和EtherCAT性能差不多。对于POWERLINK，一个主站带10个从站的网络，最小的循环周期为100μs左右；对于EtherCAT，一个主站带10个从站的网络，最小的循环周期为100～400μs，取决于用户添加的应用层以及主站的性能。此外，EtherCAT当初是根据机器设备的控制需求制定的方案；而POWERLINK当初的设计目标是工业现场总线，除了可以用于机器控制，还可以用于过程控制、DCS系统等。

POWERLINK是一项公共且公开的技术，任何单位或者个人都可以无偿将其用于各种用途。
POWERLINK的实现方案之一openPOWERLINK是一套开源的解决方案，它遵循BSD许可，也就是说POWERLINK的使用者对该技术拥有知识产权。
EtherCAT是一项私有技术，它属于Beckhoff公司，使用这项技术的人需要向Beckhoff公司支付许可费用，即使是用户根据EtherCAT技术标准自己开发的方案，也需要支出许可费用。

openPOWERLINK 介绍

openPOWERLINK 协议栈可用作通用源代码版本，可轻松移植到各种目标和操作系统。是POWERLINK协议的一个开源实现。它基于Ethernet技术和POWERLINK协议，提供高速、实时、可靠的通信服务。不仅支持以太网的基本通信服务，还提供了POWERLINK协议的高级特性，如同步机制、节点管理、诊断和故障处理等功能。可以用于各种实时应用领域，如工业自动化、机器人控制、医疗设备、航空航天等，为各种实时应用提供高速、实时、可靠的通信服务。

github地址：GitHub - OpenAutomationTechnologies/openPOWERLINK_V2: Release 2 of the openPOWERLINK protocol stack

源码地址：

Download openPOWERLINK

文档地址：openPOWERLINK :: openPOWERLINK :: Documentation

移植指导文档：openPOWERLINK: openPOWERLINK Porting Guide

CANopen协议介绍

POWERLINK 总线在以太网基础来实现的CanOpen协议，因此了解CANopen协议至关重要。

目前CANopen通讯协议已经在工业领域得到了广泛的使用，由于其面向对象的设计思路，CANopen协议已成为欧洲等国家的自动化公司标配的通讯接口之一。

什么是CANopen?

CANopen是一种基于CAN的通信协议。这项协议非常有用，因为它可以让设备、节点（如工业机械）之间具有现成的互操作性，以及它提供了安装前和安装后配置设备的标准方法。CANopen最初是为面向运动的机器控制系统设计的，如今，它被广泛用于电机控制（步进/伺服电机）领域，并在以下应用中得到广泛使用：

机器人技术：包括自动化机器人、传送带和其他工业机械

医疗：包括X射线发生器、注射器、病人床和透析设备

汽车：包括农业、铁路、拖车、重型汽车和船舶等

CANopen是一个基于CAN总线的“高层协议”，这意味着CAN总线（ISO 11898）就像集装箱的卡车一般作为CANopen信息的“运输工具”。在OSI模型中，CAN总线代表两个最低层（物理层和数据链路层）。这意味着CAN只是实现了带有11位CAN ID、远程传输（RTR）位和64个数据位（与更高层的协议相关）的字段的帧的传输。换言之，CAN总线在CANopen中的作用与在J1939协议相同，而CANopen则实现了OSI模型的第七层，并能够适应除CAN以外的其他数据链路层协议（例如EtherCAT、Modbus、Powerlink）。

值得关注的是，随着CAN FD的推出，CANopen FD作为下一代CANopen标准，可能会发挥着越来越重要的作用。具体细节欢迎到CiA官网中查看。

相较于CAN总线和J1939协议，CANopen协议新增了以下6个核心概念：

通信模式

设备/节点的通信有3种模式：主/从站、客户端/服务器和生产者/消费者。

通信协议

用于通信的协议，如配置节点（SDO）或传输实时数据（PDO）等。

设备状态

单个设备支持不同的状态。一个“主站”节点可以改变一个“从站”节点，包括重置等操作。

对象字典

每个设备都有一个OD，其中有指定设备配置等的条目，它可以通过SDO访问。

电子数据表

EDS是OD条目的标准文件格式，它允许服务工具来更新设备。

设备设置文件

描述了I/O模块（CiA 401）和运动控制（CiA 402）等供应商独立性

CANopen通信基础知识

Basic knowledge of CANopen communication

在CANopen网络中，需要多个设备进行通信，例如，在工业自动化设置中，你可能有一个带有多个伺服电机节点和一个控制接口/PC节点的机械臂。为了促进通信，CANopen中存在着三种模式，每种模式都与我们所讨论的CANopen协议紧密相连。下面将简单介绍这三种模式：

CANopen通信的三种模式

01 主/从站

一个节点（例如控制接口）作为应用主站或主控制器。它向从站设备（例如伺服电机）请求数据。这个过程被用于诊断或状态管理。在标准应用中，可以有0到127个从站。请注意：在单个CANopen网络中，可以有不同的主机控制器共享同一个数据链路层。

服务示例：NMT

02 客户端/服务器

客户端向服务器发送数据请求，服务器回复请求的数据。例如，当应用程序主站需要从站的OD中获取数据时使用这一模式。从服务器上读取是一种 "上传"，而“写入”是一种 "下载"（该术语采用服务器端的角度）。

服务示例：SDO

03 消费者/生产者

该模式中生产者节点向网络广播数据，由消费者节点消费。生产者根据请求（拉模型）或没有特定请求（推模型）发送此数据。

服务示例：心跳

显然，这些模型实际上是相同的，但为了术语的一致性才对对它们进行了区分。

POWERLINK通信实验

实验powerlink的通信还是容易的，不需要特殊的网卡硬件，两台电脑就可以。

或者一台电脑作为主节点，通过网口外接到一个嵌入式主板或单片机+PHY芯片的板子上实现通信。因现有条件不具备，以下仅在windows两台电脑间做了通信。openpowerlink源码结构分层清晰且代码量也不大，想移植到单片机环境中应该也不是什么难事。

Software Architecture：

The following picture shows the software architecture of the openPOWERLINK stack.

实验的整个过程涉及XDD文件配置、openconfigurator的配置、openpowerlink的appDemo源码的更改，电脑基于powerlink的以太网通信、利用Wireshark进行传输数据分析。调试时如果不通过openconfigurator配置也可以，需手工修改字典objdict.h文件中的内容，这需要搞懂PDO通信参数的映射关系。

源码编译

源码编译比较简单，源码结构清晰，推荐使用cmake工具。

源码地址：
https://sourceforge.net/projects/openpowerlink/

mnobd.cdc文件介绍
此文件用于配置 MN 堆栈。它包括MN和所有CN的所有配置数据，包括网络映射信息。CN 配置由 MN 的配置管理器（CFM）模块处理。mnobd.cdc 文件地址在
openPOWERLINK_V2.7.2\apps\common\openCONFIGURATOR_projects\Demo_3CN\output

用于配置 MN 堆栈。它包括MN和所有CN的所有配置数据，包括网络映射信息。CN 配置由 MN 的配置管理器（CFM）模块处理。该文件由openCONFIGURATOR工具生成。手工改映射关系是麻烦的，可通过openCONFIGURATOR工具实现。

mnobd.txt

此文件以人类可读的格式描述堆栈配置。它包括MN和所有CN的所有配置数据，包括网络映射信息。此文件仅用于诊断目的。

xap.xml

XML 文件包含进程映像的结构定义。这取决于应用程序中使用的CN的可用数据字段。应用程序可以分析 xml 文件，从而获取有关进程映像中映射的通道偏移的信息。

xap.h

头文件包含两个 ANSI C 结构形式的进程映像的结构定义。它可以直接包含在应用程序中。

编译日志

====================[ Build | oplkmn | Debug ]==================================
"D:\Program Files\CMake\bin\cmake\win\bin\cmake.exe" --build E:\test\cpp\openPOWERLINK_V2.7.2\stack\cmake-build-debug --target oplkmn
[1/80] Building C object proj\windows\liboplkmn\CMakeFiles\oplkmn.dir\__\__\__\src\user\pdo\pdoucal-triplebufshm.c.obj
[2/80] Building C object proj\windows\liboplkmn\CMakeFiles\oplkmn.dir\__\__\__\src\user\event\eventu.c.obj
[3/80] Building C object proj\windows\liboplkmn\CMakeFiles\oplkmn.dir\__\__\__\src\user\obd\obdal.c.obj
[4/80] Building C object proj\windows\liboplkmn\CMakeFiles\oplkmn.dir\__\__\__\src\user\obd\obdu.c.obj
[5/80] Building C object proj\windows\liboplkmn\CMakeFiles\oplkmn.dir\__\__\__\src\user\api\processimage.c.obj
[6/80] Building C object proj\windows\liboplkmn\CMakeFiles\oplkmn.dir\__\__\__\src\user\nmt\identu.c.obj
[7/80] Building C object proj\windows\liboplkmn\CMakeFiles\oplkmn.dir\__\__\__\src\user\nmt\statusu.c.obj
[8/80] Building C object proj\windows\liboplkmn\CMakeFiles\oplkmn.dir\__\__\__\src\user\api\service.c.obj
[9/80] Building C object proj\windows\liboplkmn\CMakeFiles\oplkmn.dir\__\__\__\src\user\api\generic.c.obj
[10/80] Building C object proj\windows\liboplkmn\CMakeFiles\oplkmn.dir\__\__\__\src\user\api\sdotest.c.obj
[11/80] Building C object proj\windows\liboplkmn\CMakeFiles\oplkmn.dir\__\__\__\src\user\dll\dllucal.c.obj
[12/80] Building C object proj\windows\liboplkmn\CMakeFiles\oplkmn.dir\__\__\__\src\user\nmt\nmtcnu.c.obj
[13/80] Building C object proj\windows\liboplkmn\CMakeFiles\oplkmn.dir\__\__\__\src\user\nmt\nmtu.c.obj
[14/80] Building C object proj\windows\liboplkmn\CMakeFiles\oplkmn.dir\__\__\__\src\user\nmt\nmtmnu.c.obj
[15/80] Building C object proj\windows\liboplkmn\CMakeFiles\oplkmn.dir\__\__\__\src\user\pdo\pdoucal.c.obj
[16/80] Building C object proj\windows\liboplkmn\CMakeFiles\oplkmn.dir\__\__\__\src\user\sdo\sdoudp.c.obj
[17/80] Building C object proj\windows\liboplkmn\CMakeFiles\oplkmn.dir\__\__\__\src\user\pdo\pdou.c.obj
[18/80] Building C object proj\windows\liboplkmn\CMakeFiles\oplkmn.dir\__\__\__\src\user\sdo\sdoseq.c.obj
[19/80] Building C object proj\windows\liboplkmn\CMakeFiles\oplkmn.dir\__\__\__\src\user\sdo\sdotest-seq.c.obj
[20/80] Building C object proj\windows\liboplkmn\CMakeFiles\oplkmn.dir\__\__\__\src\user\sdo\sdocom.c.obj
[21/80] Building C object proj\windows\liboplkmn\CMakeFiles\oplkmn.dir\__\__\__\src\user\sdo\sdotest-com.c.obj
[22/80] Building C object proj\windows\liboplkmn\CMakeFiles\oplkmn.dir\__\__\__\src\user\sdo\sdocomsrv.c.obj
[23/80] Building C object proj\windows\liboplkmn\CMakeFiles\oplkmn.dir\__\__\__\src\user\sdo\sdocomclt.c.obj
[24/80] Building C object proj\windows\liboplkmn\CMakeFiles\oplkmn.dir\__\__\__\src\user\nmt\syncu.c.obj
[25/80] Building C object proj\windows\liboplkmn\CMakeFiles\oplkmn.dir\__\__\__\src\user\timesync\timesyncu.c.obj
[26/80] Building C object proj\windows\liboplkmn\CMakeFiles\oplkmn.dir\__\__\__\src\user\sdo\sdocom-dummy.c.obj
[27/80] Building C object proj\windows\liboplkmn\CMakeFiles\oplkmn.dir\__\__\__\src\user\sdo\sdoasnd.c.obj
[28/80] Building C object proj\windows\liboplkmn\CMakeFiles\oplkmn.dir\__\__\__\src\user\sdo\sdocom-std.c.obj
[29/80] Building C object proj\windows\liboplkmn\CMakeFiles\oplkmn.dir\__\__\__\src\user\errhnd\errhndu.c.obj
[30/80] Building C object proj\windows\liboplkmn\CMakeFiles\oplkmn.dir\__\__\__\src\user\obd\obdcdc.c.obj
[31/80] Building C object proj\windows\liboplkmn\CMakeFiles\oplkmn.dir\__\__\__\src\user\sdo\sdoudp-windows.c.obj
[32/80] Building C object proj\windows\liboplkmn\CMakeFiles\oplkmn.dir\__\__\__\src\user\timer\timer-generic.c.obj
[33/80] Building C object proj\windows\liboplkmn\CMakeFiles\oplkmn.dir\__\__\__\src\user\dll\dllucal-circbuf.c.obj
[34/80] Building C object proj\windows\liboplkmn\CMakeFiles\oplkmn.dir\__\__\__\src\user\event\eventucal-win32.c.obj
[35/80] Building C object proj\windows\liboplkmn\CMakeFiles\oplkmn.dir\__\__\__\src\user\errhnd\errhnducal-local.c.obj
[36/80] Building C object proj\windows\liboplkmn\CMakeFiles\oplkmn.dir\__\__\__\src\user\pdo\pdoucalmem-local.c.obj
[37/80] Building C object proj\windows\liboplkmn\CMakeFiles\oplkmn.dir\__\__\__\src\user\timesync\timesyncucal-local.c.obj
[38/80] Building C object proj\windows\liboplkmn\CMakeFiles\oplkmn.dir\__\__\__\src\user\event\eventucalintf-circbuf.c.obj
[39/80] Building C object proj\windows\liboplkmn\CMakeFiles\oplkmn.dir\__\__\__\src\user\ctrl\ctrlucal-direct.c.obj
[40/80] Building C object proj\windows\liboplkmn\CMakeFiles\oplkmn.dir\__\__\__\src\user\cfmu.c.obj
[41/80] Building C object proj\windows\liboplkmn\CMakeFiles\oplkmn.dir\__\__\__\src\user\ctrl\ctrlu.c.obj
[42/80] Building C object proj\windows\liboplkmn\CMakeFiles\oplkmn.dir\__\__\__\src\kernel\dll\dllkstatemachine.c.obj
[43/80] Building C object proj\windows\liboplkmn\CMakeFiles\oplkmn.dir\__\__\__\src\kernel\dll\dllkfilter.c.obj
[44/80] Building C object proj\windows\liboplkmn\CMakeFiles\oplkmn.dir\__\__\__\src\kernel\timesync\timesynck.c.obj
[45/80] Building C object proj\windows\liboplkmn\CMakeFiles\oplkmn.dir\__\__\__\src\kernel\led\ledk.c.obj
[46/80] Building C object proj\windows\liboplkmn\CMakeFiles\oplkmn.dir\__\__\__\src\kernel\dll\dllk.c.obj
[47/80] Building C object proj\windows\liboplkmn\CMakeFiles\oplkmn.dir\__\__\__\src\kernel\errhnd\errhndk.c.obj
[48/80] Building C object proj\windows\liboplkmn\CMakeFiles\oplkmn.dir\__\__\__\src\kernel\ctrl\ctrlk.c.obj
[49/80] Building C object proj\windows\liboplkmn\CMakeFiles\oplkmn.dir\__\__\__\src\kernel\pdo\pdokcal-triplebufshm.c.obj
[50/80] Building C object proj\windows\liboplkmn\CMakeFiles\oplkmn.dir\__\__\__\src\kernel\errhnd\errhndkcal.c.obj
[51/80] Building C object proj\windows\liboplkmn\CMakeFiles\oplkmn.dir\__\__\__\src\kernel\dll\dllknode.c.obj
[52/80] Building C object proj\windows\liboplkmn\CMakeFiles\oplkmn.dir\__\__\__\src\kernel\pdo\pdokcal.c.obj
[53/80] Building C object proj\windows\liboplkmn\CMakeFiles\oplkmn.dir\__\__\__\src\kernel\dll\dllkframe.c.obj
[54/80] Building C object proj\windows\liboplkmn\CMakeFiles\oplkmn.dir\__\__\__\src\kernel\dll\dllkevent.c.obj
[55/80] Building C object proj\windows\liboplkmn\CMakeFiles\oplkmn.dir\__\__\__\src\kernel\nmt\nmtk.c.obj
[56/80] Building C object proj\windows\liboplkmn\CMakeFiles\oplkmn.dir\E_\test\cpp\openPOWERLINK_V2.7.2\contrib\trace\trace-windows.c.obj
[57/80] Building C object proj\windows\liboplkmn\CMakeFiles\oplkmn.dir\__\__\__\src\kernel\timesync\timesynckcal-local.c.obj
[58/80] Building C object proj\windows\liboplkmn\CMakeFiles\oplkmn.dir\__\__\__\src\kernel\event\eventkcal-win32.c.obj
[59/80] Building C object proj\windows\liboplkmn\CMakeFiles\oplkmn.dir\__\__\__\src\kernel\dll\dllkcal-circbuf.c.obj
[60/80] Building C object proj\windows\liboplkmn\CMakeFiles\oplkmn.dir\__\__\__\src\kernel\pdo\pdoklut.c.obj
[61/80] Building C object proj\windows\liboplkmn\CMakeFiles\oplkmn.dir\__\__\__\src\kernel\event\eventk.c.obj
[62/80] Building C object proj\windows\liboplkmn\CMakeFiles\oplkmn.dir\__\__\__\src\common\debugstr.c.obj
[63/80] Building C object proj\windows\liboplkmn\CMakeFiles\oplkmn.dir\__\__\__\src\kernel\ctrl\ctrlkcal-direct.c.obj
[64/80] Building C object proj\windows\liboplkmn\CMakeFiles\oplkmn.dir\__\__\__\src\kernel\pdo\pdok.c.obj
[65/80] Building C object proj\windows\liboplkmn\CMakeFiles\oplkmn.dir\__\__\__\src\kernel\event\eventkcalintf-circbuf.c.obj
[66/80] Building C object proj\windows\liboplkmn\CMakeFiles\oplkmn.dir\__\__\__\src\kernel\timer\hrestimer-windows.c.obj
[67/80] Building C object proj\windows\liboplkmn\CMakeFiles\oplkmn.dir\__\__\__\src\kernel\edrv\edrvcyclic.c.obj
[68/80] Building C object proj\windows\liboplkmn\CMakeFiles\oplkmn.dir\__\__\__\src\kernel\dll\dllkcal.c.obj
[69/80] Building C object proj\windows\liboplkmn\CMakeFiles\oplkmn.dir\__\__\__\src\kernel\edrv\edrv-pcap_win.c.obj
[70/80] Building C object proj\windows\liboplkmn\CMakeFiles\oplkmn.dir\__\__\__\src\kernel\errhnd\errhndkcal-local.c.obj
[71/80] Building C object proj\windows\liboplkmn\CMakeFiles\oplkmn.dir\__\__\__\src\common\memmap\memmap-null.c.obj
[72/80] Building C object proj\windows\liboplkmn\CMakeFiles\oplkmn.dir\__\__\__\src\kernel\led\ledktimer.c.obj
[73/80] Building C object proj\windows\liboplkmn\CMakeFiles\oplkmn.dir\__\__\__\src\arch\windows\target-mutex.c.obj
[74/80] Building C object proj\windows\liboplkmn\CMakeFiles\oplkmn.dir\__\__\__\src\kernel\pdo\pdokcalmem-local.c.obj
[75/80] Building C object proj\windows\liboplkmn\CMakeFiles\oplkmn.dir\__\__\__\src\arch\windows\target-windows.c.obj
[76/80] Building C object proj\windows\liboplkmn\CMakeFiles\oplkmn.dir\__\__\__\src\common\circbuf\circbuf-win32.c.obj
[77/80] Building C object proj\windows\liboplkmn\CMakeFiles\oplkmn.dir\__\__\__\src\arch\windows\netif-windows.c.obj
[78/80] Building C object proj\windows\liboplkmn\CMakeFiles\oplkmn.dir\__\__\__\src\common\circbuf\circbuffer.c.obj
[79/80] Building C object proj\windows\liboplkmn\CMakeFiles\oplkmn.dir\__\__\__\src\common\ami\amix86.c.obj
[80/80] Linking C static library proj\windows\liboplkmn\oplkmn_d.lib

Build finished

openCONFIGURATOR 下载

openCONFIGURATOR 是一个开源配置框架，用于轻松设置、配置和维护任何 POWERLINK ( https://goo.gl/U9tjiy）网络。它完美地补充了 openPOWERLINK，这是用于主站和从站的开源 POWERLINK 协议栈。最新项目由一个实现配置算法的核心库和一个 Eclipse 插件基础用户界面组成。之前就版本1.4.1可独立安装（需要依赖ActiveTcl8.6的32bit）。

新版下载地址：openCONFIGURATOR download | SourceForge.net

旧版本1.4.1下载地址： https://master.dl.sourceforge.net/project/openconf/openCONFIGURATOR/1.4/1.4.1/openCONFIGURATOR-1.4.1-win32-x86.zip?viasf=1

旧版需要依赖ActiveTcl（32位），ActiveTcl8.6.4.1(windows x86)下载地址：https://download.csdn.net/download/qwer012345678/9859168

工具使用手册：https://master.dl.sourceforge.net/project/openconf/openCONFIGURATOR/1.4/1.4.1/UserManual_V1.4.1.pdf?viasf=1

PDO的通信参数映射关系

PDO是process data object的缩写。简单地说，可以理解为数据桢。在POWERLINK 通信过程中，如果某个节点需要将自己对象字典中的多个object周期性地发送出去，就需要将这些要发送的 object 组成一个数据桢，发送到网络上。这个数据桢，就称为 PDO。向外发送的PDO，称之为TPDO; 接收到的 PDO，称之为 RPDO。PDO的传输类型是连续的，不提供“基于事件”或“基于改变”传输类型，也就是无论实时数据是否有变化，PDO的数据都是周期性的发送，这一点有别于传统的CANopen。

看一个powerlink网络的例子：

在这个例子中，有主站（PLC）, 1 号从站（IO 站）， 2 号从站（伺服驱动器），3号从站（传感器），这些设备共同组成一个网络。

这就涉及到一些问题：
1．对于每一个设备他需要将自己的哪些 object 发送到网络上？
2．这些 object 如何组成一个数据桢，即这些 object 在数据桢中的位置排列？
3．由于 POWERLINK 支持交叉通信，也就是说上述例子中的伺服驱动器可以接收
来自 PLC 的数据，也能接收来自传感器和 IO 站的数据。伺服是否需要接收某个传感器和 IO 站的数据？以及接收哪些数据？
4．每个设备该如何解析收到的数据包？

这些问题需要通过配置通信参数和映射参数来解决。

通信参数：决定该节点需要接收来自哪个节点的数据，或者将数据发送给哪个节点。对于从节点，由于发送数据桢是广播的，因此不需要设置该参数；对于主站的发送数据桢 Preq，需要设置该参数，来标示该数据桢是发送给哪个从节点的。

映射参数：决定该节点如何组成要发送的数据包或者如何解析收到的数据包。也就是确定对象字典中的对象（Object）与数据包中数据段的对应关系。

每个 POWERLINK 节点接收和发送数据时，都有一组通信参数和映射参数来描述。

对于接收：
0x1400-0x14ff：为通信参数
0x1600-0x16ff：为映射参数
通信参数和映射参数成对出现，一一对应。0x1400 与 0x1600 为一对；0x1401 与 0x1601为一对；0x14xx 与 0x16xx 为一对。

对于发送：
0x1800-0x18ff：为通信参数
0x1A00-0x1Aff：为映射参数
通信参数和映射参数成对出现，一一对应。0x1800 与 0x1A00 为一对；0x1801 与 0x1A01为一对；0x18xx 与 0x1Axx 为一对。

一、从站发送之通信参数(0x18XX)

该参数描述此节点需要把自己的数据帧发送给网络中的哪个节点（根据节点号区分）。从我们前面讲的 POWERLINK 基本原理可知，每个从站在上报自己数据的时候，都是以广播的形式发送，也就是说从站发送数据的时候，发送的目标地址是 255。因此所有从节点的发送数据的通信参数都是255。

一个 POWERLINK 数据帧最大为 1500 个字节，节点在发送数据时，可以把很多参数打包成一个大的数据帧。所以在 POWERLINK 网络中，一个从节点每个循环周期只需要发送一个数据帧就够了。因此对于从节点，我们只需要实现并使用 0x1800 就够了。

二、从站发送之映射参数(0x1AXX)

由于通信参数和映射参数成对出现，一一对应。0x1800 与 0x1A00 为一对；因此对于从节点，当你使用 0x1800 作为通信参数时，那么你就必须使用 0x1A00 作为映射参数。映射参数解决的是对象字典中的对象 Object（即参数）与数据帧中数据段的对应关系。对于发送来说，也就是如何将要发送的Object 组成一个数据帧。

如下图，描述了一个数据帧和一个对象字典中需要发送的对象。现在需要将这些要发送的参数，组成一个数据帧。也就是把每一个要发送的 Object 与某一个数据段建立映射关系,把 Object 的值放到数据帧中对应的字段。

假如我们想建立如下映射关系：

即：

对象 0x2000/02 放在数据帧偏移量为 0 的地方，长度为 16bits，

对象 0x6000/01 放在数据帧偏移量为 16 的地方，长度为 16bits；

对象 0x6000/02 放在数据帧偏移量为 32 的地方，长度为 8bits；

对象 0x2000/01 放在数据帧偏移量为 40 的地方，长度为 16bits；

为此，我们需要将 0x1A00 的值配置如下：

0x1A00/0x01 值: 0x0010000000022000
0x1A00/0x02 值: 0x0010001000016000
0x1A00/0x03 值: 0x0008002000026000
0x1A00/0x04 值: 0x0010002800012000

下面来详细解释一下第一句话的意思，“0x1A00/0x01 值 0x0010000000022000”

0x1A00/0x01 是用来描述第一个 Object 与数据帧中字段的映射关系的参数，把他的值设为0x0010000000022000，意思是将索引为 0x2000 子索引为 0x02 的对象映射到数据帧偏移量为 0x0000 (数据帧开头)的地方，长度为 16bits。

三、从站接收之通信参数(0x14XX)

该参数描述了此节点需要接收来自哪个节点的数据。从前面讲述的 POWERLINK 基本原理可知，POWERLINK 支持交叉通信，因此每一个节点都可以接收来自另外一个或多个节点的数据。所以一个节点可以有多个接收通道。例如 0x1400 是一个通道，接收来自主节点的数据，那么就把 0x1400/0x01 的值设为 0（默认值设为 0，表示接收来自主站的请求数据）；0x1401 是一个通道，接收来自 3 号节点的数据，那么就把 0x1401/0x01 的值设为 3，这样该节点在同一个循环周期里既接收来自主站的数据，也接收来自 3 号节点的数据。

四、从站接收之映射参数(0x16XX)

由于通信参数和映射参数成对出现，一一对应。0x1400 与 0x1600 为一对，0x1401 与0x1601 为一对…；因此对于从节点，当你使用 0x1400 作为通信参数时，那么你就必须使用0x1600 作为映射参数。映射参数解决的是对象字典中的对象 Object（即参数）与数据帧中数据段的对于关系。对于接收来说，也就是如何将一个数据帧进行解析。因为某个节点发来的数据，往往是多个 Object 打包在一起的，接收方需要知道自己应该接收数据帧的哪一段或者哪几段，数据长度多长。

如下图，描述了一个数据帧，和对象字典中的对象。现在需要将收到的数据帧中的数据段和对象字典中的 Object 建立映射关系。

假如我们想建立如下映射关系：

即接收到的数据帧中数据段与 Object 的映射关系：
数据帧偏移量为 0，长度为 16bits，这段数据被截取放到对象 0x2000/02；
数据帧偏移量为 16，长度为 16bits，这段数据被截取放到对象 0x6000/01；
数据帧偏移量为 32，长度为 8bits，这段数据被截取放到对象 0x6000/02；
数据帧偏移量为 40，长度为 16bits，这段数据被截取放到对象 0x2000/01。

为此，我们需要将 0x1600 的值配置如下：
0x1600/0x01 值： 0x0010000000022000
0x1600/0x02 值： 0x0010001000016000
0x1600/0x03 值： 0x0008002000026000
0x1600/0x04 值： 0x0010002800012000

下面来详细解释第二句话的意思，“0x1600/0x02 值 0x0010001000016000”。

0x1600/0x02 是用来描述第二个 Object 与数据帧中字段的映射关系的参数，把他的值设为 0x0010001000016000，意思是数据帧中偏移量为 0x0010（第 16 bit 开始），长度为 0x0010（16bits）的这段数据映射到索引为 0x6000 子索引为 0x01 的对象。

五、主站发送参数的配置

主站和从站的区别：每个循环周期，从站只需要发送一个 TPDO 的数据帧。

而主站如果基于请求/应答模式，一个循环周期需要向网络中所有的节点都发送一次请求数据帧 Preq，而且相应的也会收到从站的回复 Pres，一个 Preq 数据帧就是一个 TPDO,而一个 Pres 数据帧，就是一个 RPDO。这也就意味着主站在发送时，需要有多个发送 TPDO的通道；在接收时，需要有多个接收 RPDO 的通道。举例来说，假如一个系统里，有 1 个主节点和 3 个从节点。此时主站需要 3 个发送通道和 3 个接收通道。

对于主站的发送需要如下配置：