Advanced Search

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.

A port address change would prevent the step/dir outputs from working,
so it's probably not that.

You might check that you get a valid voltage change at the limit switch pins,
in case there is a wiring problem.

Another possibility is that the new motherboards parallel port lacks pullup
resistors on the input pins, and the breakout board expects these pullups.
( This problem has happened before with parallel port systems and would
have similar symptoms, that is, input pins always read low )

Hakan wrote:

Will I get banned if I propose to let for example Claude look into this and do a test migration?

No, and no.
Claude can not help with this, but it can help quite a bit with fixing minor issues.
Also, giving full server access to claude is absolutely not OK.

Hello community! I need some expert help to restore the automatic homing sequence on my 2014 PROBOTIX Meteor.
Current Status:
• I am running LinuxCNC / AXIS version 2.5.0 on an older PC.
• The machine is perfectly calibrated by software. Motors are running fine at 240 in/min, acceleration is dialed in, and the SCALE is correct (-1685 for X and Y).
• Since automatic homing wasn't working, I successfully set up a "Virtual/Manual Home Routine" by setting HOME_SEARCH_VEL = 0.000000, HOME_LATCH_VEL = 0.000000, and HOME_SEQUENCE = 0, 1, 2 inside the .ini file. The software references perfectly in the air and my soft limits (MAX_LIMIT) protect the entire table (25x50").
The Problem:
I want to recover the physical automatic homing sequence, but LinuxCNC seems completely blind to the physical switches.
When looking at the HAL Configuration screen (Pins ➔ parport ➔ 0), the pins parport.0.pin-11-in (Z), parport.0.pin-12-in (Y), and parport.0.pin-13-in (X) are constantly stuck on FALSE, even if I physically click the microswitches on the machine with my finger. The inverted signal (-not) stays on TRUE all the time.
My Question:
Has anyone with a 2014 Unity Box experienced this? Is this a known hardware issue like a loose common ground wire inside the breakout board, a faulty ribbon cable, or do I need to look for a specific pinout override in my .hal file?
I am attaching my current .ini and .hal files. Any guidance on where to look inside the breakout board or the wiring would be highly appreciated. Thanks in advance!

Note on Hardware Alteration: Please note that the original motherboard supplied by PROBOTIX was replaced with a different motherboard. I am still using the original 2014 Unity Box and breakout board, but the parallel communication is now handled by this new motherboard setup. Could this motherboard swap change the base address or cause a voltage mismatch on the input pins (parport.0.pin-IN), even though the motors (parport.0.pin-OUT) are outputting movement perfectly?"

mwc wrote:

Just a quick thought, given how Kunena stores attachments, could you download enough attachments to free up server space for the uograde/conversion, delete them from the server, then reupload them after?

Would be a bit time consuming/bandwidth consuming though.

(I've got no idea whether the upgrade actually does anything with/checks attachments, so it may not be possible or cause more problems)
 

It would be a database hell  to try that. There is no problem creating a new droplet from a snapshot of the current forum then upgrading the OS, Joomla and Kunena on the new droplet. I've already done that once with no problems.

We are looking into ways to improve our storage and memory to make the forum run faster, but it has to be long term.

JT

Hakan wrote:

How about getting the storage you need for a full upgrade/conversion.
Then start trimming.
 

You can't go down in storage size after you increase it. A straight across is no problem.

JT

Just a quick thought, given how Kunena stores attachments, could you download enough attachments to free up server space for the uograde/conversion, delete them from the server, then reupload them after?

Would be a bit time consuming/bandwidth consuming though.

(I've got no idea whether the upgrade actually does anything with/checks attachments, so it may not be possible or cause more problems)

How about getting the storage you need for a full upgrade/conversion.
Then start trimming.