Advanced Search

Hi everyone,
 
I'm experiencing cumulative axis position shifts (mostly Y, some X) during helical boring operations generated by Fusion 360 Personal Use. The shift happens between passes, not during cutting. I've done extensive testing to isolate the cause and I'm stuck — hoping someone with trajectory planner experience can help.
HARDWARE:
- 3-axis mill, 1204 ballscrews
- Mesa 7i96s ethernet card
- Teknic ClearPath CPM-SDSK-2311S-RQN servos (step/dir mode)
- 75VDC PSU
- Raspberry Pi 5 running Debian Bookworm
- LinuxCNC Master (2.9)

THE PROBLEM:
When running a Fusion 360 helical bore operation (3 passes: rough, semi-finish, finish), the machine shifts position during the helical arc cutting itself. The first boring pass starts correctly, but position drifts during the operation. The shift is cumulative across passes — each subsequent pass is worse. I initially thought the shift was only happening between passes during repositioning, but after extensive testing I've confirmed it also occurs during the actual G3 helical arc execution.

WHAT I'VE RULED OUT:
1. NOT mechanical: Dial indicator shows <0.01mm backlash. Coupling and ballscrew are tight.
2. NOT motor faults: ClearPath LEDs stay green, no faults. (Note: HLFB is wired but not yet configured in HAL — this is on my to-do list.)
3. NOT lost steps during linear moves: I wrote a test program doing 20 cycles of G91 G1 Y50 F1000 / G1 Y-50 and Y returns perfectly. Zero shift.
4. NOT electrical noise / VFD: Shift occurs with VFD off, spindle off, no tool, air cutting only.
5. NOT step timing: Tested DIRSETUP/DIRHOLD at 2000, 5000, and 10000ns. 5000 was slightly better but didn't solve it.

WHAT I'VE FOUND:
The problem appears related to how the trajectory planner handles the G-code Fusion 360 Personal generates. Key factors:
A) Fusion 360 Personal Use converts ALL G0 rapids to G1 moves. This means repositioning between bore passes (retract, XY travel, approach) are G1 moves subject to G64 path blending. The machine blends through the repositioning corners instead of making exact stops.
The bore operation uses helical arcs (G3 in XY with simultaneous Z) — this is the exact pattern described in GitHub Issue #426 (Arc Blending Bug).
C) I tested ARC_BLEND tuning parameters:
ARC_BLEND_ENABLE = 1
ARC_BLEND_FALLBACK_ENABLE = 1
ARC_BLEND_OPTIMIZATION_DEPTH = 50
ARC_BLEND_GAP_CYCLES = 4
ARC_BLEND_RAMP_FREQ = 100
D) ARC_BLEND_ENABLE = 0 did NOT fix the second file either.

G-CODE STRUCTURE:
The problematic repositioning sequence between bore passes (02.ngc):
N635 G1 X-77.844 Y12.6 (exit move)
N645 Z5. (retract - G1, should be G0)
N650 Z15. (retract more - G1, should be G0)
N655 Z4. (approach - G1, should be G0)
N660 Z2. (approach to cut depth - G1)
N665 X-80.544 Y13.2 (XY reposition AT cut depth - G1, gets blended!)
N670 G3 X-81.144 Y12.6 ... (arc cutting begins)
My INI Snippet:
[EMCMOT]
EMCMOT = motmod
SERVO_PERIOD = 1000000
ARC_BLEND_ENABLE = 1
ARC_BLEND_FALLBACK_ENABLE = 1
ARC_BLEND_OPTIMIZATION_DEPTH = 50
ARC_BLEND_GAP_CYCLES = 4
ARC_BLEND_RAMP_FREQ = 100
 
[JOINT_0] (X)
MAX_VELOCITY = 50
MAX_ACCELERATION = 150
STEPGEN_MAXVEL = 62.5
STEPGEN_MAXACCEL = 250.0
DIRSETUP = 5000
DIRHOLD = 5000
STEP_SCALE = 200.100
 
[JOINT_1] (Y)
MAX_VELOCITY = 50
MAX_ACCELERATION = 150
STEPGEN_MAXVEL = 62.5
STEPGEN_MAXACCEL = 250.00
DIRSETUP = 5000
DIRHOLD = 5000
STEP_SCALE = 200.460
 
G-code preamble: G64 P0.005 Q0.005

