Advanced Search

Yes Rod .. it is solution but it is creating constant delay between control position -> DFIR -> current position of tool ....

next stuff what Gemini tells me at Cloud of points topic is - 

* Look-Ahead Buffer CompressionConventional S-curves fail when the "Look-ahead" buffer is too small. If the planner only sees 10 points ahead, it doesn't know it can maintain $F500$ through the next 100 points.The Fix: Use a Compressor or Point Filter.In your trajectory planner settings, ensure the look-ahead is set to at least 100–200 segments.The Approximation: If three points are almost in a straight line, the planner should "ignore" the middle point. This turns a "Cloud of Points" back into a "Set of Vectors," which is much easier for S-curve math to handle.

(before noticed DRIF)
* The "Look-up Table" (LUT) Approximation
If the analytical math (solving cubic equations) is too slow for your CPU, you can use a pre-computed trapezoidal acceleration profile and apply a Finite Impulse Response (FIR) Filter.

The Method: Calculate a standard, "harsh" Trapezoidal move first. Then, run that velocity profile through a "Moving Average" filter.

The Result: The "sharp corners" of the trapezoid become smooth "S" shapes.

* Constraint Decoupling (Axis vs. Path)Latency often spikes when the planner tries to synchronize 3+ axes using 3rd-order math.The Fix: Instead of calculating a full 3D vector S-curve, calculate the S-curve for the Master Path (the total distance) and then linearly project that to X, Y, and Z.The Trade-off: This is slightly less "optimal" for machine time, but it reduces the math complexity by $66\%$, significantly dropping your latency.

* Frequency Domain Filtering (Advanced)
If you are writing the code for the planner, you can use a Low-pass filter on the commanded acceleration.
Generate the "rough" motion.
Pass it through a 2nd order low-pass filter (Butterworth or similar).
This effectively "limits jerk" by removing the high-frequency components (the "thumps") of the motion.

what I can see aproximation or longer thread timing are the only known solutions... but I am not expert in this topic 

endian wrote:

In professional controllers (Fanuc/Siemens), this is solved by having a dedicated DSP (Digital Signal Processor) or an FPGA that does nothing but the motion math, leaving the main CPU to handle the G-code.

As far as I know, that’s not entirely right.
For the nano-smoothing function (NURBS interpolation for cloud of points), Fanuc uses non-realtime buffered calculations on the CPU to prepare the trajectory (look-ahead buffer). Then, data from the interpolator is sent to the DSP, where the planner calculates the speeds in real time.

Hi,
Some time ago I opened a topic about separating CiA402 logic from EtherCAT and validating it in a more modular way.

forum.linuxcnc.org/ethercat/58434-separa...ter-drive-stub-valid

Since then I kept working on that idea and turned it into something more complete that is now actually runnable and easier to test.

What problem I was trying to solve:
While studying and experimenting with CiA402 setups (and reading quite a few forum threads), I kept running into the same kind of issues:
often ending up debugging everything at once (motion + HAL + EtherCAT + drive)
not knowing if a problem comes from logic, wiring or hardware
drive-internal homing causing unexpected behavior or following errors
difficulty understanding what the controlword / statusword is really doing at runtime


So the goal here is not to replace anything, but to make those problems easier to isolate and understand.

What this does differently
The main idea is to separate things a bit more clearly:
keep LinuxCNC motion as-is
isolate CiA402 semantics (state machine, CSP, homing, etc.)
keep hardware/backend separate (EtherCAT, etc.)
This way it's possible to:
test CiA402 behavior without hardware first
see what's happening internally instead of guessing
debug logic without mixing it with transport issues

You can run it directly (no EtherCAT required):
git clone github.com/MarcosDuqueCesar/linuxcnc-cia402-layer
cd linuxcnc-cia402-layer
find comp -name "*.comp" -exec halcompile --install {} \;
linuxcnc ini/examples/runtime_validate_xyz.ini
scripts/diag.sh

This runs a full CiA402 pipeline using a stub backend.
You can observe things like:
controlword behavior
statusword transitions
mode switching (CSP / HOMING)
basic sequencing / watchdog behavior

Debugging focus:
One thing I tried to improve is visibility.
Instead of guessing, you can see internal state and get a better idea if the issue is:
logic / sequencing
HAL wiring
or backend / hardware

About homing:
This is one area that motivated the work.
In some setups, using drive-internal homing can lead to following errors if the LinuxCNC side is not kept consistent with what the drive is doing.
Here, homing is treated as a separate semantic part instead of being embedded inside the driver logic, so it's easier to observe and reason about.

Current status:
simulation: working
CiA402 logic: validated in runtime
hardware integration: not yet tested
This is intentional so far — the focus was to understand and validate the CiA402 behavior first without requiring hardware.

Scope:
This does not replace:
real-time tuning
EtherCAT setup complexity
Those are still necessary.
This is mainly about structuring and understanding CiA402 behavior.

Feedback:
If anyone is working with CiA402 in LinuxCNC, I’d really appreciate feedback.
Especially from real hardware setups, to validate the adapter/binding side.
Thanks

 was struggling with the forum editor formatting, so the first post didn’t come out right.

