Advanced Search

Hakan wrote:

ok, thought it was a reply to my post.

A consequence of the LinuxCNC servo loop not being the same length and not being synchronized with the EtherCAT DC cycle is that the drives can make unpleasant noises every few minutes. How noticeable this is depends on how well the drive is able to handle this situation.
If I listen closely I can hear it from my ECT60 drives. This is especially noticeable with stepper motors where even a small change in pulse frequency can be perceived by the ear. In principle this should also happen with servo drives, but I have not studied it.
The 2 cycle delay is hard to do something about.
Synchronzation of the servo loop and Ethercat's loop can be done by having linuxcnc follow the DC cycle. When they use DC.
Well it can't be done, but it can be developed.

 is linuxcnc + ethercat master over lcec component single cycle time synchronized ?

Yes, achieving highly synchronized single-cycle operation with LinuxCNC and the EtherCAT master (specifically using the IgH EtherCAT master via the LCEC component) is a primary goal and generally achievable, especially when utilizing Distributed Clocks (DC) synchronization.Here's a breakdown of how it works and what's involved:

• EtherCAT's Distributed Clocks (DC): EtherCAT is designed for high-performance and precise synchronization. A key feature is Distributed Clocks (DC), where one slave is designated as the reference clock (often the first DC-capable slave in the chain). All other slaves, including the EtherCAT master, synchronize their internal clocks to this reference. This results in very tight synchronization across all devices on the EtherCAT network, often in the nanosecond range.
• LinuxCNC's Real-Time Environment: LinuxCNC operates on a real-time (RT) kernel (like PREEMPT_RT or RTAI) to ensure deterministic execution of its motion control and I/O tasks. The main control loop runs in a "servo thread" at a fixed, precise rate (e.g., 1 kHz).
• LCEC Component's Role: The LCEC component in LinuxCNC acts as the interface between the LinuxCNC HAL (Hardware Abstraction Layer) and the IgH EtherCAT master. It allows LinuxCNC to send commands and read data from EtherCAT slaves.
• Synchronization Strategy:
  • Slave Synchronization: The EtherCAT slaves themselves are tightly synchronized to the reference clock on the bus via the DC mechanism. This means their internal operations (e.g., updating output values, sampling input values) occur at precisely defined moments relative to the bus clock.
  • Master-to-Slave Synchronization: The crucial part is synchronizing the LinuxCNC servo thread (the master) to the EtherCAT bus's distributed clock. This can be achieved by:

    • ecrt_master_application_time()

      and

      ecrt_master_sync_reference_clock()

      : The IgH EtherCAT master library provides functions like

      ecrt_master_application_time()

      to set the master's application time and

      ecrt_master_sync_reference_clock()

      to adjust the reference clock based on the master's time. These are called within the LinuxCNC servo thread.

    • sync0Shift

      and

      refClockSyncCycles

      : These parameters in the EtherCAT configuration (often in an XML file) are critical for fine-tuning the synchronization.

      • sync0Shift

        defines an offset for the slave's Sync0 event (the point in time when process data is applied/sampled) relative to the start of the EtherCAT cycle.

      • refClockSyncCycles

        can be used to tell the master to synchronize its internal clock to the reference slave's clock. A negative value (e.g.,

        -1

        ) often indicates a mode where the master actively adjusts its timing to the reference clock.
• Achieving Single-Cycle Synchronization: When configured correctly with DC synchronization, the goal is for the LinuxCNC servo thread to operate in a tight, deterministic loop where:
  1. LinuxCNC calculates new output values.
  2. The LCEC component sends these outputs to the EtherCAT master.
  3. The EtherCAT master sends the process data over the bus.
  4. The EtherCAT slaves receive the data and apply it, and sample their inputs, all precisely synchronized by DC.
  5. The slaves send their input data back.
  6. The LCEC component reads the inputs, which are then available to LinuxCNC for the next servo cycle.
  While the process data exchange itself happens very quickly within the EtherCAT frame (the "bullet train" analogy), LinuxCNC's typical "read inputs, process data, write outputs" model means that there can be a one-cycle delay for inputs to be reflected in the control loop. However, the timing of these operations is highly synchronized to the fixed cycle time.

Challenges and Considerations:

• Jitter: Even with a real-time kernel, some level of jitter (variations in actual execution time) can occur. The goal is to minimize this jitter so that the LinuxCNC servo thread's timing is consistent enough to maintain tight synchronization with the EtherCAT bus.
• Hardware: A good real-time capable PC and a suitable EtherCAT-compatible network card are essential for optimal performance.
• Configuration: Correct configuration of the IgH EtherCAT master and the LCEC component, especially the DC synchronization parameters, is crucial.
• Debugging: Tools like

  ethercat slaves -v

  and HAL scope sessions (to monitor

  pll-out

  and

  pll-err

  pins in

  lcec

  when

  refSyncCycle = -1

  ) can help in debugging synchronization issues.

In summary, LinuxCNC with the LCEC component and EtherCAT's Distributed Clocks is designed to provide highly synchronized single-cycle operation for motion control applications, enabling precise and deterministic machine control.

Hakan wrote:

Why bring in Twincat?