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?

Hi,

Could really use some pointers:

Short version, PCNC 1100-3 PC with PCIe mesa card died, new PC can't fit PCIe mesa card, only card that seems compatible is the Mesa 7i92T (in my case the 7i92TM, yah wrong DB 25 gender, but a gender bender fixed that.)  Issue is when  restore from my tormach supplied PP 2.0.0 thumb drive, that version does not support the T version of mesa cards, but to update to the latest version I need to get to the PP GIU (Or is there 1) a way to upgrade without PP GIU or 2) create a PP full install thumb drive that has a newer version of PP?)  I tried some .ini and .bashrc edits I found to force it into simulation mode, but they are not working.  Granted I had to guess at where the files were located and they did not match the lite description of where to edit so I may have been doing it wrong.  the files I edited with in the ~ directory the .bashrc where i added the PATHPILOT_SIM_MODE=1 (pretty sure this one is right, made it the first line) and the other edits were in the ~/tmc/configs folder in files that were for the 1100-3 with Ethernet - but these I am suspecting have changes or I really did not get what the ask was on what I had to change as none of the lines matched the instructions, so I took my best guess as to what I had to do, regardless it does not let the GIU start.   Any help is greatly appreciated.  PS:  I don't believe the PC is the issue and the card is setup to use 10.10.10.10 and is communicating, there are no other devices on the Ethernet, its a direct link.  thanks, Happy new year

Thanks for these instructions, have made them but PP 2.0.0 does not boot without giving the "No ethernet link detected. check cabling between controller and machine." My original PC for my PCNC 1100-3 died, it used the PCIe mesa card, have switched to a small form factor Intel based PC and imaged the drive with my install/upgrade thumb drive but when I got it Tormach was on PP 2.0.0. With the new Ethernet based MESA 7i92T card I need to update PP before it can work with the newer card, but I can't get it to the PP GUI to do the update. Any ideas how to force it past the above error, note plugging in the card to the Ethernet port (direct) changes the behavior to display a indication that the card FW has been updated then reboots, this keeps happening with no sign of the PP UI. Not sure I am in the right files/folders for the above changes the files I tried modifying are in ~/tmc/configs/ with my selected mill type. the .bashrc file is in ~ directory.

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 line in the hal file.
Anyway, you must attach your ini and hal file for any meaningful diagnose to the problem.

I've been really curious about EtherCAT and decided to take a deep dive and a bit of risk in ordering a Lichuan CL57E-2A. It's a 2 axis, closed-loop stepper driver: en.xlichuan.com/product-xq/200.html

It took a little while looking through the forum, but once I found the information in this thread , particularly from Robbbbbb (thank you!), I got the drive into an OP state and 1 axis working in LinuxCNC fairly easily. So it was with a lot of expectation that I added the configuration for the 2nd axis, but then got nowhere for days.

Has anyone had success with a drive that has 2 axes?

I run `ethercat pdos` and have created the config .xml file attached. As I said, the first axis works, but the second doesn't get set up correctly, and it isn't controllable from LinuxCNC. Using the show HAL configuration tool, I can see the statusword in LCEC HAL pin shows `0x0000` for the second axis. Reading the value via `ethercat upload -p 0 0x6841 0 -t uint16`, I can see that it's not `0x0000`. So I'm thinking something is wrong with my config file or with the lece driver? Is it normal to have two PDOs in one sync manager?

Many thanks,
David.

 

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 

I guess the answer is here: www.forum.linuxcnc.org/29-forum-announce...nuxcnc-2-9-8-release