Advanced Search

I wonder if TSN works. At least without modifications.
Do you have any real-world experience with that?

In the  flyer I read that while the master can be unaffected, at some point the slave needs to support TSN either directly or via a TSN switch in front of it.

The i210 is an excellent choice, albeit a bit old now. I have good luck with the i217 and also with the latest dirt-cheap i226-v adapters. Older adapters use the igb driver, newer use the igc driver, with some different options and defaults.

Thanks a lot for your reply. I ran the latency test at the beginning of this project. At first I had some issues because of the drivers (realtek 8168), and sometimes it would stop with a “Finished reading” error. After a bit of trial and error I changed the drivers as suggested in some threads, and now it runs fine: no packet loss, and both average and maximum latency stay below 70 µs, so I think I’m good.

JT wrote:

Also note that there is no /etc/apt/sources.list.d/debian.sources in my Debian 13 after doing a full upgrade.

JT

yes the old format is retained on a full upgrade from Bookworm but it will nag you on an apt update to run sudo apt modernize-sources if I got the spelling right...

Debian says the old format will be removed in time.

Hartwig wrote:

Dear members,

my Leinen FM1 is now running with LinuxCNC on all 4 axes.
I have built a small cubicle containing the required components. I have not modified the original setup at all. The CNC cubicle can be activated by a simple changeover of the original plugs coming from the mill (HONDA MR 50 pin and 20 pin plugs and the 4 Heidenhain plugs) from the original control panel to the CNC cubicle.
The relevant hardware I'm using is
- MESA 7i97T
- 1 Heidenhain EXE with 3 channels from a MAHO mill (1 my resolution)
- 1 Heidenhain EXE 610 for the rotary axis (0,001° resolution)
- 2 Mattke two channel Tach DC motor controller MTRG 25/2D
- 1 Mattke MTRM 061/5 Tach DC motor controller for the spindle motor
- 1 cycloidal transfer 60VAC for the spindle
- 1 cycloidal transformer 2 x 22VAC for the axes motors
- 1 5VDC and 1 12VDC power supply
- 1 All-In-One PC
Only the MESA card is new. All the other other equipment is bought second hand and mostly about 40 years old. But it works !
To be sincere, without help I would not have been able to configure LinuxCNC.on my own. A very kind and knowledgeable member of this forum did this work for me. Thanks a lot to him.
If anybody needs the INI and the HAL files, I would be happy to send a copy.
The following functions are implemented::
- x-, y-, z- and rotary-axis control
- end switches for the 3 linear axes
I have and I need no homing function.
The spindle speed is controlled outside LinuxCNC with an old Beckmann 10-turn potentiometer. I know them from the 80th of the last century, using them in the university labs.
Furthermore I have installed an original old style Waldmann machine light
Best regards
Hartwig

You should be able to use your existing end switches as home switches and limit switches. It is so much easier if set up completely. Just make sure you have a home_offset to move the axis away from the limit switch (even 0.5mm is enough, sometimes less). Otherwise the limit switch will trigger as homing completes.

I saw it the first time I opened it. Couldn't bother myself to fix the sequence on a Sunday afternoon lol
I will fix it for y'all tonight.

Edit:
Done, pushed to github, the ini configuration is better suited for quick testing, you don't even need to home it ([TASK] NO_FORCE_HOMING = 1), but if you do is just one click, and you got infinite limits to load your wildest g-codes.

A couple of us played briefly today on Trixie and we built some debs to share with a few friends.
In the sim, I would like to see 
HOME_SEQUENCE=1 for all joints 
This will enable the home all button to save some time when playing. No need to home each joint.

I'm just having trouble with a corrupt APT system on my Linuxcnc PC and I am getting latency errors on my  office PC so I could not see much but I did briefly see some nice curved graphs in halscope.

I think if it was committed, there would be a stream of testers to find any remaining bugs...
 

With linuxcnc mapping and io mistakes I can't tell cause it's machine dependent. A quick glance didn't pop up anything crazy.

The middle two bullet points usually work or don't. I wouldnt run the estop that way but if it works.....run it.

In this world if it works reliability and it's fast enough just let it rip.


The only thing I would recommend is to do a latency-histogram and see what your latency is. This allows for days running without issues vs hours (or min) (Applications-linuxcnc-latency histogram) If it's below 100 let it ride, below 150 prob fine might tweak a few settings, above that would tune things to make it more reliable..... Otherwise it'll studder/glitch which can cause the UI to drop out.

Let's use know and I can help tune

Thank you. I just saw this after a long illness.

The docs are good, its just so much information.. and it seems like alot of it can conflict with each other and can be easily setup wrong. I would suggest a better LinuxCNC setup wizard.

Consider this, the pncconfig and the stepper config could be updated. Yes it would be massive amount of work. Basic setup is a breeze currently but if it was updated to have more options like probe, tool sensor, camera, ATC ect. Each new section can have additional details or options with images or explanations. Based on the setup the wizard would automatically change the .ini file, hal file, postgui, add folders, add routines, ect, set paths, ect. This way human error is taken out leading to a faster setup or update

Thank you so much for the independent testing, really appreciate it.
On another note, for who is not following the PR posts, Andy Pugh and the other devs decided to merge as soon as they can into master branch, so that it can get more wide testing, and probably be part of the 2.10 release, also I will leave here the same thing I posted in the PR on GitHub:

By the way there is also a PLANNER_TYPE = 2 which I have not documented at all, I intended to remove it, but have not come around to do the cleaning yet, that could be cleaned, or the community could be doing some further testing.

The main practical difference is in how they handle cornering velocities during blends, type 1 is more cautious, while type 2 balances smoothness with speed, in my testing type 1 wins out in most scenarios.

I'm so glad you have had some success!

1) tool probing from the offset page is a completely different probing routine.
IIRC qtdragon didn't originally have a dedicated probe tab. We added it and never removed the original.

2) oh yes weird I'll see if it's something simple...

Is there anything you think we could add to the docs to help the next person to get up to speed quicker?

testing in full stream ... its runs at 2ms cycle with profibus master without significant problems ... hardware beckhoff C6930-0060 with native driver at 3.4ghz 


video - 

That issue had been raised before and had been marked as closed as it was an issue with Linuxcnc itself, not with the image. The readme also addressed the issue. Please check the readme, as well as checking both the open and closed issues on GitHub.
As I'm in the process of looking for a new place to live it may be some time before a new image is built.

Was also mentioned here:
github.com/ozzyrob/linuxcnc-rpi-2.9.7-im...ase-12-december-2025

New image releases will also be announced via github. The latest announcement will have links to the latest release.

Possibly missing a first linein the hal file.
Anyway, you must attach your ini and hal file for any meaningful diagnose to the problem.

I have attached the probe settings screenshot, however I found the issue. The .ini file had [VERSA_TOOLSETTER] Z=-2.49, changed it to 0 and it works! 

Thanks for the help! I have two questions though

1. What is the difference between the tool sensor commands (in the offset section) compared to this auto tool length change? Wouldnt have been the same? 

2. The other screenshot "Zoffset" shows a massive Z offset. Not a concern though the tool able takes the correct number