Search Results (Searched for: )
- my1987toyota
19 Oct 2026 10:51 - 20 Oct 2026 11:02
Replied by my1987toyota on topic Usefull Open Source software, vibe coded in Rust
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".
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".
- Muzzer
19 Oct 2026 10:35
Replied by Muzzer on topic HAL for open-loop encoder homing
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.
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.
- suspension
19 Oct 2026 10:26
Z location seem to be wrong with auto tool measurement was created by suspension
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
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
- Alexf2a
19 Oct 2026 08:49
Replied by Alexf2a on topic HAL for open-loop encoder homing
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!
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!
- tietouwa
19 Oct 2026 06:44
Replied by tietouwa on topic J1900 L2 sibling: pin Qt HMI to CPUs 0-1, keep the 1 ms EtherCAT thread on CPU3
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.
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.
- Holzwurm56
19 Oct 2026 06:29
LCNC and Stepspeed? was created by Holzwurm56
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
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
- Screph
19 Oct 2026 03:07
Camera-based workpiece alignment and AI-assisted toolpaths: Screph demos was created by Screph
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?
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?
- tuxcnc
18 Oct 2026 20:01
Replied by tuxcnc on topic lcec_conf error (newest lcnc 2.10 and debian 13)
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.
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.
- tuxcnc
18 Oct 2026 19:12
lcec_conf error (newest lcnc 2.10 and debian 13) was created by tuxcnc
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...
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.
Code:
lcec_conf: symbol lookup error: lcec_conf: undefined symbol: hal_pin_u32_newf
Code:
# halcmd loadusr -W lcec_conf test.xml
lcec_conf: symbol lookup error: lcec_conf: undefined symbol: hal_pin_u32_newf
# lcec_conf
lcec_conf: symbol lookup error: lcec_conf: undefined symbol: hal_pin_u32_newf
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...
- Hermle_Gerald
18 Oct 2026 19:12
Replied by Hermle_Gerald on topic Hermle auswahl Mesa Karten
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
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
- yaska
18 Oct 2026 18:39
Replied by yaska on topic Z-axis doesn’t move
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.
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.
- yaska
18 Oct 2026 18:32
Replied by yaska on topic Z-axis doesn’t move
Here are the files again
- MaHa
18 Oct 2026 17:33
Replied by MaHa on topic Z-axis doesn’t move
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
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
- dirkx
18 Oct 2026 17:13 - 18 Oct 2026 17:15
carousel - persisting the last state & homing - what is best practice? was created by dirkx
I've got a Deckel/Maho DMC70V here with a 30 slot carousel for its tools; its Dialog112/MELDAS600 brain has been replaced by Ethercat & LinuxCNC.
I've automated part of this with the carousel(9) real time component; and this works well overall & is quite reliable Actual config at the end of the message. Now I am struggling with two things:
I've automated part of this with the carousel(9) real time component; and this works well overall & is quite reliable Actual config at the end of the message. Now I am struggling with two things:
- How does one trigger this cleanly when normal homing completes (the spindle needs to be in the home position for the carousel/arm to safely home) -- and then ideally so that if the carousel homing does not come complete/come-on - the machine is not declared fully homed; just like it would for an axis ?
- On startup - if the tool changer is in a low slot - it will insist on doing a full rotation with increasing numbers; thus making a full circle; even though it could just go back one. What is the right way to persist the last position on closing linuxcnc(1) ? So that it can use this to home a lot more efficiently ?
Thanks !
Dw.Code:# Deckel-Maho DMC70V toolchanger carousel, 30 slots, can be rotated in both # directions; with a brake sensor on the motor that controls the wheel and # a pocket sensor that confirms it stopped at the right spot. General control # is to power on the motor in either direction until you see the brake sensor # coming up; then stop the motor and check that the pocket sensor confirms # a stop in the right place. If not -that is usually caused by a tool or arm # with something still in it & needs manual intervention. # # S202 is the slot signal & S201 is the brake now; stop motor power on rise and # then wait for S201 to go high. # net carousel-index-sensor S200-input => carousel.0.sense-0 atc.led-carousel-index net carousel-pocket-sensor S201-input => carousel.0.sense-1 atc.led-carousel-brake net carousel-enable atc.button-carousel => carousel.0.enable <=> Magazine-output net carousel-active atc.led-carousel <= carousel.0.active # S202 will rise a bit later - to confirm correct position # and needs to be combined with the counter ready # net confirm-tool-in-pos S202-input => iocontrol.0.tool-changed atc.led-carousel-pocket net carousel-pocket-num iocontrol.0.tool-prep-number => carousel.0.pocket-number # Link motor direction outputs to your stepgen or VFD/relay drives net carousel-motor-fwd carousel.0.motor-fwd => Forward-output net carousel-motor-rev carousel.0.motor-rev => Backwards-output net carousel-current-pos carousel.0.current-position # Allow the jog buttons to work; propably need to be # tied to the interlock of MCall that then lights up # the light output # net carousel-motor-jog-fwd S274-input => carousel.0.jog-fwd net carousel-motor-jog-rev S216-input => carousel.0.jog-rev net carousel-homed carousel.0.homed => atc.led-carousel-homed net carousel-current-pos => atc.number-position
- Shu
18 Oct 2026 17:06
Replied by Shu on topic Tuning Steperonline A6 Servos
script for tuning the servos over the ethercat bus with the most important parameters:
github.com/shulter/biber-ethercat/blob/main/tools/servo-tune.py
github.com/shulter/biber-ethercat/blob/main/tools/servo-tune.py
Time to create page: 0.115 seconds