Advanced Search

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.

 If so then you weren't the only one. I was trying to buy something yesterday myself , Everything was going 
as per usual until it came time to pay then all I got was an error code. Last night I found out why.
Apparently this is a worldwide outage.

I guess I'm not very tech-savvy. I couldn't find a link to the Bookworm DEB package at the bottom of the page (and I need to figure out whether it's the real-time kernel version or the userspace version).

5 years using mesa cards and this is the first time i had issues.  The cards i'm ordering via cnc.prom.ua (the same price ±, like on the official site but not need to pay customs and tax) Usually they came already opened (the sticker is damaged), maybe they testing it, or just puts their logo.
I found only DS26LS32CM,  AM26LS32AC  , AM26LS32ACDR,  26LS32AC  (which can be used?)

So, the used 7i96s card, which was on a lathe. Signal wires on one side of the El.box, power wires on the other side of the El.box - nearly one year worked well:
ch-a - working
ch-b - not working
ch-i - not working
   

The new 7i96s (rev E was not used and not tested after arrival) :
ch-a - working
ch-b - not working
ch-i - working
     

yeah, I put EtherCAT logo on my device already, and I am now one of the owners of linuxcnc-ethercat, so we should be good, I take responsibility, please share, or if you prefer mail it to me luca at aitalmac.com

github.com/LinuxCNC/linuxcnc/actions/runs/25025393650?pr=3973

look here at the bottom of the page

Here's a program snip from the last round of unsuccessful testing:



As I mentioned earlier, I've also tried the G43 on a separate line, with and without the Hn word.  I added the M1 just to stop the pgm before the spindle ramps up during testing.

The X-values are all negative based my post processor (gang tool slant bed back-lathe, X+ is 'up', and T2 is on the 'negative' side of things).  The motion is correct for my particular setup.

If I start the above program with T2 loaded and offsets applied (via MDI or GUI cmd), everything works...until the next tool change.

I've also attached my remap.py and stdglue.py just in case there's something in there messing things up.

Thanks for having a look.