Aqui os 3 modelos que testei funcionaram bem.
Mas com .bit chinês

Before I had TTS tool holders I used a touch plate that I had made. It was basically a spring-loaded brass button in a Delrin base. I used to put each OP in a separate G-Code file and touch-off with the touch-plate at each tool change. Now I have an M6 remap that automatically measures my variable length tools like drills and odd endmills that I don't have dedicated toolholders for. It uses that length in the tool table for the tools with dedicated holders.

I don't have a surface plate or height gauge (yet). I do have a lathe with a DRO. I made a ring that the tool holder fits into. I chuck the ring up the lathe, Turn the lathe tool post holder around so I have a flat surface that will go up against the ring. Zero out the DRO. Move the tool post away from the ring. Insert the mill tool in the ring then move the lathe tool so it touches the tip of the tool. The DRO now shows the tool length. I enter that value into the tool table.

We use CSP control with Ethercat, I can't really envision benefit of sending next next position, instead of just next position.

What do you actually observe on real finished parts? Any actual quality issues? Or is this a theoretical concern based on watching HAL ferror signals?

FWIW, I finally got back to working on this with the new 7i84 board and the ferrules I ordered.
I purchased two different ferrules but the one that seems to work best is a 0.14mm2  - 26-28g brown  Digikey PN 288-1656-ND, manu-PN 1163014

These will go in and start over the insulation slightly (maybe where it's been necked down a little during stripping?) but crimps down tightly.
I do think I might all a drop of CA to the plastic end of the ferrule once the wire is in just to move the flex point away from where the bare wire is crimped and up to the insulated part

Back to wiring....

 

Hi everyone, I'm 杨阳. I'm currently studying the lookahead optimization code in the motion planner, and we're also exploring some approaches to improve its computational efficiency. If everything goes well, I hope to contribute further optimizations in the future. 

The hal file shows independent analog outputs and encoders

Are you sure you have the feedback correct for Y and Y2?

You not only have to get the right (matching) directions but the
proper feedback so you don't get a instant runaway at drive enable.

Might be best to test  this with the linear axis disconnected

Ah, I didn't see anything on a real machine. Will have to look deeper.

First tart is here in 2 weeks or so, so ill try it on that.

I think grandixxmo takes the prize already. A complete stable and finished scurve planner with a PR for inclusion in the linuxcnc core code. (new features go into 2.10 so that's where it is). Also tested by another user on real hardware (by endian) In the mean time, try the version in his github. It works!

interesting. I'll be watching where this goes. There have been 100 false starts on this that never make it to the end. That's why I am going to be offering up a tart, to incentivise completion.

(completion mean running a machine bug free, solid, stable and finished)

Yes, you can see the other post in the forum

forum.linuxcnc.org/38-general-linuxcnc-q...-curve-accelerations

Endian posted a video in action.
It will be in 2.10 release, it's in my Linuxcnc fork now, and should be merged soon to master.

Now the wiring is correct and the enable is working. If i test every axis for its own it seems to work fine.

But now i got a problem with my gantry Y Axis. If both Y Axis connected to the TB5 and we press F2 the Motors jumps around and an following error occures. Do you have any idea why this happend?

Anyone have any ideas what's wrong with my spindle. The video clip below shows the lathe in CSS mode. Everytime I'm moving the X axis you can see the display on the vfd dipping , when a lot of speed changes are there it newly stops the spindle it's so low. I noticed this in manual mode also. When changing to another speed it dips slightly before going to the commanded speed. I measured the 0-10v output on the Ec500 and can see the voltage dipping before going back up.

youtube.com/shorts/Mo1SoWhW5U4?si=6uqabWnk2D27JKpQ

The issue is resolved. The only missing part was adding USER_M_PATH = /home/cnc/linuxcnc/nc_files to the [RS274NGC] section of the .ini file. After adding this line and restarting LinuxCNC, the M130 user M-code was recognized correctly.

 Thanks to hmnijp for the help and guidance.