Advanced Search

i have upgraded to trixie 6.12.113 kernel and jitter now is much worse..
Any updated instructions for improving jitter?
I think every kernel update make things worse.

For reference, here are some results showing a comparison between the original proximity switch homing and the "index gated" implementation.
 
The "optimisation" process produced the biggest improvements which were the result of finessing the PID values and slightly reducing the homing speed to minimise the delay between reading the index pulse and processing the data. Both methods were significantly improved this way but the end results were almost identical.
For the test setup, I repeatedly homed the machine (typically 20 times, as shown), with the absolute position automatically logged and plotted.

   I had seen the videos of that Tesla car on Youtube this past weekend. It's an interesting piece of window dressing 
to be sure, however the physics involved would say that other then showing off for investors it holds no practical use
nor do I really think you will ever see that on the road. That car can't hold batteries and enough fuel/Gas for propulsion
to be allowed by various departments of transportation. Purpose built aircraft still can fail and crash, you can imagine 
some idiot trying one of those stunts in traffic, a thruster fail, and crashing onto someone’s car killing them. That doesn't
include the fact that as soon as that car is airborne Aviation authorities will enforce there rules on it as well. You know
how much they complain about little johnny flying his little drone at a soccer field. How much more so with this.
will they sell a car that looks like the one they showcased? Probably. Will it do what was shown? Not Likely.
There's a big difference between a controlled environment and the open road.

In reality this is just more "Bread and Circus".

 
 

I've got a very similar setup on my lathe, and while that's not a milling machine, the setup has a lot in common.

I have a Chinese glass encoder on the Z axis and a magnetic encoder buried in the X axis (under the cross slide). The Z axis has an inductive (technically eddy current) proximity switch for homing and the X axis has a microswitch.

Those both work in closed loop. I don't use backlash compensation but the axes used NOS, Japanese ground ballscrews.

I spent several hours recently implementing "index mark" homing on both axes, using the synthesised encoder outputs from the servo drives and perhaps surprisingly there was no obvious benefit, so in the end I simply reverted to using the limit switches.

This is partly due to the way the index pulses are read by the 7i85, but then subsequently processed by Linuxcnc. I also suspect that some of the remaining variation is in the mechanism between the servo motors and the actual axis ie toothed belt, ballscrew, bearings, mechanical slop etc.

When you look at it that way, it doesn't seem obvious that moving the servo motor to a particular angular position after homing to the switch would necessarily deliver any obvious benefit. Either way, repeated testing with a decent DTI showed clearly that while the system was working, it didn't improve the homing repeatability or accuracy in my case.

This outcome may differ with your machine. Mine can only resolve / achieve 5um repeatability due to the encoder resolution and although I have good ballscrews and the machine is well adjusted, it wasn't built as a CNC machine, so is perhaps not the optimal choice.

Hi
I have been trying to understand what causes this issue with QTDragon UI running LinuxCNC 2.10 pre release. 
The issue is, almost always, the Z position seem to be wrong after i enable auto tool measurement.

This is what I usually do:
1. Enter the block height. I either measure this manually or utilize the 'Work Piece Height Probing' mentioned in 14.1 of the manual. This is given in the probe section.
2. I have setup the tool sensor at a given X/Y with search velocity, etc. I have also modified the tool change command to trigger the python plugin which does an automatic tool height measurement with this sensor. The height of the tool sensor is also fixed and given. This is provided in the probe section.
3. Load the gcode program and start. 

It correctly triggers the tool measurement and continues, but almost always the Z height is wrong. What is shown for G54 is unrelatable to the real Z height which should be there for the program. 

Is there anything that I am doing wrong? Do I have to set things up differently when I generate the gcode from Fusion 360? Also I see that some f the parameters like block height, tool height need to be specified in many places of the GUI. Which one is used by the auto tool measurement?

Thanks
Sus

Thanks for the help!
Actually, ChatGPT helped me find an error in the INI file for my closed-loop system (which I attached earlier).
There is a line for initial settings: `RS274NGC_STARTUP_CODE = G21 G40 G90 G94 G97 G64 P0.025`. By adjusting the `P` value within the `G64` command, you can fine-tune the surface quality. I achieved the best surface quality with `P0.005`. I haven’t tried your firmware, as I’m currently satisfied with the surface quality I’m getting. Thanks again for your help!

Follow-up: isolated CPU2 as well.

HMI still on CPUs 0-1. EtherCAT thread still on CPU3, SCHED_FIFO 80.
isolcpus=managed_irq,domain,2,3 and irqaffinity=0-1, so the i915 IRQ
is off the L2 sibling. ec_r8169 is polled from that thread, no NIC IRQ.

These runs are 2 kHz (0.5 ms), not the 1 ms set above.
Same measurement: wake-to-wake minus the period, full capture,
absolute jitter, nearest-rank.

CPU3 isolated only, just before (10 runs, 124447 samples):
P95/P99/P99.9 = 4/5/7 us, max 15 us.

CPU2 isolated too (20 runs, 241941 samples):
P50/P95/P99/P99.9 = 0/1/1/2 us, signed -11/+12 us.
Every run has P99 = 1 us. |j| >= 10 us is 11 samples, |j| >= 20 us is 0.
Lost frames = 0, no missed cycles.

Hello,
When using a parallel port, entering the jitter value in Stepconf results in the calculation of the maximum step rate. Does this figure—for example, 33333 Hz—apply to each axis individually, or to all axes combined?
Best regards,
Hans

