CAN bus and RS-485 bus, as commonly used industrial communication buses, are widely used in many industrial fields. But as industrial applications continue to expand and the need for networking increases, they face some limitations. For example, although the CAN bus has high communication speed and reliability, it has problems such as limited number of nodes and short data transmission distance. Although the RS-485 bus has the advantages of longer transmission distance and a large number of nodes, it has problems such as low communication rate and poor real-time performance. Therefore, looking for new bus technology to upgrade has become one of the current trends.

foreword

Today's network chips are getting cheaper and cheaper, the performance of single-chip microcomputers is gradually improving, and the networking of embedded terminal equipment is the trend.

For a long time, the CAN bus technology as the "nervous system" of automobiles was once a technical highlight promoted by automobile manufacturers. However, with the development of automobile technology, especially automobile electronics technology, the existing "nervous system" of automobiles is difficult to meet the development needs of the industry. As a result, many car manufacturers began to focus on Ethernet.

On the one hand, the advent of the Internet of Vehicles era has made the application of Ethernet in the automotive field a trend; on the other hand, with the increasingly sophisticated automotive electronic systems, after having functions such as automatic driving, cameras, and infotainment systems, Ethernet becomes the best option to bring it together. Some experts predict that the application of Ethernet technology in automobiles will not only revolutionize the "nervous system" of automobiles, but also revolutionize the entire automobile application.

Common automotive buses generally include LIN, K, CAN, CAN-FD, FlexRay, Ethernet, MOST, VAN, etc. Due to the particularity of the automotive industry (such as safety and interference factors), the Powerlink protocol requires certain security measures to ensure communication Data Security. Therefore, the application of the Powerlink protocol in the automotive field may have certain challenges and limitations, and further research and improvement are required to meet the needs of the automotive industry. However, in other occasions where the security requirements are not too high, such as IO data acquisition and control, and the traditional use of 485 bus and can bus, it is also a good attempt to use single-chip microcomputer + PHY chip + Powerlink protocol.

Why bother to make the MCU realize the Internet bus? Of course because of demand. If the speed requirements are not high, the existing 485 bus and can bus can fully meet the needs, and there is no need to toss. But if speed is critical, the industrial Internet bus is none other than the bus.

Why choose Powerlink over other buses? It seems that some other buses such as EtherCAT, ProflNet, M3, etc. are more popular, but these are not open and require authorization, there is no way to modify them, and it is not as good as buying them. Will not fall down a large piece.

Why does powerlink feel like it's out of date? First, the promotion is unfavorable and there is not much information. The second is related to commercial interests. EtherCAT dedicated slave chips cost less than 100 yuan per chip, which is not as good as buying. Moreover, the EtherCAT ecosystem is relatively complete, relying on chips to monopolize a large number of markets, and many suppliers provide related products and services. In contrast, Powerlink's ecosystem support still needs to be improved. In fact, some large factories also use a lot, but the industry is different, so I don’t know.

In terms of servo drives, although the market share of Powerlink is not as large as that of EtherCAT, it is still a mature and reliable real-time Ethernet protocol, and has been widely used in some specific application fields.

Note:

1. The CAN transmission period of 1ms is the average transmission time of a complete data.
2. The number of CAN nodes can actually reach 110 under the condition of ensuring reliability.

Powerlink promotion official website address in China: POWERLINK open automation

Ethernet POWERLINK China User Organization

What does research mean? At least you can take a look at how powerlink implements the CanOpen protocol through the Ethernet foundation? How to use UDP and TCP to realize SDO and PDO.

What about the powerlink protocol? Is there any research value? Just look at the research papers of the University of Science and Technology of China in 2020, from which you can see some experimental data and performance indicators. Localization, Chinese people should strive for self-improvement. see:

Research on Application of Real-time Ethernet POWERLINK in Accelerator Control System- Search

There is a practice in a master's thesis document, using stm32F407ZGT6+PHY chip DP83848CVV, using RMII interface to connect with stm32 microcontroller, using FreeRTOS for lightweight task scheduling, the final communication cycle fluctuation range is 1~4ms, and the jitter is about The effect of 25us meets the real-time requirements of some industrial sites. Papers see:

Application Design of Powerlink in Heat Network Monitoring System- Baidu Library

If it works for you, it's still worth researching and digging. There are related patents in this area, such as:

A method of making a Powerlink communication service component for a safety controller

A Motion Control System for Industrial Robots Based on POWERLINK- Baidu Academic

Introduction to Powerlink protocol

