Advanced Search

 

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

Yes and no.
It's programmatically possible (lathe views gets closer) but not built in.
What version of linuxcnc do you use?

Here I modded to show a more lathe like perspective:
 

Anyway, I solved it with 7i80db_16_7i85sx2d.bit and replacing stepgen00 with stepgen04, now everything works. I'll leave it like this, as I'll switch the 7i97t to analog soon. Thanks!

dlv wrote:

tuxcnc I'll check out dxf2gcode.  I can export a DXF and post process that.  You're not wrong, Fusion is a beast.  But I'm really quite comfortable on the design side and for the most part I like working with it.  That said since I'm learning the CAM side I am definitely open to trying some alternatives especially if they're open source.

 

I'm not against Fusion if the user paid for commercial version.
I'm against the "free" versions (student, hobby, etc.), because someday thats may become won't start without any warning.
However Fusion is large program with thousands functions, so the good question is it worth learn this for simply projects...
I suggested Librecad plus dxf2gcode not because this is Fusion replacement (is not), but because it is very simple and enought for simple projects.
In Librecad you easy can place small circle at the center of big circle, and in dxf2gcode yo can learn the edition of postprocesor  in one hour, because it is plain text human readable.
For example this is fragment of my laser postprocessor:My laser has no Z axis, so no lines for Z moves, but the feed of Z move is simply translated to laser power (F -> S).
I don't know how is in Fusion (I'm not curious about it), but I think this is more complex. In some CAM you can nothing without programming knowlege...

 

OK, see if there is something useful here
www.google.com/search?q=linuxcnc+Hole+Sp...ox-b-lm&hs=BQhV&sa=X

Thanks. I added the message, which displayed, so that is the .ngc being loaded. 
I had just run a facing cut which had a taper. Ran it after adding that msg, and had no taper. I will need to see what the error correlates with.

Ahh that's a pin file error, I'll fix that today or tomorrow.

Thanks Rod.  Fusion has cut profiles.  The approach would be similar to the layers you mention I think.  Select the holes to be spotted in one cut profile and the rest of the part sans the small holes in another.  Perhaps a bit more "one click" in Sheetcam but it's really no trouble in Fusion.  Then from the two profiles I post two different NC files so I can change my torch amps between spotting and cutting (I have to do that manually, no fancy Hypertherm for me!).

I will look into writing a gcode filter take small holes and replace with the spotting commands I have in my test code.  That's the approach I've been thinking of anyway.  Was wondering if anyone had already done that.  If there are examples out there of gcode filters anyone can point me at I'd appreciate it.  I've got decent C and Python skills.

Tommy I looked at the feature I think you're referring to and from what I read QtPlasmaC will take a gcode command to only run the pierce operations it finds in the file and no cut ops.  I guess I'd use the cut profile approach above with just the holes in it and set the lead in to put the torch in the hole center for the pierce.  Like 2mm holes with a 1mm 90deg lead in.  Then use this: So yeah that would be ok if I wanted to actually pierce the hole centers.  I like the "center punch" dimples I'm getting with the M3 command test above but this certainly would be a solution to try and I will.  Might work better on thicker steel.  So far I'm just testing on aluminum sheet.

tuxcnc I'll check out dxf2gcode.  I can export a DXF and post process that.  You're not wrong, Fusion is a beast.  But I'm really quite comfortable on the design side and for the most part I like working with it.  That said since I'm learning the CAM side I am definitely open to trying some alternatives especially if they're open source.

Thanks guys!

Good Day CnC's

I am a "TOTAL" new bee to Linux and to LinuxCnC trying to get the new Ver. 10 to run with the help of AI and maybe 5-6 hours installing on my  Zorin 18.1 Linux computer.
I managed to get it installed only to get an terminating error on opening the program it says to create a report file which i did but can not find the report and don't know how to send it to someone if i did find it. so I seem to need some help if some one can provide some guidance
here is a cut and paste of the error. it will not be hooked to any machine at this time. Just would like to get the program to run for right now

Tks if anyone would like to tackle this. if not I'll understand.

5280 (ken)


Print file information:
RUN_IN_PLACE=yes
LINUXCNC_DIR=
LINUXCNC_BIN_DIR=/home/ken/linuxcnc-dev/bin
LINUXCNC_TCL_DIR=/home/ken/linuxcnc-dev/tcl
LINUXCNC_SCRIPT_DIR=
LINUXCNC_RTLIB_DIR=/home/ken/linuxcnc-dev/rtlib
LINUXCNC_CONFIG_DIR=
LINUXCNC_LANG_DIR=/home/ken/linuxcnc-dev/src/objects
INIVAR=inivar
HALCMD=halcmd 
LINUXCNC_EMCSH=/usr/bin/wish8.6
LINUXCNC - 2.10.0~pre1
Machine configuration directory is '/home/ken/linuxcnc-dev/configs/by_machine/cooltool'
Machine configuration file is 'Basic540_3axes.ini'
INIFILE=/home/ken/linuxcnc-dev/configs/by_machine/cooltool/Basic540_3axes.ini
VERSION=1.1
PARAMETER_FILE=stepper.var
TPMOD=
HOMEMOD=
TASK=milltask
HALUI=
HALBRIDGE=
DISPLAY=axis
COORDINATES=X Y Z
KINEMATICS=trivkins
Starting LinuxCNC...
Starting LinuxCNC server program: linuxcncsvr
Can't execute server program linuxcncsvr
Shutting down and cleaning up LinuxCNC...
Removing HAL_LIB, RTAPI, and Real Time OS modules
Removing NML shared memory segments

Debug file information:
Stopping realtime threads
Unloading hal components
rtapi_app: exit received while not running

I don't see anything in 'facing.ngc' that could cause a simultaneous move in X and Z.

Could you put a debug message inside of your 'facing.ngc' and run that macro again. Just to be sure that that is the actual file being executed (You should see a info message popup in the gmoccap gui).

Something like adding '(MSG, Executing facing.ngc)' to the start of the sub:

Hi Andy,
Sorry for the slow response. I dropped the ball on this as I was doing wood working .

This is the facing.ngc file I am using. I have not modified it at all. I just noticed I have both a "lathemacro.ini" and a "lathemacros.ini" (plural) in my machine directory. Could that be the issue?
Cheers,
Mark