Advanced Search

Hello everyone,

after all these years, I finally seem to have found a solution to the problem described in this thread.

I should mention that I'm not really a programmer, so I investigated this with quite a bit of help from AI. Essentially, an amateur debugging LinuxCNC with AI assistance.

The original problem was that when jogging an axis using the arrow keys in AXIS, moving the mouse pointer into an embedded GladeVCP panel and releasing the key could cause the axis to continue moving.

I reproduced the issue in an isolated LinuxCNC 2.9.10 simulation and added some debugging output to AXIS and GladeVCP.It turned out that GladeVCP correctly receives the KeyRelease event, but the forwarded event does not always reach AXIS.

The solution appears to be surprisingly simple:

In lib/python/gladevcp/xembed.py, inside keyboard_forward()

add d.flush() immediately after fw.send_event(fe):


fw.send_event(fe) d.flush()


I performed an A/B/A test:

- With d.flush(): Jogging stops correctly.
- Without d.flush(): The original problem returns.
- With d.flush() restored: Jogging stops correctly again.

I also restored the original LinuxCNC 2.9.10 xembed.py and applied only this single-line modification. The fix still works.I tested repeated jogging and switching between axes, releasing the arrow keys while the mouse pointer was inside the GladeVCP panel. So far, the problem has not reappeared.