QUESTIONS:
1. Is there a known interaction between Fusion 360 Personal's G1-only rapids and the trajectory planner's arc blending that could cause multi-millimeter position shifts?
2. Is there a recommended set of ARC_BLEND parameters for helical boring operations where G1 repositioning is mixed with G3 arcs?
3. Would modifying the linuxcnc.cps post processor to insert G61 before repositioning moves and G64 before cutting moves be the correct approach?
4. Should I be looking at something else entirely?
I can attach the G-code files if helpful. Any guidance appreciated — I've been chasing this for a while.
 
Thanks!

prokopcio wrote:

phino wrote:

Is there stock available for purchase of the height sensor?

A couple of days ago, I saw 1 in stock, but when attempting to purchase, it said out of stock.
Send me private message plese.
or beter contact by WhatsApp +48 604 247 648 
 

I don't think this forum has private messaging, but I have sent you an email (today and on 2025-10-09) at both This email address is being protected from spambots. You need JavaScript enabled to view it. and This email address is being protected from spambots. You need JavaScript enabled to view it. . Are those addresses correct?
I can also have a colleague of mine reach out to you on WhatsApp.

Hi,

Please provide your .xml, .ini, and .hal files.
An output of dmesg and EtherCAT slaves

Ok, I'll admit that I overlooked the functionality of the button. I tried inputing an offset but it wouldn't let me. "TOOL DIAM OFFSET" is a button that turns it on and changes the offset distance.

Thanks for setting me straight.

Here is my working  wiring diagram

Thanks again Peter for you help! It is soo nice that the Linuxcnc community helps newbies like myself. This help is hopefully getting me to learn more about Linuxcnc so I can figure out how to fix things. I started of trying to use pncconfig and did't understand alot of the terms and settings info so I went to AI for some help and I can see now that it was not really helpful.
Thanks again,
George

Thank you Rod for that information! I am as I said just an newbie and really don't know squat about Linuxcnc, but with your and Peter's assistance I am learning these errors were at the early stages of the configuration so hopefully I will learn more to get me through. Thannks again
George

You were a great help! I was already pretty far with the handwheel solution.

I'll wait and see what Sascha has to say, and wait a bit more to see if Scott will be able to dedicate sometime to the project.

Should I reach out to Bjarne? Or can you let him check the conversation in my PR in Scott's repo?

Thanks for the comp file kinematics update.

I am trying that out.In the meantime, I have been experimenting with current update.
I find that the planner type 2 also cannot accelerate across multiple segments. For a file with very small lines, it is not taking up adequate speed and the file execution is very slow. I am going to try to increase the jerk and try it on a real machine too...  
 

The ngc/tap file is also attached.  

I was thinking this could be solved with defining zones for acceleration. Where segments with similar kinematic parameters and some tolerance of direction can be accelerated over simultaneously. 
I have tried to capture my "Zones" based acceleration idea (using Claude.ai to elaborate on the details).A zone is a group of consecutive path segments that are treated as a single kinematic unit for acceleration planning. Segments are grouped into a zone when they are nearly collinear — i.e., the direction change between them is below a threshold (angle_threshold, default ~0.57°). A zone boundary is created when:

• The direction change exceeds the threshold  or 
• The kinematic limits (v_max, a_max, j_max) differ between adjacent segments 

This collapses thousands of micro-segments (e.g. from a linearized arc) into just a handful of zones

Corner Velocity Constraint: At each zone boundary (a "corner"), the maximum speed the machine can carry through the junction is computed geometricallyradius = path_tolerance / (1 - cos(θ/2))  
v_corner = sqrt(a_max × radius)

• path_tolerance = max allowable deviation from the sharp corner (e.g. 0.01 mm)  
• θ = junction angle between the two direction vectors
• A 90° corner at 0.01 mm tolerance and a_max=500 gives v_corner ≈ 4.1 mm/s — forces a near-stop
• A collinear junction (θ→0) gives v_corner → ∞ — no speed reduction needed

Zone-Level Bidirectional Velocity Planning: This is where acceleration is actually resolved:
Forward pass — starting from v_start, for each zone compute how fast the machine can exit given the distance and limits:          
           v_fwd[k 1] = min(max_reachable_from(v_fwd[k]), zone_Vmax, v_corner[k 1])
Backward pass — starting from v_end, do the same in reverse:          
           v_bwd[k] = min(max_reachable_from(v_bwd[k 1]), zone_Vmax, v_corner[k])
