Advanced Search

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

Hi everyone,
im currently trying to set up an 18 pocket carousel with a cia402 controlled ethercat stepper motor. 
While I got it working in CSV (velocity mode), CSP so Positioning would be much nicer, faster and more accurate. 

My issue with this however, is that I have no way (or at least none that i know) to regulate the speed when setting the target position over the counts-target pin. Am I missing something or is this just not possible?

How is the typical CIA402 driven drive speed regulated?

When you have come this far with EtherCAT you can just keep on going.
No point in switching to Mesa now. Unless you want a Mesa system of course.

That sounds promising... @andrax
To the folllwing error: fault on my side. The servo was set too soft, and when decelerating there was too much play. Set it a bit harder and now it works. 
Mesa card arrives tomorow. Gonna try my best.

I did a clean install with the 2.9.8 / trixie ISO file, and have the same behavior on a 1980x1080 HDMI monitor, but inconsistantly. Sometimes full screen is correct, and then I get a switch to Gmoccapy not fitting the screen, but I am not yet sure under which conditions that happens.
Scaling 1.1 doesn't help, it just uses 90% of the screen with the gmoccapy still not fitting.
Cheers,
Mark

Try using the sendkeys component linuxcnc.org/docs/html/man/man1/sendkeys.1.html

no problem .. you are welcome, I am proud to cooperate/test this feature for linuxcnc comunity... as you noticed, I am not soo focused in the perfect trajectory but mainly at timing stability... sometimes it's like chasing your own tail

its interesting job and I see many advantages ... I am using TP0 for lathe threading/synchronization of motion for now, but we will wait for new stuff I am looking forward ...

yes I saw but Yang Yang publish new crucking repo few days ago but I have not time to study it ...

Luca which will be the next steps now ?

that dark blue spline at the bottom is the servo-thread.time, in the 100k resolution, which are sharply jumping at start of cloud of points as ... I am not pretty sure how the TP1 works to from the start but other files starting well without that spiking... is it possible to precalculated it or add some waiting to start the motion to smooth the beginning timing? 

How much influence latency of using Mate instead of Xfce gui ?
 

After adding downi915.enable_dc=0 i915.enable_fbc=0 i915.enable_psr=0 to grub, and creating another thread for all non-motion related stuff I got servo-thread time down to ~400000 and tmax 1351609 (did not increase after startup). Not realtime delay errors so far.

Also tried again with [HMOT](CARD0).read-request in the end of servo-thread just for fun. It definitely shortens read.time, servo-thread time drops to around 50000, but something breaks and i get following error spikes in every 75ms (pyvcp refresh rate). I would be interested to know why, any speculations welcome.

But most importantly it seems to be working now. Thanks for help rodw and PCW.