a {
text-decoration: none;
color: #464feb;
}
tr th, tr td {
border: 1px solid #e6e6e6;
}
tr th {
background-color: #f5f5f5;
}I’m currently developing this application, but I haven’t yet been able to publish it on the Play Store as an open test. I’m looking for users who can try it out, share their feedback, and help identify any bugs or issues that may still be present.Most of my current testers don’t have access to this type of device, so their testing opportunities are somewhat limited. If you’re interested in evaluating the app, I’d be happy to invite you. Just send me your email address, and I’ll provide you with the Play Store testing link.Thank you for your time and willingness to help improve the app. Your feedback would be greatly appreciated.
   
LinuxCncDroid is a high-fidelity, touch-optimized industrial Human-Machine Interface (HMI) built for monitoring, controlling, optical centering, and metrology calibration of CNC machine tools powered by LinuxCNC and Machinekit.Crafted natively in Kotlin using Jetpack Compose and Material 3 Industrial Design, LinuxCncDroid provides out-of-the-box support for industry-standard fieldbus topologies (Mesa FPGA, EtherCAT, and Parallel Port), featuring real-time telemetry, a haptic Virtual MPG Handwheel, an interactive 3D G-Code Toolpath visualizer, 3D probing routines, live camera crosshairs, reactive Metric (G21 mm) / Imperial (G20 inch) switching, and an ISO 230-2 metrology calibration wizard.

Hi Andy,

I actually discussed this idea with Michael Haberler about 15 years ago, and I left it alone for a long time because of the complexity involved.

When I finally took it on, it required a substantial amount of reworking across the existing code. It took several attempts and a few changes in direction before I found an architecture that worked for what I wanted to achieve.

The shared HAL approach is an interesting option. In my case, finding a workable overall concept was a major part of the effort.

It’s good to hear that this is being discussed at the meet-ups as well!

Hi Rob,

Thanks for your message and your offer to help with testing and development! Your Citizen L16 sounds like a great candidate, and your experience with sliding head lathes would be very valuable.

I’m currently in California and will be back in Europe on 13 November. Given the complexity of the project, I’d suggest a video or phone call to discuss the machine, its existing hardware, and the requirements for the retrofit.

I’d be happy to support you with integrating the new system into your Citizen L16. Testing it on a real machine and getting your feedback would also help us develop and refine the functions needed in practice.

Let’s arrange a suitable time for a call.

Best regards,
Daniel

Goooood morning/afternoon/night!
So after tons of hours of working with colleges we had to drop linuxcnc core because of hundreds of limitations and we have to write eveything from scratch. I can explain why and how this soft is done if you are intereset but for now some pictures and a video of the whole new parser, 90% $iemns compatible (also ISO mode compatible), HMI is based on same UI for operator familiarity but i added several "always i wanted" features.

Here we go: jerk controlled movements, feed blending, PLC codesys based making a toolbox, up to 31 axis (why? because i just wanted to..cpu and ram makes the limit), hmi can run on separate pc if more power is needed, multithreaded realtime subsystem running in xenomai (migrating to jailhouse soon) (actually rtapi from linux cnc has a huge design problem, it only runs on one cpu core and each thread has less priority than the previous initialized, that was the weakest point found to make as drop it completely), work offsets, tool offsets, machine data with access protection, multichannel (up to 10 right now, why? because i wanted to.. again, cpu is the only limit) with synchronization (waitm commands plus others), up to 10 mode groups (several channel can group in different mode groups so, going to jog mode makes all channel from same group change to jog, same for mdi, auto, etc..)


youtube.com/shorts/kW06KXbYc_0

Best regards, enjoy!


 

I think I've found a solution to this odd behaviour:

Link to old topic...

I would be grateful if someone could test and
replicate the solution.

Best wishes, Jan

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

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