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.

TAKUYA wrote:

Awesome Thank you.
ill try it with a simple limit2. Didnt know this component existed but it seems to do exactly what i need.
 

Following this as I've got a stepper-driven ATC using 'index' encoding under carousel.comp.  I'm thinking about switching everything over to ethercat, but the ATC was a really fuzzy area for me.

That's fantastic.

I've no idea what that pos->trans stuff means or does, but if you think it's the right plan I'm hopeful.

I've obviously got some reading to do.

Awesome Thank you.
ill try it with a simple limit2. Didnt know this component existed but it seems to do exactly what i need.

The speed is controlled by the trajectory planner. You can also use the limit3 or simple_tp components.

In your case - for the tool changer - you could use PP mode. Then the speed would be controlled by the drive itself, and you would only need to specify the new position. This mode is not available in the widely used cia402 component, but there have been examples of modifications on the forum, or a simple startup setting via SDO 0x6060=1   + a small amount of HAL logic