Advanced Search

@Andrax
I'll try it, thanks.

@Maha
like @Aciera, I didn't think that was how M6/G43 worked, but I'll try it (again).  I've tried putting G43 on the next line after the Tn M6 (or M6 Tn) line, but that didn't seem to make a difference.

@Aciera
Thanks for pointing that out.  I think I tried the RETAIN_G43 when I first noticed an issue during the G10 L2 WCS flip testing a couple weeks ago.  I know I haven't turned that on/off during this last round of fiddling.

Among the many things confusing me is the F360 post for LCNC turning.  right at the beginning of the post file is this:

But the post outputs no G43 at all - neither on the same line or the next.  Something to sort out once I get G43 working.

I'll try everyone's suggestions this evening and report back.  As usual, I'm grateful for the assistance.

How did you get linuxcnc originally? What version are you using?
What mods would you like to do?

Hey zusammen,ich hänge gerade ein bisschen fest und hoffe, jemand von euch kann mir einen Schubs in die richtige Richtung geben ,Ich habe eine Maho 500 W4 mit einem Servomotor, der analog im Closed Loop läuft. An der Maschine ist ein 3-gängiges Getriebe verbaut:
1:1 (ca. 650–5000 U/min)
Neutral
Untersetzung (ca. 20–649 U/min)

Ist wohl ähnlich wie bei dem User Dowerna hier aus dem Forum.Mein Problem: Ich bekomme den Gangwechsel in LinuxCNC einfach nicht sauber umgesetzt. Ich hab mir das mit der[/code]

so G43 in a line with M6, sets G49

Not sure I understand this right but 'M6 Tn G43' certainly works fine for me.

@spumco
Have you tried without 'RETAIN_G43 = 1' in the ini file? (you have one line commenting it out and another later on activating it)

It should, just try it, it is a small download and easy to try

In one picture you have the encoder inputs connected, this may affect test results.

Here is the encoder input circuit, you can check if the 26LS32 is faulty by seeing of the
outputs follow the input state. (the outputs are inverted from the TTL input levels)

 



 

Thanks, I downloaded and installed it.
The latest changes to my configuration were as follows: I have a machine with a rack-and-pinion system. It has a good control board and cable. The XXYYZ configuration, Matrixkins—I backported it myself from the source code, adapting it for 5-motor control. The configuration has been tested and works.

To ensure the minimum Z-axis step size was acceptable for scanning, I switched the step divider from 8000 to 25000. For my speeds, I had to reduce the value
[EMCMOT]
#edited 2026-03-21 due to jitter tuning not exceeding 2800 (previously 8000) - base_period reduced from 20000
EMCMOT = motmod
COMM_TIMEOUT = 1.0
BASE_PERIOD = 10000
SERVO_PERIOD = 1000000

What did this lead to? Version 2.8.4 with these same parameters works like a charm. The version you sent displays a message at startup - -
Unexpected realtime delay on task 0 with period 10000
This Message will only display once per session....


then goes through homing

+ and when attempting to move the Y-axis, the Y-motor emergency protection trips (torque overload). Obviously, something is wrong with my Matrixkins. Apparently, my participation in testing is causing more problems than it’s helping.

Just wanted to send a quick thank you to Rodw and Jerry. I have managed to go through the first part of the video and the cyber black hole of networking has been cleared up somewhat. Will advise my success or lack therof when I have a chance to sit down and go over things. Wayne

You can check for G43 in Linuxcnc status. Eg Axis:


 


M6 turns off G43, 
so G43 in a line with M6, sets G49 

I'm not entirely sure about this either.
At least G10 only affects the currently selected coordinate system. As soon as you switch, your shift disappears.
It could be the same with G43, since you're applying the length correction to G53.

Just try it out.

Discord seems to be aimed at gamers that like flashy colors.

github.com/LinuxCNC/linuxcnc/actions/run...artifacts/6673490803
is uspace preempt-rt

I was under the impression that a 'G0 G53 Xnnn' line doesn't change the active WCS to the machine coordinates, it just causes LCNC to move to a machine coordinate for that line only.

Second, if a change in WCS causes the tool offsets to be removed everyone using LCNC would have to write programs with G43 after every WCS change.

More importantly, the order of G53-G43-G54 is what is output by the Fusion 360 standard LCNC turning post.  I can't be the only one using that post; if that order was wrong everyone who uses the post would be having the same problem.

I will certainly try out your suggestion this evening even if I'm dubious.  And thank you for giving it some thought.

I see
G53...
G43...
G54...
G43 currently refers to the machine coordinates. Then you select coordinate system 1.
That might be why G43 becomes ineffective.
Write G54 before G43
G53...
G54...
G43...
In MIDI, by the way, the last coordinate system is always active, so G54.

I hope this helps

regards

All those dodgy Chinese routers marshaled into a botnet. I don't use TP-link but the ISP's insist on using them.
One example. www.malwarebytes.com/blog/news/2025/09/t...crosoft-365-accounts.
So far they've not found my home network.