Advanced Search

meister wrote:

or you can let me know which ones you’d like to see included – as long as the FPGA supports them, it’s no problem.
 

I'm sorry I'm not kindly to you, but your very hard work will be useless, if you have important things in secret.
For example you adviced in github md "than copy a config file that is near to your setup", but there are no tangnano1k setups in github, but I see you have some setups for this board , because you show about it on YouTube...
Share your configs, please.

Aciera wrote:

Using the unstable pre release is probably not the easiest entry point for a new user. Unless there is a compelling reason for this  I would strongly suggest to use the stable 2.9.10 instead.
 

Since few months I regullary installled LinuxCNC 2.10 on Debian 13, because I'm looking for the best configurations for my machines.
It was tens of installations, because I preffered new system installation not update, and did not want to clean after tries of installations, as it turned out, unnecessary packages.
Well, never LinuxCNC refused start, or worked unstable.
I dont understand why people  are afraid of new things and prefer old and certainly worse ones...

In this topic we have other problems.
1. Why the author installed LinuxCNC on Zorin (Ubuntu)?
2. What else the author does but doesn't talk about it?

Sorry, but in my opinion we can not help somebody, who don't know Linux, AI helps himself and installed system by few hours instead half hour...

I described the installation of newest LinuxCNC in www.forum.linuxcnc.org/9-installing-linu...ng-of-linxcnc#348132, but I suspect this will not works on other than newest Debian 13. 
Zorin is not Debian, Mint is not Debian, and if somebody will try, let him suffer alone...

Thanks, heaps, for the info. I have a working config for Ethercat on my raspberry pi 5, So I will play around with connecting a tang 9k to the spi on the pi and see how I go. I will post more info if/when i get it working.
Thanks again.
Andrew

Using the unstable pre release is probably not the easiest entry point for a new user. Unless there is a compelling reason for this  I would strongly suggest to use the stable 2.9.10 instead.

'$ git checkout 2.9' and rebuild

Test using one of the included sim configs, like Axis_mm.
The cooltool one you tested fails here also, but with a different error.

I think from memory, in sheetcam, you do a drill operation and that inserts the spotting code. (assuming its in the post processor) Perhaps you can do the same in f360.

please share your Hal and ini files. I think you have added something that's not necessary. 
Can you run an axis sim?

andypugh wrote:

I have a good model of my lathe, but the mill model is rather lacking.
There are a few milling machine models on Thingiverse / Printables etc.

Thanks Andy, The PR is there now github.com/LinuxCNC/linuxcnc/pull/4318

There is little more than a single bug fix in 2.10 so unless that is going to affect you which it probably isn't, just get your Mesa card up and running with the working system you have.

meister wrote:

He's done a really great job with his MTconnect;
it works perfectly, so I integrated it directly into my riocore system as a plugin.
It would be nice if there were a dedicated repository for it.

There is a PR submitted now into LinuxCNC's core. It would be great if you could add your feedback there github.com/LinuxCNC/linuxcnc/pull/4318

 

Fixed 7i80db_16_7i85sx3d.bit and 7i80db_25_7i85sx3d.bit

Thanks for the changes.

"Run time" now works correctly.

"Auto mode switching = True" works perfectly; it could definitely be added to the GUI.

Regarding issue number 4, I've found the problem.

The auto mode check condition in the "external_offset_state_changed" function also needs to be removed. After this change, everything works correctly.

Another issue with the stop button: after pressing stop, the machine stops, but the spindle doesn't turn off. You have to press stop again to turn the spindle off.
The stop button status displays "error process aborted."
This doesn't seem to be related to the recent changes.

Looks like you guys have been busy, this is awesome.

I decided to test out the capabilities of GPT 5.6 Sol by making an entire jerk-limited CNC controller from scratch over the last few weeks. It's mostly done and works, but I'm sure there are still bugs and things I need to finish. I have it working with my mesa 7i96, but haven't connected it all back up to my router yet. It "supports" 6 axes, but I have not even started to worry about the ABC axes yet as I have none on my router. github.com/a-downing/ngc.

