Advanced Search

We really appreciate all of the time and effort that is being put into this. Please don't get discouraged JT. For a moment I was afraid you were giving up when it went back to the old forum and the announcement you made about reverting. Looking forward to seeing the fruits of your labors.

I can hardly imagine the storage required for the many years that the forum has been collecting data. What is it, about 17-18yrs? Hosting it can't be particularly cheap or easy.

I am being plagued by the following messages:(LinuxCNC 2.10-pre1.)
What is this, and where does it come from?
Please don’t explain to me what it was supposed to be or what it should be—I already understand that.
The machine is running perfectly; nothing is jamming, and there are no suspicious sounds. Surely, if communication with the controllers were stalling for tens of milliseconds, I would notice it...

Unfortunately, my original thread was deleted during an attempt to migrate the forum to a new server.
Therefore, a brief introduction:
I purchased a Chinese rotary axis in a tilt/rotary configuration.
Mechanically, it works perfectly, but I’ve had trouble configuring the open-loop EtherCAT drives.
Replacing the motors with closed-loop ones is not an option, as none of the available models would fit.
After many attempts, I believe I have configured the drives correctly, but I cannot be certain.
That is why I needed a program that would run a large number of cycles—performing many movements—to ensure that the table returns to the correct position every time.
This is crucial; if the tilt axis were to stop in an unintended position, the machine would end up milling itself instead of the workpiece...

Naturally, this program can also be used to test a simpler machine, even one with only a single axis.
The program executes a specified number of movements and checks whether a sensor is in an active state; if it is not, the program stops.
I used a "home" sensor, but any switch placed anywhere on the machine can be used.
Minor adjustments to the `.hal` file are required, but the process is very straightforward—even a beginner should be able to handle it.
It essentially involves adding `motion.digital-in-00` to the line containing the sensor signal you wish to monitor (e.g., `joint.3.home-sw-in`), or adding a new line if you are incorporating an additional sensor.
Of course, the "home" sensor cannot also function as a limit switch. We can remove the relevant entry, or, once LinuxCNC is running, use `halcmd unlinkp <signal-name>` to temporarily disconnect the specific net.

And here is the program itself:

Hi,

I've built a thing. Or, more accurately, I asked Claude to build a thing.

I wanted to see how good AI coding agents have actually become. I didn't expect to make this public, but I think what came out of it might be useful to some of you as well.

It's a conversational lathe CAM program that I've called WOP (Workshop Optimized Programming).

It runs directly on Linux, not as a plugin for any LinuxCNC GUI, but as a standalone application.

I don't think it can replace full-featured CAM software for complex parts. But at least for me, most of the parts I make on the lathe aren't particularly complicated. So I see it as something in between full CAM software and Andy Pugh's lathe macros.

It currently supports facing, simple turning, drilling with canned cycles, threading, grooving, and turning along a custom path. It also has some machine-control features, such as optional stops that can be inserted between operations.

I'm the only person who has really used and tested it so far, so there may be things that seem obvious to me but aren't particularly intuitive to anyone else. Hopefully, though, it's fairly easy to use. That's really the main goal: to have a quick and straightforward way to program an entire part in a single file and export the resulting G-code.

If you want to try it out, it's open source on GitHub:  github 

If you want to see how it works, I've also made a YouTube video:



I'd be interested to hear what you think, especially if you get a chance to try it out.

no, running Maschine, sudo apt update ,- upgrade - --lost
2x new installation with Linuxcnc.iso + Manual -same
New Installation ,first Debian and linuxcnc ,ethercat over Synaptic - same
New Installation Debian and linuxcnc-ethercat apt repository manual -same

i have no Idea ...

I am working on a new, experimental EtherCAT layer for LinuxCNC.

You might be interested in the tool ecatsetup even if you don’t want to commit to this idea just yet.
ecatsetup is a tool to commission EtherCAT slaves/drives, test-drive, connect in hal and more.
It doesn't generate a XML file and never will. But you can find the necessary info you need in the tool.
Start here github.com/MetalMusings/ecat, find Getting started and try it.

The complete kit includes
- user space EtherCAT master, derived from IgH master 1.6.8
- the ecat.so hal module (replaces lcec), between linuxcnc and the ethercat master, and between ecatsetup and the ethercat master.
- ecatsetup graphical tool for commissioning of EtherCAT drives, test drive, troubleshoot, connect to hal pins, monitor and record EtherCAT master and slave behavior of a running LinuxCNC machine..