Please note: All testing was done in a simulation, not on a real machine. This is not a safety validation.Since I can`t guarantee that this is the correct upstream solution, it would be great if someone familiar with the XEmbed implementation could review the change.Maybe this little fix can finally put an end to an issue that has been around for quite a few years!

I attached the modyfied xembed.py file.

Best regards,

Jan

We discussed this idea at the LinuxCNC meet-up in Stuttgart (and this particular post in the video meeting just now).

One way to approach this was, we thought, to allow multiple LinuxCNC instances to share a HAL space to allow interprocess communication. At that point it feels like a HAL namespace problem. but fairly simple.

I am unclear (scanning this during the meeting) whether this is a fork, add-in or potential PR to the main LinuxCNC project.

hi, this is very grate news,

i am in the UK,

i have a Citizen L16 laying around (did offer it on her for sale etc) its waiting for a new life as the old control boards are dead.
i'v done many linuxcnc retrofits over the years of milling & Turning for the sliding head iv been waiting for someone todo this much needed addition work. so thank you for taking this on.

i have other sliding head lathes too and multi axis spindle machines so i am willing to retrofit the old Citizen L16 and help you develop this along its road path as is needed from a lathe point of view and usage and test and help you add functions to it.

let me know how how i can help out etc

Thanks to all for reading, found I guess everything so far.

Regards
Roman

And yet, it still doesn't work...
Versions 1.46 and 1.47 can be installed, but they refuse to run because they fail to detect a library that is, in fact, already installed—and I haven't been able to find a newer version anywhere.

Version 1.45 installs and appears to work, but then it’s impossible to install `cia402` (another round of "congratulations" to the LinuxCNC developers).
I tried using the source code from the repository github.com/rodw-au/cia402_homecomp, which works with the `pre1` release...
I haven't been able to find any newer versions either.
Compillation returns many "lvalue required as left operand of assignment" errors, that say nothing.

I tested it on an real machine.
Unfortunately, it didn't work as intended.
That is to say, everything was fine when homing a single axis, but when homing all of them at once, things got really strange...
This sort of thing often happens when you're working with someone else's code. While it’s fairly easy to understand what a given function does, it’s much harder to figure out the order in which those functions are called.
Essentially, the state of the `joint.N.homing-inhibit` pins was being read at the wrong time—or, more specifically, it wasn't being updated.
Running a program with outdated data never ends well...

I took a bit of a shortcut, but I concluded that the `joint.N.homing-inhibit` pins should be ignored when homing all axes simultaneously. This is because the entries in the `.ini` file already define the correct sequence, ensuring that each axis is positioned in a way that allows the next one to be homed.
Everything is working as expected now.
The files in my previous attachment were for LinuxCNC 2.10-pre2, but since that version doesn't support EtherCAT, I’ve prepared a patch for LinuxCNC 2.10-pre1—the version I’ll continue to use.
In principle, the only differences should be in the line numbers (the `homing.c` files differ in length between the two versions). With a little tinkering, it should be possible to apply these changes to even older versions (though you might need to adjust variable types in the declarations).

I’ve also written a HAL file containing the necessary logic. It uses the `near` component to compare the position of the B-axis against a target value within a specified tolerance, and the `and2` component to verify whether the B-axis has been homed—ensuring that the reported position is reliable.
This can also be implemented without modifying LinuxCNC sources; however, instead of `joint.N.homing_inhibit`, you would need to use `motion.homing-inhibit`, which prevents homing for all axes. While not exactly the ideal solution, it is certainly much better than nothing.

 

Both machines were put up for sale because the workshop they were in was damaged in a strike. I bought them and I've been slowly rebuilding them since. Here are a few photos from my archive.
As for the specs: Both the lathe and the mill have ballscrews on all axes. The spindles are equipped with monoblock induction motors paired with VFDs (the HS - High Speed version).
On the lathe, I initially wired the spindle via a 0-10V analog signal because I couldn't figure out the RS485 character-based text protocol at the time. However, I finally cracked it this year. Thanks to AI, I managed to write a driver. I used the mill's motor for testing. I’ll be integrating this solution into the lathe a bit later.
So, I’d be glad to hear any advice and look forward to the discussion!
 

To put it briefly, I was forced to leave my home workshop behind due to the war. But since I love working with machine tools, I later bought myself a couple of used "baby" CNC machines — a Wabeco lathe and a Wabeco mill. I immediately set the stock control systems aside.
The Wabeco lathe has been up and running for over a year now, powered by LinuxCNC + Mesa 7i92 + Chinese 400W servo motors.
As for the Wabeco mill, I’ve rebuilt it, repainted the enclosure, and so on. Right now, I'm very slowly putting it together using the stock stepper motors and a Chinese XC809D controller (which was a gift). To be honest, it hasn't really impressed me so far, so it might just be a temporary solution.
I don’t have an urgent practical need to switch to EtherCAT.
My main driving force is pure curiosity and a desire to figure it out to the point where I can work with it effortlessly. Naturally, the first question that came up was: what is the most elegant way to handle encoders? As a backup plan, I'm considering installing a second network card and running EtherCAT alongside Mesa simultaneously (using Mesa to handle encoders: one for the spindle + manual pulse generators for each axis).
So, here is what has been done so far:
• Installed the IgH EtherCAT Master (EtherLab) + linuxcnc-ethercat + cia402.
• Ordered a Lichuan LC10E servo kit with a 23-bit absolute encoder from AliExpress (currently in transit).
• Bought locally (and quite cheap) an Omron NX-ECC201 coupler (1 pc), ID5342 digital input modules (3 pcs), and OD5121 digital output modules (2 pcs).
The Omron hardware should arrive in a day or two, so I’ll start experimenting with EtherCAT using that, and then the servo kit will arrive. First, I'll take it step by step to learn the ropes, and later I might convert the lathe to EtherCAT. But the ultimate goal here is self-development and the enjoyment of learning something new. The practical benefits are taking a back seat for now, but they might come in handy for future retrofits. Once everything settles down, I really want to bring a small CNC lathe with live tooling over from Europe.

Hi Shu,

Thanks for the info and the servo tuner script. I had to take a break from working on the mill for the moment.

At the moment all the axis are moving and the servo spindle runs (still need to check the config on it). I am working on the lubrication system at the moment. It is making a huge mess so I have to figure that out before I work on the movement more.

Thanks for the help

You are welcomed, always.

Tommy thanks for your quick reply. I am new to the CNC world, looking to build my own CNC Router Table with LinuxCNC controller.

The task turned out to be a bit more difficult than I had anticipated.
Although HAL provides the pins and flags necessary for the required configuration, they cannot be easily utilized—for instance, simply by adding entries to an .ini or .hal file.
The developers of LinuxCNC recommend writing and compiling a custom "homecomp" component; however, I concluded that it would be simpler and more effective to modify the `src/emc/motion/homing.c` file.
Firstly, this modification is straightforward and requires only a basic understanding of C programming.
Secondly, the newly created pins are inactive by default; if a user chooses not to employ them, the system continues to function exactly as it did before the changes.
Thirdly, this is a versatile solution that could prove useful for other configurations as well.

Here is how it works:
 
 
The first image illustrates a scenario that, in principle, should not occur: the homing process for the Y-axis (joint 1) is blocked prior to the initial homing sequence. While this shouldn't happen, it was necessary to test it. As shown, all axes complete their homing process—with the exception of the blocked axis, which remains in its pre-homing state, as intended.
The second image shows the state after unblocking the Y-axis homing, performing a full homing sequence, executing some movements, re-blocking the Y-axis, and then running the homing sequence again. As can be seen, all axes complete their homing and zeroing—except for the blocked axis, which retains its existing homing status and position.
Now, it is possible to configure everything within a .hal file using standard LinuxCNC components. For example, to prevent an axis from being re-homed, you simply need the following line in your HAL file:As for the modified `homing.c` itself, it works as intended: it blocks the homing of a specific axis and displays a message informing the operator that the outcome of the homing process may differ from what they expected.
I suspect some of the changes might be redundant, which could result in the same message being displayed multiple times. I haven't been able to verify this, but it poses no real risk—it’s merely a minor nuisance. The message itself could also be refined to look better, though that would be a purely cosmetic change.

A brief summary of the changes:
I have added new boolean pins, `joint.N.homing-inhibit`, one for each axis.
By default, these are set to `FALSE`, so if they are left unused, LinuxCNC will behave exactly as it did before.
Setting a pin to `TRUE` will exclude that axis from the homing procedure—leaving it in its current state—and trigger a warning message for the operator. No other actions are taken.
 

Dear all,
thank you for all the work that has been done in the last years to LINUXCNC.

I upgraded/changed years ago my machine hardware and then the project stopped, version 2.9 came and I missed the upgrade tool.
Now finally I found the time my hardware is ready setup & new qtplasmac is running and still can't get some of my old features.
Thank you for your patience and help.

xbox controller
I was using a xbox controller which I setup now with pncconf, checked the pins and signals in halmeter, they are working.
Checked my hal, seems to be ok, but the thing will not jog , am I missing something (activate in Gui?)

 

User Button

My crosslaser is connected to the mist I think 06 pin, and it works with offset setting etc. 
I wanted to turn it on with a user button M7 on M9 off , did not work, I was not able to find in the documentation which commands are needed or possible in user button setup fields.
 

color change

is it possible to change the color of the hallshow?
the tree is so dark , I changed the linux debian theme already but it did not help.
 



I hadn't played around with the system much due to setting up and configuring . 
I was using before for the offset between torch and crosslaser a command as well on the xbox controller with a button
#connect mdi commands to button presses
net xbox-a halui.mdi-command-00
net xbox-b halui.mdi-command-01
net xbox-x halui.mdi-command-02

BUTTON_10_NAME           = Laser\ON
BUTTON_10_CODE           = M7
BUTTON_10_IMAGE          = 
BUTTON_11_NAME           = Laser\OFF
BUTTON_11_CODE           = M9
BUTTON_11_IMAGE          = 
BUTTON_12_NAME           = Move\Reset
BUTTON_12_CODE           = o<offsetmove> call

[HALUI]
MDI_COMMAND = M7
MDI_COMMAND = M9
MDI_COMMAND = o<offsetmove> call

so the offset was o<offsetmove> sub
G10 L20 P1 X0 Y0 Z0
G0 X31.787 Y19.331
G10 L20 P1 X0 Y0
o<offsetmove> endsubare these still possible to add to the xbox controller in the same way?? (custom.hal??)

Can the offset be set in the ini ?? manually or do I need to use the GUI so setup?

last question for this time when I run into the end stop, I need to got to settings, enable override limits , go to main power off on maschine then I can override the limits. is this the correct way?
I read that you only have to press the estop and it continues which does not work on my machine.

Big part will be the arc voltage which was on mine to high on torch start and phillc54 made an exception for me to get it running years ago, will test soon
I guess ingore arc ok may help.

 thanks a lot,
Roman

Hello dberegovoy,

i retrofitted a Maho MH400E and therefore worked with various Beckhoff encoder inputs. Plug and play support is there for pretty much most of their encoder terminals. I tested the EL5021, EL5101, EP5101 and EL5002 terminals. All of them work flawlessly and are available for cheap on ebay, starting at ~50€/piece. If you want to go down the rabbithole of creating yoir own EtherCAT slave, you can certainly do that, but it willl take quite some time and you don't have any support or industrial quality whatsoever.

A list of all supported EtherCAT slaves can be found here:
github.com/linuxcnc-ethercat/linuxcnc-et...mentation/DEVICES.md
Claude also built me drivers for all of my not yet supported terminals:
github.com/PedPEx/linuxcnc-ethercat

Keep us posted with your lathe details

Hola!. Mi viejita cpu con Linuxcnc 32 bits, trabaja en la prueba de Latencia, unos 33 grados celsius, muy poco. Me gustaría poder configurarla mejor, para sacar mejores resultados. Tiene grasa disipadora nueva, bateria nueva, ssd, y sus 2 módulos de 512 megas ddr de ram, llegando a sus 1024 megas de ram, y la eleg{i por tener su puerto parelelo en su mother. Gracias!...