The jerk-limited path solver is a small part of it and I ended up separating it out into its own repo here: github.com/a-downing/PathTempo. It basically takes in a series of path pieces represented by a curve length and an array of samples of three derivatives (tangent, curvature, curvature-derivative) along that curve for the solver to use. The output is a sequence of time domain cubic polynomials representing cumulative distance along the path, with each polynomial belonging to one path piece. It has helpers to convert lines, arcs, helical arcs, and b-splines into path pieces with their curvature samples.

It has two modes, zero and optimized. In zero mode the acceleration between each path piece is zero, and in optimized mode it can be non-zero for a more time optimal trajectory. The zero mode is very fast (about 0.15% of trajectory time), and optimized mode has taken at most about 1.5% of the time of the trajectories that I've tested so far.

The trajectory planner supplies the real-time backend with timed axis-space polynomial execution spans, quintic for normal continuous motion and cubic for exact stop motion and stop-tails. Each motion chunk includes a proven stop-tail so the backend can stop safely if it reaches the chunk’s branch point without a valid continuation. Homing and probing is done in the backend. Feed hold is done in the backend and only enforces the feed-hold specific tangential jerk limit, and the tangential/normal path acceleration limit. I have not implemented feed override yet, this can be done entirely in the backend if you only allow lowering the feed rate, but for raising it you need to implement it in the planner, and the latency can be up to one planning horizon plus whatever motion the backend has buffered. To have an acceptably low latency the planner would have to only publish a certain amount of motion (measured in time) to the backend. This is doable, but it increases the chance that the backend has to take a stop-tail if something unexpectedly makes planning take longer.

G64 path smoothing is what needs the most work. The time-optimality is more sensitive to the path geometry than anything else by a large margin. A path that to the eye looks extremely smooth can have large curvature derivatives that harshly limit the maximum velocity through them to meet the jerk limit. What I'm basically doing is for lines and arcs above a certain size I join them with a curvature continuous cubic b-spline (not taking full advantage of the G64 P value yet). For spans of arcs/lines that are "small", control points of a quintic b-spline are dropped on their center points and the ends are joined to the enclosing "large" lines/arcs with curvature continuity. If you only do this it will look very smooth, but have large curvature derivatives that severely limit the max velocity. You have you run the spline through a smoothing algorithm that balances minimizing curvature and curvature derivative, while staying within the G64 P value from the original entities. It's already doing this, but I think it could be improved. It should also probably be removing control points in most cases, which it is not.

The one thing I've had no problem with yet is performance. The planner is able to produce work for the backend much, much faster than the backend can consume it. I think it is mostly because GPT 5.6 was able to come up with a very efficient jerk limiting solver, and that the work is pipelined with multiple threads. The first thread evaluates the gcode and produces path geometry and publishes it to a lock free queue, this work only has to be done once, but it takes the most time. Mostly because of the spline smoothing. The trajectory planner reads from this queue and plans a window that includes a stop-tail. Because of the stop-tail some of the same geometry is involved in the next planning window. The planner then publishes the axis space time domain polynomials to another lock free queue in the real-time backend.

I'm not sure if you guys will find any of this useful for the jerk-limiting in LinuxCNC, but I figured I'd drop this here.

FWIW the "pierce only" feature is the answer for me in my workflow.  This along with selecting the holes to be center pierced into a separate Fusion 2D cut profile with the path parameters set to center offset, 90 deg lead in, lead in = 1/2 the circle diameter worked perfectly.  Since size doesn't matter (pun intended) I just used 6mm circles with 3mm lead in.  No gcode editing or other steps needed.

Thank you Tommy for prompting me to RTFM.   I was a dolt and didn't even realize that the "Normal Cut" button in the GUI toggles "Pierce Only"!  I was stuck on trying to use the M3 $2 S1 code but this works just fine.

I did also create a material.cfg entry for "Hole Spotting" and put my center piercing settings in there; 0.120" pierce height, 20A (as low as my machine will go) and 0.1s Pierce Delay (as short as it will go).  I'll add more as needed for thicker materials.

Cheers!
 

QtPlasmaC updates - Master (v2.10):

• fix double "qtvcp" ghost windows on repeated switches to the conversational tab (June 2026 - Forgot to post this...oops)
• reload file with G10 rotation in MDI for bounds checking