Merge pass — take the minimum at every zone boundary:          
           v_zone[k] = min(v_fwd[k], v_bwd[k], v_corner[k])

VelocityPlanner.max_reachable_velocity computes how fast you can reach the end of a segment given jerk/accel limits. Zones are then classified as accel, cruise, or decel based on whether the entry/exit velocities rise, stay flat, or fall. Consecutive same-type zones are merged into runs, and one S-curve (7-phase jerk-limited profile from SCurveSolver) is planned per run.This means for a linearized arc with 1000 micro-segments, only ~3–4 S-curve phases are generated (ramp-up, cruise, ramp-down), instead of 1000 independent profiles.

Regards,

-automata

I solve it right now by putting in hal file this line -
net machine-is-on halui.machine.is-on halui.joint.0.home

Write this for all joints you have, just connect machine-is-on to all joints.home.

When you enable your machine, it will trigger homing for each joint. Its not so dangerous I think, because you still need to Enable machine, but you dont need to extra click Home-all.
If you have properly setup homing via absolute encoders, machine will not move at all, just take possition from servo.

This solution is not solving if servo lost position, but it can be easily checked and routed to rehome script. I will solve this later.

Hi ihavenofish,

I read through that entire thread, unfortunately I couldn't find anything specifically on the pinout. I think I am going to have to remove the ATC shroud and take a look at the board. Here are some relevant posts from that thread:

forum.linuxcnc.org/30-cnc-machines/32276...ure?start=360#172455
forum.linuxcnc.org/30-cnc-machines/32276...ure?start=470#258347
forum.linuxcnc.org/30-cnc-machines/32276...nture?start=10#87606
forum.linuxcnc.org/30-cnc-machines/32276...nture?start=60#96531

I did some more searching online, and stumbled on this Brother B521136-2 board. It's not labeled for a TC225, but it has what appears to be the same number of pins, so I might be able to at least look at this to cross reference to what I have. The harness I have is labeled as follows:

E - Green w/ Yellow Stripe
49 - White w/ Yellow Stripe
50 - White w/ Green Stripe
51 - Blue Solid
52 - White w/ Blue Stripe
53 - Yellow Solid
54 - White w/ Red Stripe
55 - Red Solid




I feel pretty good about setting up HAL to handle the four BCD encoder bits, the deceleration signal, and the limit switch swap; there is a ton of good information in your thread that I will certainly use as a starting point. When I got the machine, however, it was in mid-retrofit, and pretty much all of the original hardware is gone - the only thing left are the factory limit switches, the Oriental Motor SBR32-ZP brake pack, and the Oriental Motor gear motor.

Thanks,
Jeff

kello711 wrote:

I am trying to load up a 1" wood surfacing bit. I wanted to use the tool offset direction in the probing but it doesn't seem to work. I didn't find anything in the documentation to explain how. I added the diameter to the tool table to no avail. Also on the probing menu, what do "User Params" 1 and 2 do?

It should work. Using the diameter offset changes the coordinates of the touch point in the macro.

kcjengr.github.io/probe_basic/tool_lengt...f-parameter-settings

github.com/kcjengr/probe_basic/blob/main...ol_touch_off.ngc#L32

grandixximo wrote:

Honestly, waiting for Scott for some direction, he is not been replying any messages, so at the moment everything is stale, I don't really want to touch core functionality, I'm not sure about the uspace work by Sascha, should linuxcnc take that in as well? We would have to build Sasha's ethercat master as well to enable all of that. Not sure what the community needs

Thats a but disappointing. Its hard to keep commitment on projects like this. Sasha lost interest and it was badly broken. At one stage, I hosted the hal driver repo briefly when I built the initial 2.9 ISO then Bjarne at etherlab did a deal with Sasha to host it direct. I gladly gave it up. Then Scott did a deal with Sasha to host it and develop it (which he did). So I did some intros and Bjarne helped Scott build workflows to send builds to the etherlab repo so it was hosted and available so that was pretty cool. I see Sasha's page says use Scotts repo and he hadn't made any commits since 2024 until a mad flurry of commits in 2026! Whatever you do etherlab will be very supportive.

Its just a shame the Ethercat license does not allow linuxcnc to manage it.

Not sure if that helps....

phino wrote:

Is there stock available for purchase of the height sensor?

A couple of days ago, I saw 1 in stock, but when attempting to purchase, it said out of stock.

Send me private message plese.
or beter contact by WhatsApp +48 604 247 648