Advanced Search

Rod: Thank you for the quick response and the script. I can only imagine the effort involved in finding all the settings for that script.

However, I ran the script and it didn't solve the problem on my machine. I ran the script and re-booted. When the machine started up I logged in and started linuxcnc. To test I just let it idle, no keyboard or mouse input and no running program in linuxcnc. It idled for just about 30 minutes and then logged out. The result was a user/password screen to re-login. When I login using that new screen I find myself stuck in a loop. I login, the computer thinks awhile, then pops up a new login screen. Same as I had when I pushed the wrong Power Management button before. Again, since I don't know how to revert from here using a terminal, I needed to re-install to get out of this loop.

I took to heart your comment, "Its actually very difficult to stop this". If there's no "standard" solution and you've had problems, I have no hope of fixing it myself. Instead I installed linuxcnc 2.9.4 which uses the older Debian 12 (Bookworm). But it sounds like to main problem is with the XFCE desktop more than the underlying Debian. I don't know the differences in XFCE between 2.9.4 and 2.9.8 but the problems look to be there.

Is this somehow computer dependent? If not a lot of users must be having the same problems. Is there a solution being worked on? If XFCE has gone off the rails, maybe a different desktop for future releases?  I'll need to update linuxcnc eventually and sure hope this is addressed.

Thank you very much for the help. I've solved my immediate problem, version 2.9.4 is now working. Again, thank you.

Hugh

Well I have made a little headway thanks to your help but now I am stuck again after a few hours of banging my head against my keyboard I am back. I have encountered an error at hal 67 with limit inputs. I have the inputs on TB6 04-9 being first 4 limits xyy2z 8&9 estops. I have commented out any thing to do with the estops and spindle on both ini and hal files to try and get linuxcnc running without errors and then I will work on them. The is pin 04 does not exist and I'm sure I am going to get the same errors for the joints. I have updated my ini and hal files and and added a screen copy of the run of Linuxcnd with the exact error shown and you can see what else is loading.
thanks again,
George

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