Powerlink is an Industrial Ethernet fieldbus protocol. The Ethernet POWERLINK Standardization Group (EPSG) is an independent organization founded in 2003 by leading companies in the drives and automation industries. Its purpose is to standardize and further develop POWERLINK. POWERLINK was first developed and launched by B&R in 2001. The high-performance real-time communication system is an extension of the IEEE 802.3 Ethernet standard protocol, ensuring microsecond-level transmission of real-time data.

The Powerlink protocol simply modifies the standard Ethernet data link layer and disables the CSMA/CD mechanism, so that the master station completely controls the data sending and receiving process on the network, thereby ensuring strict time characteristics and realizing real-time communication functions. It is an emerging industrial bus technology, which is based on Ethernet technology. By using real-time Ethernet technology and IEEE 1588 time synchronization protocol, it realizes data transmission with high reliability, high speed, high precision and real-time performance. The Powerlink protocol can meet the data bandwidth and real-time requirements of industrial applications, while providing a highly flexible and scalable network architecture.

Powerlink vs. EtherCAT

This question is often asked. In general, POWERLINK and EtherCAT have similar performance. For POWERLINK, a master station with 10 slave stations, the minimum cycle period is about 100μs; for EtherCAT, a master station with 10 slave stations, the minimum cycle period is 100-400μs, depending on the user added The performance of the application layer and the master station. In addition, EtherCAT was originally formulated according to the control requirements of machinery and equipment; while POWERLINK was originally designed to be an industrial field bus, which can be used not only for machine control, but also for process control and DCS systems.

POWERLINK is a public and open technology, and any unit or individual can use it for various purposes free of charge.
One of the implementations of POWERLINK openPOWERLINK is an open source solution that follows the BSD license, which means that POWERLINK users own the intellectual property rights of the technology.
EtherCAT is a private technology, which belongs to Beckhoff. People who use this technology need to pay license fees to Beckhoff, even if users develop their own solutions according to the EtherCAT technical standard, they also need to pay license fees.

openPOWERLINK Introduction

The openPOWERLINK stack is available as a generic source code version that can be easily ported to various targets and operating systems. It is an open source implementation of the POWERLINK protocol. Based on Ethernet technology and POWERLINK protocol, it provides high-speed, real-time and reliable communication services. It not only supports the basic communication services of Ethernet, but also provides advanced features of POWERLINK protocol, such as synchronization mechanism, node management, diagnosis and fault handling and other functions. It can be used in various real-time application fields, such as industrial automation, robot control, medical equipment, aerospace, etc., to provide high-speed, real-time and reliable communication services for various real-time applications.

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

Source address:

Download openPOWERLINK

Document address: openPOWERLINK :: openPOWERLINK :: Documentation

Porting guide document: openPOWERLINK: openPOWERLINK Porting Guide

Introduction to CANopen protocol

The POWERLINK bus implements the CanOpen protocol on the basis of Ethernet, so it is very important to understand the CANopen protocol.

At present, the CANopen communication protocol has been widely used in the industrial field. Due to its object-oriented design idea, the CANopen protocol has become one of the standard communication interfaces for automation companies in Europe and other countries.

What is CANopen?

CANopen is a CAN-based communication protocol. The protocol is useful because it allows out-of-the-box interoperability between devices, nodes such as industrial machinery, and because it provides a standard way to configure devices before and after installation. CANopen was originally designed for motion-oriented machine control systems, today it is widely used in the field of motor control (stepper/servo motors) and is widely used in the following applications:

Robotics: includes automated robots, conveyor belts, and other industrial machinery

Medical: including X-ray generators, syringes, patient beds and dialysis equipment

Automotive: including agriculture, railways, trailers, heavy vehicles and ships, etc.

CANopen is a "high-level protocol" based on the CAN bus, which means that the CAN bus (ISO 11898) is like a container truck as a "transportation tool" for CANopen information. In the OSI model, the CAN bus represents the two lowest layers (physical layer and data link layer). This means that CAN just implements the transmission of frames with fields of 11 bit CAN ID, Remote Transport (RTR) bits and 64 data bits (associated with higher layer protocols). In other words, the role of the CAN bus in CANopen is the same as in the J1939 protocol, while CANopen implements the seventh layer of the OSI model and can adapt to other data link layer protocols other than CAN (such as EtherCAT, Modbus, Powerlink).

It is worth noting that with the introduction of CAN FD, CANopen FD, as the next generation CANopen standard, may play an increasingly important role. For details, please visit CiA official website.

