tangential knife along multiple layer height

Hi Vre,

This for info. I hope you can use it.

The linuxcnc scurve planner has now tangential knife output value to hal.
The hal rotational output value could be coupled to a axis motor or device for rotation.

Within the the planner you can also benefit from the clothoid fillets, where the path
tends to be g3 continu, ideal for a drag knife application.

scurve planner is in master?
Have you completed it and is in working state?

Your new TP is a stand alone module just like the original designers of Linuxcnc intended. In fact, it is the first alternative TP module ever made to my knowledge. So really, there is nothing to stop you from doing a pull request to Linuxcnc master because the user would need to deliberately install it to break his machine!

But what grabbed my interest was you mentioning you have a tangential knife output. I am assuming by this means you  are outputting the heading which is tangential to the arc being traversed and the slope of the line if its travelling in a straight line. This is something which is in Mach 3 and something wanted for Linuxcnc. I did some modifications using state-tags that enabled the same feature. But while you are at it, why don't you also publish the radius of the arc being traversed? I have always thought this would be useful for plasma cutting so cut parameters could be modified based on the arc radius for better cut quality.

@Vre,

It's not in master at github linuxcnc. I use Codeberg to host source code.
It is in working state. But as always. It just needs testers, and feedback helps improve the final result.

@Rodw,
The arc radius of G2's, G3's are now also added to display in hal. tpmod.hal_segment_radius
Also the arc radius for the clothoid fillets are displayed in hal, same hal pin, to make it complete.

there is nothing to stop you from doing a pull request to Linuxcnc master
But then the donkey button is not visible anymore.
To be honest, this planner has a value for me to be around +$200.000 dollar in invested time.
On new shipped machine's, this is a game changer.
If i invested my time in building and selling machines, i made much more money. In fact i don't
give a shit about money anymore.

I give it for free to the world, under GPL2 licence.

That's why i hate the Tormach approach, where they keep their dev scurve software closed source.
And that's why Tormach may not use this software. It's stated in the licence. They are the only once's
that may not use my software, or ship my software. Because off their own behaviour to us, the community.

In return for my work i only ask for a tiny donation to the donkey farm in United States above San Fransico.
If users like the software, they can consider a tiny donation. The first donation is made already.

But Rod. You are free to push it to github yourself, as my account does not work any longer.

I will have to try your planner now
Yes, I know how hard you have worked to achieve this planner.

The theory I had was to calculate the cetripetal radius at a given cut speed so that we knew the radius below which the torch must slow down due to physics. Then we could apply some yet to be invented algorithm to the cut parameters. One idea was to stop managing the process control variable voltage to keep height stable, and we would lock the torch height and then alter current as a process control variable to maintain constant torch voltage. In this scenario, the kerf width should stay constant as the arc is negotiated. When you have perfected this planner, try that on your machines

Hi Rodw,

I really hope Clive can use the planner with the plasmac application and even get a better result.

And yes the centripetal radius can be used to calculate cut speeds. Your approach should work ok.
If you need any additional hal pins, don't hesitate to request a feature.

For plasma's true hole technology we could also give a-axis, b-axis values to compensate kerf angle at runtime.
This is simplest solution that can be done by 2 tiny motors attached on z axis torch holder. A compensation range
0-15 degrees should be ok in x,y direction.

From that perspective we could also compensate the tp xyz position output so that
the torch kinematics stay valid, the tcp stay's valid when torch angle is compensated.

This are just idea's.

Some very good ideas too. I had thought about tilting the torch as you suggest. This is simple if you take a line perpendicular to the heading (eg the line from the current position to the centre of the arc) to set torch orientation and another motor to tilt the torch your 10-15 degrees
Some of the underlying true hole technology shared with me is also built into Monokrom GUI written by James Walker (JoCo) who was the only one interested in implementing it. github.com/kcjengr/monokrom
It uses a Gcode filter to remove all holes and replaces it with our "true hole" database driven methodology
I describe the methodology here 

I think the only other pin required would be the heading from the centre of the arc to (or from) the current position.

 

I used Gemini 2.5 Pro to create a python script that adds retracts and C axis moves to a program.It could be turned into a filter program. Try it on the attached test file and see if it works properly.

Before:


After:

vre wrote:

Is there any other cam software for tangential knife except sheetcam ?

 

FreeCAD (?) (wiki.freecad.org/CAM_DressupDragKnife)
CamBam (www.atelier-des-fougeres.fr/Cambam/Aide/Plugins/DragKnife.html)
RhinoCAM (mecsoft.com/OnLineHelp/RhinoCAM%202023/i...s-knife-cutting.html)

All these CAM are dragknife not tangential.
Tangential knife has an extra C axis that is mounted on Z axis to actively rotate the knife.