by way of explanation the moving average uses a simple circular buffer and calculates the sum of readings. Once the buffer is filled, the next reading overwrites the first reading in the buffer. So by deducting that value before it is overwritten and adding the new value as its written, the sum is maintained without any loops. The moving average is simply the sum / buffer size. There is no reason why it could not be called again recursively to calculate the second moving average.

C73 on a 7I96 (there is no C73 on a 7I96S)  is 22 uF 10V or 16V size 1210

Interesting. If it helps, I have a well tested non-looping moving average function in a component for torch voltage here github.com/rodw-au/showstopper/blob/mast...ents/ohmic3.comp#L92
If I wrote it today I would malloc the storage in the component's startup function instead of using fixed arrays.

Why can't you use more than one thread instead of a FGPA?

 

@3404gerber

What I've found is that the existing firmware needs to be configured for debug build. There's a naive spinlock var not marked volatile and the compiler optimizes the loop to an infinite hang. I tried to mark it as volatile, but then I got to ~300 packets instead of ~7. Debug builds do work.

I've refactored to remove the need for the spinlock entirely, and will contribute back whatever Scott will take. My current repo is github.com/eraserhd/Remora-RP2040-W5500/tree/scratch . Optimized builds run great from this branch, and there's a Nix flake with a reproducible build environment.

I'm zeroing in on doing stepgen with the Pico's PIO. It's now properly separated out to do it.

I was finally able to try out your suggestion this weekend and of course stepgen produces exactly the number of pulses it's supposed to.
So I also connected the motor encoder to the 7i96s and used it to calibrate the number of steps/mm and it turned out to be 456, which is exactly 5% fewer than expected. Since my small pulley has 20 teeth, this led me to inspect the mechanics again and it turns out I have T5 pulleys with an AT5 belt, which resulted in it skipping one tooth forward once per motor rotation. Then I guess occasionally it wouldn't skip and my machine would lose it's position.

Thanks for your help, I learned a lot more about hal. I just have one more sort of related question: can you tell me the capacitance and voltage of the C73 capacitor on a 7i96?

Use PP (profile position) mode, not csp or csv. Unfortunately, the cia402 component doesn't support
that but it's not very hard to add. 

No problem to have both EtherCAT and Mesa. Two network adapters.
You possibly have some IO on the servo drives if you look.
See if you can run the vfd on Modbus, saves alot of IO and get a lot of functionality.

Spezidrohne wrote:

Mesa for my i/o, as i dont have any ethercat 24v i/o. As there might be glass scales in the future, not sure yet. But for general i/o as a jogwheel, pneumatics, Buttons etc. And for spindle vfd. Run, dir, pwm... Mesa cheaper than endless Beckhoff units.

Many people look for used  beckhoff modules on eBay.

I just got this working for testing yesterday
www.aliexpress.com/item/1005005340849270.html
It is documented (including manuals)  on the forum here.
It seems to include all I/O you need. It even has 0-10 volt input for plasma torch voltage and 0-10 volt output for spindle. It would be interesting to get the RS485 modbus working to control the spindle VFD but that might be asking too much....

Gemini tells me too...

The Problem: The 7-Phase WallWhen we move from traditional Trapezoidal (T-curve) to S-curve (Jerk-limited) motion, we hit a massive computational wall during High-Speed Machining (HSM). In a "cloud of points" (dense G-code with 0.01mm segments), a 3rd-order planner like the Yang Yang method has to solve a 7-phase analytical equation for every junction.At a 1ms servo thread, this is heavy. At 250µs, it’s nearly impossible for the CPU to stay in real-time. The result? "Unexpected Realtime Delays" or the planner "giving up" and slowing the feedrate (F) to a crawl to stay within Jerk limits.

The Best Available Solution: The "Double FIR" ApproachIf you are struggling with latency in your new S-curve trajectory planner, the most efficient implementation for dense point clouds isn't more complex math—it’s Digital Filtering.Instead of solving the 7-phase cubic equations at every point, the "Gold Standard" for high-frequency (250µs+) loops is the Double FIR (Finite Impulse Response) Filter:Trapezoidal Base: Use a simple, ultra-fast Trapezoidal planner to generate "raw" velocity.Filter 1: Pass the raw velocity through a moving average filter. This creates 2nd-order motion (Linear Acceleration).Filter 2: Pass that result through a second moving average filter. This creates 3rd-order motion (S-Curve / Jerk-limited).Why this wins for Point Clouds:O(1) Complexity: The math is just addition/subtraction. It doesn't care if the segment is 10mm or 0.001mm.Low Jitter: It’s perfectly suited for the 250µs window.Natural Blending: The filters act as a low-pass filter, naturally "smoothing" the noise inherent in point clouds without the overhead of junction-blending logic.

In professional controllers (Fanuc/Siemens), this is solved by having a dedicated DSP (Digital Signal Processor) or an FPGA that does nothing but the motion math, leaving the main CPU to handle the G-code.

re-did the pc. even used one with a 10th gen i5 now instead of the old 5th gen. Jitter is at around 10-20k. should be fine.

DRO is still not always filled on start, still takes a few moments for it to do that.
Will test further

Mesa for my i/o, as i dont have any ethercat 24v i/o. As there might be glass scales in the future, not sure yet. But for general i/o as a jogwheel, pneumatics, Buttons etc. And for spindle vfd. Run, dir, pwm... Mesa cheaper than endless Beckhoff units.