PID tuning when you have a tuned Servo in CSP mode?

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.

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.

I am not specialist in this field ... I have asked AI about it ... and she told me below ...

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:
    • Code:

      ecrt_master_application_time()
      and
      Code:

      ecrt_master_sync_reference_clock()
      : The IgH EtherCAT master library provides functions like
      Code:

      ecrt_master_application_time()
      to set the master's application time and
      Code:

      ecrt_master_sync_reference_clock()
      to adjust the reference clock based on the master's time. These are called within the LinuxCNC servo thread.
    • Code:

      sync0Shift
      and
      Code:

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

        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.
      • Code:

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

        -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
  Code:

  ethercat slaves -v
  and HAL scope sessions (to monitor
  Code:

  pll-out
  and
  Code:

  pll-err
  pins in
  Code:

  lcec
  when
  Code:

  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.

 

endian wrote:

Be careful because it is configurable for twincat Nc task axis setup is axis lag watching possible to disable and there are any running speed possible to get... I think they have 7phase generator to control to axis movement which is probably more powerfull then lcnc trajectory generator ... They have native ec drivers for they native hardware .. but I am not specialist, I have just 15y of experiences which is nothing... 

Hi Endian, thanks for the info.  I'm actually using the CNC component of twincat and it does monitor axis position lag.   When I get some time I would like to try your converter to see if I can take the twincat ethercat config and convert it to LCNC...perhaps this would solve the issue.

What I have noticed till now is ... the DC configuration it has the main influence for timing ... I have older stuff as Kollmorgen S300 where it is little bit different but line creates me lags and jerks in the motion .. I just customized this line to  and everything was gone ... 
Output refrence from twincat3 setup looks like - something like 
[/code][/code]

Just to close the loop on this from a Teknic/ClearPath perspective, they have a Jitter delay that can smooth out motion, that was set at 14ms, when turned off the f-error dropped to 2ms which is in the ball park of a timing loop. 

Long story short, I am turning off everything PID related since I am using CSP and DC as long as my jitter setting is the same on all the motors they will all end up at the same commanded place at the same commanded time even if LinuxCNC is 2ms behind. 

Sorry to break in again, but AI is wrong on the linuxcnc synchronization with the DC loop.
They are not synchronized.
Spend some time and measure it.
I think the easiest way to detect it is using the ddt component on the feedback position from the drive.
It should be constant at constant speed, so very easy to spot any missing or out of sync cycles.