Chengdu Shian Anxin Technology Co., Ltd. has developed the industry-leading multi-core heterogeneous framework RTOnBoot. Combined with SOEM master stations and OpenPLC, they have successively developed low-cost, high-performance single-core single-master station and industrial controller solutions on the RK3588 platform, achieving a stable Ethercat synchronization cycle of 125 microseconds.
Now we've gone a step further, combining the RK3588 platform with Linuxcnc, which boasts a more general and superior real-time architecture, to develop a low-cost, high-performance CNC solution. The Ethercat synchronization cycle can also be stably achieved at 125 microseconds.
As is well known, Linuxcnc is a full-featured industry solution encompassing a graphical interface, G-Code interpreter, libnml, HAL layer, and real-time motion planning and execution, primarily implemented on x86-PC machines. Its real-time architecture is perfectly integrated with RTAI, Xenomai, and Preempt-RT, with the HAL layer residing in shared memory, resulting in excellent real-time performance.
Now we have perfectly integrated the multi-core heterogeneous framework RTOnBoot with Linuxcnc. RTAI, Xenomai, and Preempt-RT do not possess RTOnBoot's cache isolation design, allowing for free variable definition; therefore, their real-time performance and stability are inferior to RTOnBoot. Meanwhile, some RTOSs may be used, with real-time performance superior to RTOnBoot's NUTTX. However, Linuxcnc has a large amount of logic in the Linux user space, such as Python, TCL, G-code interpretation, etc., which is difficult to port to these pure RTOSs.
The difference between our design and the original Linuxcnc design is that the original Linuxcnc's real-time portion runs on the Linux kernel or Linux user space, while our real-time portion runs on a separate RTOS core. Our goal is to combine with a more general and advanced architecture like Linuxcnc, while simultaneously completing the industrial ecosystem.
To achieve our goal, we did a lot of work. First, we developed a multi-core, multi-master architecture, where multiple cores can run multiple SOEM masters, each achieving optimal performance. Obviously, the native design of SOEM masters doesn't support this.
We have three sets of HAL and RTAPI: one in Linux user space, one in Linux kernel space, and one on another core running Nuttx. The original Linuxcnc had two sets: one in Linux user space and one in Linux kernel space.
We perfectly implemented the loadrt command. Loadrt supports Nuttx's embedded mode, Nuttx dynamic link libraries, or Linux kernel KO files. It has a complete module management mechanism. Linux kernel-level KO files can implement a Linuxcnc kernel driver, allowing for two driver implementation methods: Linux kernel driver or Nuttx driver. This is very convenient for users, as many are more accustomed to writing Linux drivers, and the supported APIs are much richer. The only limitation is that it operates in Linux kernel space, preventing the export or addition of functions.
Because the real-time thread runs on Nuttx. However, through HAL signals, it is possible to efficiently establish, read, and write variable states or values between the kernel and the real-time thread.
We also perfectly modified halcompile, allowing it to cross-compile into Nuttx dynamic link libraries or Linux kernel KO modules for use by LoadRT. It also integrates with the module management mechanism.
We focused on the integration of linuxcnc and ethercat. We modified linuxcnc-ethercat. The XML configuration file format and data structure of Ethercat are consistent with linuxcnc-ethercat. Our main modification was changing the protocol stack from IGH to SOEM, adapting it to multi-core heterogeneous and multi-core multi-master structures.
We use the multi-core version of RTOnBoot. NUTTX controls at least two cores. One core runs the base-thread and servo-thread, and the other one or more cores run one or more SOEM masters.
The SOEM master has three threads: soem-init, soem, and errror_check.
We support CSP mode and zero-return operation for the Cia402 driver.
Under this general architecture, tests showed that the maximum execution latency of SOEM is 51 microseconds, and the maximum sleep latency is 31 microseconds, so the synchronization period can stably reach 125 microseconds.
Of course, our porting is general and adaptable to non-ethercat environments, but we haven't tested that.
For the graphical interface, we use qtvcp, which can display interfaces such as qtaxis. Other graphical interfaces are more classic and there's no need to use them for now. Integration with Python and TCL has been completed.
In addition, to support loading different .so files, we developed a general-purpose memory file system, SOFS, for sharing files between kernels.
In addition, we have developed a FIFO mechanism for efficient real-time and non-real-time communication as a supplement to the message mechanism.
At this point, we have completed the industrial ecosystem. Regarding the robot ecosystem, we believe that the combination of ROS distributed architecture and Linux CNC is the most beneficial architecture for the real-time performance of actuators. It leverages the distributed nature and ecosystem of ROS, while also taking advantage of the ecosystem and real-time architecture of Linux CNC. Our solution further enhances real-time performance and stability. Of course, there are multiple implementation methods in this regard, and different people will have different opinions.
Finally, here is an example HAL file.
Top comments (0)