It completely replaces the current EtherCAT kernel master and lcec and tools.
Slave support builds on support of profiles, currently CiA402, mdp and generic. Deviations and specials are handled via "quirks".
CiA402 has support for csp, csv, pp, pv and hm. One only or shift between two or more. All homing methods,  35 and 36 are tested and the other methods await testing..
A new markup-file is used to communicate settings between ecat and ecatsetup. You are not supposed to read the file; you are not supposed to write it either. ecatsetup reads and writes it. ecat reads and uses it. There is a one-time conversion possible from existing XML files. Writing XML will never be supported.

You can use ecatsetup on any LinuxCNC version, that's the intention.
ecat and user space EtherCAT master is built using 2.9.4 and you will need that. Support for LinuxCNC 2.10 is planned and will happen sooner with shown interest.

For more info (and there is a lot!), visit github.com/MetalMusings/ecat
 

 

Hakan,
You are always helpfull, thank you.

I've machined a few parts with the new spindle now and I have to say that I'm very happy with how it performs. It really transformed the machine as I can mill at much higher feed rates and still get better surface finish and the tools are properly ejected from the spindle every time without getting stuck.


 

 

 


I ran into a new issue however. With higher spindle speeds, higher feed rates and deeper cuts the chips carry much more energy causing them to fly much further. One place they like to fly was into the spindle drive belt so I had to design and order a larger sheet metal cover for the head.


 


Here it is installed on the machine with a 3D printed extension added to protect the ways.


 

 


Also my table based enclosure isn't containing the chips like it used to at slower spindle speeds. Now the chips bounce around inside until they find their way out onto the floor around the machine especially during roughing operations. I probably have to look into building a full enclosure going forward. Preferably one with an integrated box for chip collection in the stand below the machine.

Yes, two processes should help and that is what Linuxcnc does. RT with access to ethercat master in one process, and GUI and such things in other processes, shared memory. You should be able to reach a few usecs jitter.

Measure with rtla timerlat and osnoise on CPU3 before and after. What remains isn't TLB.

It was just an idea to perhaps open up the mind of possibilities.
I think you are underestimating Claude though, it can absolutely do this.
And many other things, such as optimizing your settings for minimal latency etc.

Anyway, doesn't matter. JT will fix it, I am sure, just trying to be helpful.
 

I Just want to say many thanks to all involved!!
I used to host a forum myself in the past and understand struggle you are going throug.

Hi everyone,

I’m investigating occasional 10–20 µs jitter in a custom Qt/IgH EtherCAT application, and would appreciate advice from LinuxCNC users.

Setup:
- Intel N100, Debian 13, PREEMPT_RT 6.12.107.
- 250 µs / 4 kHz cycle.
- RT thread on CPU3, SCHED_FIFO 80, nohz_full=3.
- GUI/rendering/database threads on CPUs 0–2.
- Memory locked, SAGV disabled; CPU3 fixed at 800 MHz.

All application threads currently share one process/address space.

Tracing shows Qt mprotect() and Mesa munmap() activity followed by TLB flushes on CPU3. Two +11 µs cycle-interval spikes aligned with these events. SQLite shared-memory file writeback also triggered TLB flushing, although I have not matched that to a jitter spike.

The largest untraced peak was +17 µs, so I am not claiming TLB explains every spike.

Would moving the RT loop into a separate process, communicating through preallocated fixed-size shared memory, be the recommended approach?

Has anyone measured similar interference or successfully reduced it? Are there relevant LinuxCNC implementation examples or other measurements you would suggest?

Please be patient. We are working on a solution that would retain all existing data.
Thanks!

In my opinion, the error lies in the very premises.
The forum contains knowledge that should be preserved.
Deleting content based on date makes no sense, as there is plenty of recent junk alongside a wealth of valuable, albeit old, information. Similarly, removing attachments is pointless; while the thread might remain, it would become either useless or even incomprehensible (for instance, a post saying "I have a machine like the one in the photo" when the photo is no longer there...).
If the forum is no longer usable, it should be closed, and a new one should be opened.
The approach should be to first disable create the new acounts, disable the creation of new threads, then gradually restrict the ability to reply to existing ones.
At the same time, a new forum—with a new name and a new address—should be set up for the creation of new threads.

jazzkramer wrote:

The button is a G0 X0 Y0 only (or it has Z0 as well? I have to check).
If I wait the Z axis to be at the idle height before pressing that button, the next cut properly works.

This is most definitely fixed in v2.10-016.092. It is impossible to click a button of that type until the interpreter is idle again.