If I use EtherCAT to control a motor -- say I use RTnet + SOEM to control a servo drive using EtherCAT connectivity -- and the servo drive both controls and reads sensor value, than: is it necessary to use an RTOS to make the whole system hard real time?

For example, right now I'm using Xenomai patched Linux as the RTOS, but is this necessary if I use RTnet to control the motors?


closed as too broad by Chris Stratton, Voltage Spike, Dmitry Grigoryev, Dave Tweed Jul 14 '18 at 23:11

Please edit the question to limit it to a specific problem with enough detail to identify an adequate answer. Avoid asking multiple distinct questions at once. See the How to Ask page for help clarifying this question. If this question can be reworded to fit the rules in the help center, please edit the question.

  • \$\begingroup\$ This is far too broad and unclear to be answerable. Real time is basically a function of the unspecified allowed latency, vs. the things that could interfere. So multiple processes with a non-real-time scheduler, or multiple hosts sharing the bus, or critical-path components that can throw in their own habitual delays at unfortunate times are the kind of issues you need to consider. If you can push the real time loop out to the motor by running it in an embedded system and merely sending updated settings or a drip queue of commands that is often best. \$\endgroup\$ – Chris Stratton Jul 8 '18 at 18:48
  • \$\begingroup\$ From the SOEM code description: "As all applications are different SOEM tries to not impose any design architecture. Under Linux it can be used in generic user mode, PREEMPT_RT or Xenomai." \$\endgroup\$ – asndre Jul 18 '18 at 18:32

You need to distinguish the two technologies collectively named "Ethernet" that is a misunderstanding at least from the normative point of view:

1) Ethernet itself, as a set of various Physical layer protocols standardized in IEEE Std. 802.3 not so far given the same name as the technology it described from its beginning;


2) 802.1 Bridging, also referred to as Switching, mostly known for working over IEEE 802.3-compatible PHYs (Ethernet), as a set of some Data Link layer protocols, among others most known are IEEE 802.1Q and IEEE 802.1D, described in the series of IEEE Std. 802.1-related publications.

For example, 802.1 Bridging works well too over Wi-Fi (IEEE 802.11) and other non-IEEE 802.3 Physical layers. IEEE Std. 802 explains on this:

Also, you need to distinguish the scope where you plan/need/must to use "Ethernet" effectively enough to reach the goal of your hard real time scenario:

A) a terminal device connected to the network, who has at least one, networking-dependent hard real time task in its responsibility;


B) a "bus" itself, i.e. the packet-switching infrastructure responsible for establishing the network for a hard real time tasking.


  • yes, it is possible to use Ethernet (see 1) in a hard real time task both on a terminal device side (see A) and as the data transmission technology on the physical layer of the networking infrastructure (see B);


  • various means exist to make "Ethernet" effective/suitable for hard real time tasking, as in the networking=packet-switching, where besides the mentioned IEEE 802.1D and 802.1Q (see 2) other bridging-related and/or bridging-restricting protocols compatible (such as IEC 61850) and/or totally/partly incompatible (such as PROFINET) with IEEE 802.1-bridging are used, likewise as in a terminal device design, where to achieve a fast reaction and/or nice timing various means are also taken, among others popular today are asymmetric multiprocessing with a dedicated (like Arm's LITTLE.big approach) and/or specialized (like Texas Instr.'s PRUSS) processing core, and specific software based on accurate (like in FreeRTOS) and/or low-level (like in RT Linux) task scheduling.

Not the answer you're looking for? Browse other questions tagged or ask your own question.