Compared with the CAN bus and the J1939 protocol, the CANopen protocol adds the following six core concepts:

communication mode

There are 3 modes of device/node communication: master/slave, client/server and producer/consumer.

letter of agreement

Protocols used for communication, such as configuring nodes (SDO) or transmitting real-time data (PDO), etc.

device status

A single device supports different states. A "master" node can change a "slave" node, including operations such as reset.

object dictionary

Each device has an OD with entries specifying device configuration etc., which can be accessed via SDO.

spreadsheet

EDS is a standard file format for OD entries, which allows service tools to update devices.

device settings file

Describes vendor independence such as I/O modules (CiA 401) and motion control (CiA 402)

Basic knowledge of CANopen communication

Basic knowledge of CANopen communication

In a CANopen network, multiple devices need to communicate, for example in an industrial automation setup you might have a robotic arm with multiple servo motor nodes and a control interface/PC node. In order to facilitate communication, there are three modes in CANopen, each of which is closely connected with the CANopen protocol we are discussing. The three modes are briefly described below:

Three modes of CANopen communication

01 master/slave

One node (such as the control interface) acts as the application master or master controller. It requests data from slave devices such as servo motors. This process is used for diagnostics or status management. In standard applications, there can be 0 to 127 slaves. Please note: In a single CANopen network, there can be different host controllers sharing the same data link layer.

Service example: NMT

02 Client/Server

The client sends a data request to the server, and the server replies with the requested data. For example, use this mode when the application master needs to get data from the OD of the slave. Reading from the server is an "upload" and "writing" is a "download" (the term is taken from a server-side perspective).

Service example: SDO

03 Consumer/Producer

In this mode, producer nodes broadcast data to the network and are consumed by consumer nodes. Producers send this data on request (pull model) or without a specific request (push model).

Service Example: Heartbeat

Obviously, these models are effectively the same, but they are differentiated for the sake of consistency of terminology.

POWERLINK communication experiment

It is still easy to experiment with powerlink communication, no special network card hardware is required, just two computers are enough.

Or a computer is used as the master node, and it is connected to an embedded motherboard or a single-chip microcomputer + PHY chip board through the network port to realize communication. Due to the lack of existing conditions, the communication between the two Windows computers is only done below. The source code structure of openpowerlink is clearly layered and the amount of code is not large. It should not be difficult to transplant it to the MCU environment.

Software Architecture：

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

The whole process of the experiment involves XDD file configuration, openconfigurator configuration, openpowerlink appDemo source code changes, computer-based powerlink Ethernet communication, and Wireshark for data transmission analysis. It is also possible to configure without using openconfigurator during debugging. You need to manually modify the contents of the dictionary objdict.h file, which requires understanding the mapping relationship of PDO communication parameters.

source code compilation

The source code compilation is relatively simple, and the source code structure is clear. It is recommended to use the cmake tool.

Source address:
https://sourceforge.net/projects/openpowerlink/

mnobd.cdc file introduction
This file is used to configure the MN stack. It includes all configuration data of the MN and all CNs, including network mapping information. CN configuration is handled by the MN's Configuration Manager (CFM) module. The mnobd.cdc file address is in
openPOWERLINK_V2.7.2\apps\common\openCONFIGURATOR_projects\Demo_3CN\output

Used to configure the MN stack. It includes all configuration data of the MN and all CNs, including network mapping information. CN configuration is handled by the MN's Configuration Manager (CFM) module. This file is generated by the openCONFIGURATOR tool. It is troublesome to manually change the mapping relationship, which can be realized through the openCONFIGURATOR tool.

mnobd.txt

This file describes the stack configuration in a human-readable format. It includes all configuration data of the MN and all CNs, including network mapping information. This file is for diagnostic purposes only.

xap.xml

The XML file contains the structure definition of the process image. This depends on the available data fields of the CN used in the application. The application can analyze the xml file to obtain information about the channel offsets mapped in the process image.

xap.h

The header file contains structure definitions for the process image in the form of two ANSI C structures. It can be included directly in the application.

compile log

