Advanced Search

Search Results (Searched for: )

  • maruf1777
  • maruf1777
Today 19:57 - Today 20:01

Axis position shift during helical boring - Fusion 360 Personal + Mesa 7i96s + C

Category: General LinuxCNC Questions

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.
B) 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!
  • phino
  • phino
Today 19:37

Laser Head Height Sensor – Looking for a Beta Tester

Category: Plasma & Laser

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.
  • andrax
  • andrax's Avatar
Today 17:50
Replied by andrax on topic StepperOnline A6 Servo

StepperOnline A6 Servo

Category: EtherCAT

Hi,

Please provide your .xml, .ini, and .hal files.
An output of dmesg and EtherCAT slaves
  • kello711
  • kello711's Avatar
Today 16:12 - Today 16:12

Probe Basic offset direction not seeming to work

Category: QtPyVCP

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.
  • DerKlotz
  • DerKlotz
Today 14:59

Wiring Leadshine DM856 Ena+ and ENA- -> Mesa 7i76e

Category: Milling Machines

Here is my working  wiring diagram
  • georgio
  • georgio
Today 14:59

Installing Linuxcnc on new pc Using Debian 12.13 and Linuxcnc 2.9.8 mesa 7i76eu

Category: Installing LinuxCNC

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
  • georgio
  • georgio
Today 14:55

Installing Linuxcnc on new pc Using Debian 12.13 and Linuxcnc 2.9.8 mesa 7i76eu

Category: Installing LinuxCNC

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
  • DerKlotz
  • DerKlotz
Today 14:51
Replied by DerKlotz on topic Add Buttons in Probe Basic

Add Buttons in Probe Basic

Category: QtPyVCP

You were a great help! I was already pretty far with the handwheel solution.
  • grandixximo
  • grandixximo's Avatar
Today 14:43
Replied by grandixximo on topic Ethercat random jitter fix

Ethercat random jitter fix

Category: EtherCAT

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?
  • automata
  • automata
Today 14:32 - Today 14:58
Replied by automata on topic LinuxCNC S-Curve Accelerations

LinuxCNC S-Curve Accelerations

Category: General LinuxCNC Questions

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.  

File Attachment:

File Name: flower.ngc
File Size:716 KB


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
  • Pipik
  • Pipik
Today 13:52
Replied by Pipik on topic absolute multiturn encoders (solved)

absolute multiturn encoders (solved)

Category: HAL

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.
  • jefflikesbagels
  • jefflikesbagels
Today 12:47
Replied by jefflikesbagels on topic Brother carousel encoders

Brother carousel encoders

Category: CNC Machines

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
  • hmnijp
  • hmnijp
Today 12:20

Probe Basic offset direction not seeming to work

Category: QtPyVCP

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
#<tool_radius_offset> = [#<tool_diameter> / 2]
#<left_offset_probing_position> = [#<tool_touch_x_coords> - #<tool_radius_offset>]
#<right_offset_probing_position> = [#<tool_touch_x_coords> + #<tool_radius_offset>]
#<front_offset_probing_position> = [#<tool_touch_y_coords> - #<tool_radius_offset>]
#<back_offset_probing_position> = [#<tool_touch_y_coords> + #<tool_radius_offset>]

o100 if [#<tool_diameter_offset_mode> EQ 1]
    o101 if [#<tool_setter_offset_direction> EQ 0]
        #<tool_touch_x_coords> = #<left_offset_probing_position>
    o101 else if [#<tool_setter_offset_direction> EQ 1]
        #<tool_touch_x_coords> = #<right_offset_probing_position>
    o101 else if [#<tool_setter_offset_direction> EQ 2]
        #<tool_touch_y_coords> = #<front_offset_probing_position>
    o101 else if [#<tool_setter_offset_direction> EQ 3]
        #<tool_touch_y_coords> = #<back_offset_probing_position>
    o101 endif
o100 endif
  • rodw
  • rodw's Avatar
Today 09:58
Replied by rodw on topic Ethercat random jitter fix

Ethercat random jitter fix

Category: EtherCAT

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....
  • prokopcio
  • prokopcio's Avatar
Today 09:16

Laser Head Height Sensor – Looking for a Beta Tester

Category: Plasma & Laser

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 
Displaying 1 - 15 out of 284015 results.
Time to create page: 3.565 seconds
Powered by Kunena Forum