Remora - ethernet NVEM / EC300 / EC500 cnc board

Também estou com o mesmo problema.aparentemente precisa editar o arquivo .hal no LinuxCNC. Conseguiu resolver?

Did you try to lower the jog velocity to something really slow and jog?

I get it to work finally. Idk what im doing wrong. After flashing newest beta its working :side:

Which version of Remora did you flash? Luckily, it worked with the latest beta. I've attached some files that work for me. Would you also like the pinout for the DM556Y drivers for the EC500?

You're thinking along the right lines, and this can definitely be improved.
Interrupts break determinism and can introduce jitter into the system. The jitter might be small, but it's still there because the core has to stop processing, handle the ISR, and then resume the program.
We need to get rid of interrupts entirely for this.
Configure the timer like this:

 TIM4->SMCR = (TIM_SMCR_SMS_0 | TIM_SMCR_SMS_1);     // ENCODER MODE (TI1 & TI2)
 TIM4->DIER = 0;                                     // NO INTERRUPTS
 TIM4->CCMR1 = (TIM_CCMR1_CC1S_0 |                   // (CH-A) CC1S = 01 (TI1FP1 --> TI1). CH1
             TIM_CCMR1_IC1F |            // F SAMPLING.                        CH1
             TIM_CCMR1_CC2S_0 |          // (CH- CC2S = 01 (TI2FP2 --> TI2). CH2
             TIM_CCMR1_IC2F);            // F SAMPLING.                        CH2

 TIM4->CCMR2 = (TIM_CCMR2_CC3S_0 |                   // (CH-Z) CC3S = 01 (TI2FP3 --> TI3). CH3
             TIM_CCMR2_IC3F);            // F SAMPLING.                        CH3

 TIM4->CCER |= TIM_CCER_CC3E;                        // Capture/Compare enable CH3
 TIM4->PSC = 0;                                      // PRESCALER = 0
 TIM4->ARR = 0xFFFF;                                 // 65535


 The timer will operate as an encoder counter (Channels 1 & 2) and **simultaneously** Channel 3 will be configured for **Input Capture mode**. The Index pulse (Z-channel) is connected to Channel 3.

 **What do we get from this?**
 *   `TIM4->CNT`: The current raw encoder count.
 *   `TIM4->CCR3`: The **exact hardware state** of `CNT` latched at the moment of the rising or falling edge of the Index pulse.

 This gives us an extremely accurate hardware snapshot of the counter at the exact moment the index pulse occurs.

 **Next Steps:**
 We just need to extend the communication protocol and send both `CNT` and `CCR3` for each encoder.
 Then, on the **LinuxCNC side**, `CCR3` should be processed similarly to how the Mesa driver handles `CNT`.

 When Motion sets `index_enable` in the driver, we simply do:

 if(CCR3 != CCR3_prev) {
     // HURRAY, THIS IS THE TRUE INDEX!
    // Now we can correct the raw counter based on the current CCR3 value.
 }


Result: We get precise index homing without needing to send an `index_enable` request down to the STM32. Everything is handled cleanly on the LinuxCNC side.

 Hope that makes sense.

I have a few questions regarding the Remora ETH source code. I understand it's built on the lwIP stack.

Does lwIP significantly impact the servo cycle timing? Does it cause noticeable lag/jitter?

Has anyone attempted to implement their own custom stack with Zero-Copy support? I suspect this would yield a decent performance improvement.

How is the time domain problem solved between the PC's servo cycle and the STM32's time domain? Or does the system simply operate in a fast response mode — processing commands immediately upon arrival from the PC?

If the time domain mismatch isn't handled properly, you simply cannot achieve precise velocity and acceleration control, especially when dealing with position feedback from the encoder.

Thanks.