====================[ 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 download

openCONFIGURATOR is an open source configuration framework for easy setup, configuration and maintenance of any POWERLINK ( https://goo.gl/U9tjiy ) network. It perfectly complements openPOWERLINK, the open source POWERLINK protocol stack for masters and slaves. The latest project consists of a core library implementing configuration algorithms and an Eclipse plug-in base user interface. Version 1.4.1 can be installed independently before (requires 32bit of ActiveTcl8.6).

New version download link: openCONFIGURATOR download | SourceForge.net

Old version 1.4.1 download link: https://master.dl.sourceforge.net/project/openconf/openCONFIGURATOR/1.4/1.4.1/openCONFIGURATOR-1.4.1-win32-x86.zip?viasf=1

The old version needs to rely on ActiveTcl (32-bit), ActiveTcl8.6.4.1 (windows x86) download address: https://download.csdn.net/download/qwer012345678/9859168

Tool manual: https://master.dl.sourceforge.net/project/openconf/openCONFIGURATOR/1.4/1.4.1/UserManual_V1.4.1.pdf?viasf=1

PDO communication parameter mapping relationship

PDO is the abbreviation of process data object. Simply put, it can be understood as a data frame. During the POWERLINK communication process, if a node needs to periodically send multiple objects in its own object dictionary, it needs to form a data frame of these objects to be sent and send it to the network. This data frame is called PDO. The outgoing PDO is called TPDO; the received PDO is called RPDO. The transmission type of PDO is continuous, and does not provide "event-based" or "change-based" transmission types, that is, regardless of whether the real-time data changes, PDO data is sent periodically, which is different from traditional CANopen.

Look at an example of a powerlink network:

In this example, there are master station (PLC), No. 1 slave station (IO station), No. 2 slave station (servo drive), No. 3 slave station (sensor), these devices together form a network.

This involves some issues:
1. For each device, which objects does he need to send to the network?
2. How do these objects form a data frame, that is, the positions of these objects in the data frame?
3. Since POWERLINK supports cross-communication, that is to say, the servo drive in the above example can receive
data from PLC, and can also receive data from sensors and IO stations. Does the servo need to receive data from certain sensors and IO stations? And what data is received?
4. How should each device parse the received packets?

These problems need to be solved by configuring communication parameters and mapping parameters.

Communication parameters : determine which node the node needs to receive data from, or which node to send data to. For the slave node, since the sending data frame is broadcast, it is not necessary to set this parameter; for the sending data frame Preq of the master station, this parameter needs to be set to indicate which slave node the data frame is sent to.

Mapping parameters : determine how the node composes the data packets to be sent or how to parse the received data packets. That is to determine the corresponding relationship between the object (Object) in the object dictionary and the data segment in the data packet.

Each POWERLINK node has a set of communication parameters and mapping parameters to describe when receiving and sending data.

For receiving:
0x1400-0x14ff: Communication parameters
0x1600-0x16ff: Mapping parameters
Communication parameters and mapping parameters appear in pairs, one-to-one correspondence. 0x1400 and 0x1600 are a pair; 0x1401 and 0x1601 are a pair; 0x14xx and 0x16xx are a pair.

For sending:
0x1800-0x18ff: Communication parameters
0x1A00-0x1Aff: Mapping parameters
Communication parameters and mapping parameters appear in pairs, one-to-one correspondence. 0x1800 and 0x1A00 are a pair; 0x1801 and 0x1A01 are a pair; 0x18xx and 0x1Axx are a pair.

1. Communication parameters sent by the slave station (0x18XX)

This parameter describes which node in the network this node needs to send its own data frame to (distinguished according to the node number). From the basic principle of POWERLINK we mentioned earlier, when each slave station reports its own data, it sends it in the form of broadcast, that is to say, when the slave station sends data, the destination address is 255. Therefore, the communication parameters of all slave nodes sending data are 255.

A POWERLINK data frame has a maximum size of 1500 bytes. When a node sends data, it can pack many parameters into a large data frame. So in the POWERLINK network, a slave node only needs to send one data frame per cycle. So for slave nodes, we only need to implement and use 0x1800.

2. Mapping parameters sent by the slave station (0x1AXX)

Since communication parameters and mapping parameters appear in pairs, they correspond one-to-one. 0x1800 and 0x1A00 are a pair; therefore, for the slave node, when you use 0x1800 as the communication parameter, then you must use 0x1A00 as the mapping parameter. The mapping parameter solves the correspondence between the object Object (that is, the parameter) in the object dictionary and the data segment in the data frame. For sending, that is how to compose the Object to be sent into a data frame.

As shown in the figure below, it describes a data frame and objects that need to be sent in an object dictionary. Now it is necessary to combine these parameters to be sent into a data frame. That is to establish a mapping relationship between each Object to be sent and a certain data segment, and put the value of the Object into the corresponding field in the data frame .

Suppose we want to establish the following mapping relationship:

That is:

Object 0x2000/02 is placed at offset 0 of the data frame, with a length of 16 bits.

The object 0x6000/01 is placed at the offset 16 of the data frame, and the length is 16 bits;

The object 0x6000/02 is placed at the data frame offset of 32, and the length is 8bits;

The object 0x2000/01 is placed at the offset 40 of the data frame, and the length is 16 bits;

To do this, we need to configure the value of 0x1A00 as follows:

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

Let's explain in detail the meaning of the first sentence, "0x1A00/0x01 value is 0x0010000000022000"

0x1A00 /0x01 is a parameter used to describe the mapping relationship between the first Object and the fields in the data frame . Set its value to 0x0010000000022000, which means to map the object with the index 0x2000 and the sub-index 0x02 to the data frame offset Where it is 0x0000 (the beginning of the data frame), the length is 16 bits.

3. Communication parameters received by the slave station (0x14XX)

This parameter describes which node this node needs to receive data from. As can be seen from the basic principles of POWERLINK described above, POWERLINK supports cross-communication, so each node can receive data from one or more nodes. So a node can have multiple receive channels. For example, 0x1400 is a channel that receives data from the master node, then set the value of 0x1400/0x01 to 0 (the default value is set to 0, indicating that the request data from the master node is received ); 0x1401 is a channel that receives data from No. 3 Then set the value of 0x1401/0x01 to 3, so that the node receives both the data from the master station and the data from node 3 in the same cycle.

4. Mapping parameters received by the slave station (0x16XX)

Since communication parameters and mapping parameters appear in pairs, they correspond one-to-one. 0x1400 and 0x1600 are a pair, 0x1401 and 0x1601 are a pair...; so for the slave node, when you use 0x1400 as the communication parameter, then you must use 0x1600 as the mapping parameter. The mapping parameter solves the relationship between the object Object (that is, the parameter) in the object dictionary and the data segment in the data frame. For reception, that is how to parse a data frame. Because the data sent by a node is often packaged together with multiple objects, the receiver needs to know which segment or segments of the data frame it should receive and how long the data is .

As shown in the figure below, it describes a data frame and objects in the object dictionary. Now it is necessary to establish a mapping relationship between the data segment in the received data frame and the Object in the object dictionary.

Suppose we want to establish the following mapping relationship:

That is, the mapping relationship between the data segment and the Object in the received data frame:
The offset of the data frame is 0 and the length is 16 bits. This piece of data is intercepted and placed in the object 0x2000/02
; The length is 16bits, this piece of data is intercepted and placed in the object 0x6000/01;
the data frame offset is 32, the length is 8bits, this piece of data is intercepted and placed in the object 0x6000/02;
the data frame offset is 40, The length is 16bits, and this piece of data is intercepted and placed in object 0x2000/01.

To do this, we need to configure the value of 0x1600 as follows:
0x1600/0x01 value: 0x0010000000022000
0x1600/0x02 value: 0x0010001000016000
0x1600/0x03 value: 0x00080020000260 00
0x1600/0x04 Value: 0x0010002800012000

Let's explain in detail the meaning of the second sentence, "0x1600/0x02 has a value of 0x0010001000016000".

0x1600/0x02 is a parameter used to describe the mapping relationship between the second Object and the fields in the data frame. Set its value to 0x0010001000016000, which means that the offset in the data frame is 0x0010 (starting from the 16th bit), and the length is The data of 0x0010 (16bits) is mapped to the object whose index is 0x6000 and whose sub-index is 0x01.

5. Configuration of sending parameters of master station

The difference between the master station and the slave station: every cycle, the slave station only needs to send a TPDO data frame.

If the master station is based on the request/response mode, it needs to send a request data frame Preq to all nodes in the network in one cycle, and will receive the reply Pres from the slave station accordingly. A Preq data frame is a TPDO . And a Pres data frame is an RPDO. This means that the master station needs to have multiple channels for sending TPDO when sending; when receiving, it needs to have multiple channels for receiving RPDO . For example, suppose a system has 1 master node and 3 slave nodes. At this time, the master station needs 3 sending channels and 3 receiving channels.

For the sending of the master station, the following configuration is required:

The following configuration is required for receiving:

Note: The configuration of PDO does not support dynamic changes. Once the network parameters and mapping parameters are configured and enters the synchronous communication stage, each node in the network will build and parse the data frame according to the set parameters.

For an introduction to mapping, see also: openPOWERLINK :: POWERLINK/PDO Mapping Example :: Example TPDO Mapping Table