Hi, I'm Sergei, the developer of Screph (screph.com/), a visual environment for building image-processing workflows. I'm exploring how it can help with irregular stock and repeated CNC setup.

I have two complementary English demonstrations:
1. Camera-based workpiece positioning and transformation of existing toolpaths, including clamps and excluded regions:
2. An AI-assisted design based on a wood photograph, accounting for knots, followed by alignment of the prepared paths to the board on a simulated table:

The first example uses configurable image-processing masks to distinguish stock, table, clamps and excluded regions. The second explores how the design itself could respond to features of an individual workpiece. These are separate stages: generating the design and estimating the pose for coordinate transformation. The operator should inspect the intermediate results and transformed paths before accepting a job.

These are software demonstrations and simulations. I don't own a CNC machine, and this is not a claim of a validated LinuxCNC integration or measured machining accuracy. Physical calibration, stock height, fixture clearance and controller handoff still need to be verified on the actual setup.

I'm looking for a small practical case with a machine owner, not necessarily wood, and can help with a limited test implementation at no charge. What would be useful in your workflow, and what checks would you require before accepting camera-derived positioning?

The machine appears to be working, xyzab-tdr-kins kinematics as well.

I came up with the idea to look for the hal_pin_u32_newf string in my LinuxCNC sources.
And bingo!
The latest ones don't have this string in any files (except old translations files), but I found it in sources with file dates between July 14 and September 26, 2026.
I installed LinuxCNC compiled from those sources and everything works as it should, although there is still a lot of work ahead of me.

From the above, the following conclusions should be drawn:
1. If LinuxCNC developers don't come to their senses, everything will soon stop working...
2.Never delete old files, even if newer works.
3. If someone works with 2.10.0~pre1, don't try to switch to pre2, because it will hurt.

I can share the deb packages I have 2.10.0~pre1 compiled on September 26, 2026 (so I guess the latest pre1), but not here due to size. I could send it to some server, but I have no idea which one.

Some time ago I configured and launched a machine with ethercat drives.
Everything was working fine and would probably still work, but I had to update LinuxCNC.
I simply configure the machine with xyzab-tdr-kins kinematics.
I reached the point when the machine was correctly based, but then it turned out that LinuxCNC compiled a few months ago did not support the G12.1 and G13.1 codes, which are absolutely necessary.
So I compiled 2.10 from the latest sources downloaded from Github today.
After installing the new LinuxCNC, the machine cannot be started.I have tried various methods and I have the impression that it cannot be a problem with the configuration or the xml file, because even calling lcec_conf in the terminal gives the same error.I upgraded linuxcnc-ethercat ethercat-master libethercat-dev. Nothing helped.
I have not tried compiling lcec from sources, because there is no compilation environment on the computer controlling the machine, and the laptop on which I am compiling does not have a network card.

I've run out of ideas what this could be about and how to deal with it...

Praktisch müsste eine 7i97t für analoge Ansteuerung, Encoder für Servo, Glasmaßstab mit TTL Ausgang ausreichend sein. 
Die Karte hat praktisch alles was ich benötigen würde. Eventuell 0/1 Ein/Ausgänge sind zu wenig. 
Liege ich jetzt falsch? Oder gibt es einen Haken an dem ganzen?
Ich möchte ehest möglich bestellen. Hardware seitig bin ich fertig. Der Maschine fehlt nur mehr die Steuerung. 
Danke für eure Hilfe 
 

You probably didn't read the whole thread—this is what it's all about

I’ve had problems with my lathe after running ‘reference’ in Flex GUI.
When both axes are  homed, I can jog the X-axis without any problems.
But the Z-axis doesn’t move. If I run ‘unhome’ on the X or Z, I can jog the Z-axis.
I switched to Probe Basic and it works as intended with the same INI file
no problems with jogging once the axes are  homed.
I checked with HalShow, and the difference between Flex GUI and PB was that the telop
function worked on both axes in PB but only on the X-axis in Flex GUI.
In Flex GUI, the X-axis is 0 and the Z-axis is 1. When the axes are not at home, jogging works normally. Where should I look for the fault?

On a lathe, the Z-axis is No. 2, and on a mill, it’s No. 3. I think that’s where the problem comes from—previously, I had to have two Z- and two Z+ buttons; on one pair, I used jog_1_pb,
and on the other, I used jog_2_pb, which I used when the axes were homed, and it worked. When the axes weren’t homed, I had to use jog_pb_1 to move the axis. 
So why does it work normally in Probe Basic but not in Flex GUI?

As I mentioned earlier, in FlexGui, the Z-axis = 2 on a milling machine, and on the lathe, Z = 1. If I change Z to Y in the ini file to the following:
KINEMATICS = trivkins coordinates=xy
COORDINATES = X Y
[AXIS_Y]
Then I can jog the Z-axis after homing, just as it’s supposed to work,
but of course the lathe won’t run because it requires XZ.
So now I hope you’ll make the necessary changes so it works correctly.
 

 Here are the files again

 

If you have copied flex examples, here is a lathe starter

linuxcnc/configs/flex_examples/starters/Lathe/

There is:

[KINS]
JOINTS = 2
KINEMATICS = trivkins coordinates=XZ

[TRAJ]
COORDINATES =  X Z

[AXIS_X]
[JOINT_0]

[AXIS_Z]
[JOINT_1]

and use qpushbuttons  jog_plus_pb_0, jog_minus_pb_0, jog_plus_pb_1, jog_minus_pb_1