If you want to draw a line on a pipe, it does not matter if you rotate the pipe or rotate the pen.

Here is your homework. I've already done this. Google coping calculator and review the maths and graphics for a notch in a pipe to be butt joined to another tube. print it on light card and cut the outline out. Wrap it around your tube, trace it with a felt pen and cut that notch out with an angle grinder. 90 deg join is easy to cut. 45 deg is a bit harder (as its deeper) with the angle grinder but it can be done fairly easilly. The maths creates the desired outline and won't care how you cut it! Options 1 & 2 are identical.

If you are cutting a length of RHS, it still has a standard profile defined in an engineering standard so you can still follow the surface to cut it with similar maths.

I think Its predominately a CAM problem but when you want to angle the torch, some kinematics might help. Not sure if it will help but 2.10 now includes some tangential headings which may assist. I think the full 6 axes may let you cut I beams

I'll get the EMI power line filter tomorrow and hopefully have it all back up and running over the weekend. Will also go over all the grounding wires to make sure nothing has come off (what i'm thinking as this has slowly crept in).

Thanks for all your support and ideas to get me back on track.

@spumco,
what's your configuration? is it not XZ? and what is your eta on being up and running?

@susan-parker
how close are you to being up and running?

 
Hey everyone,

I am retrofitting a CNC Plasma Pipe Cutting with 6-axis. XYZABC. I am wondering what Kinematics module to use. I have encountered two types of pipe cutting machines.

1. The pipe is placed in a chuck and rotates the a-axis
2. Plasma torch head navigates around the pipe.

These to me are totally different calculations and I would assume would be handled by the CAM software? Would i just use genhexkins and the rest is just mapping each axis and joint?

What I am trying to understand is who is in control of the machine path, the CAM software or the linuxcnc kins module. 
I want to cut a line in the pipe at point x1=0 a1= 300deg to x2=100 a2=300deg, who calculates that trajectory?
 

I am - for an EMCO Compact-5 CNC Lathe, with 6-position Auto Tool Changer (3 + 3 tools).
I am still setting up the hardware, getting close though.
The 4-quadrant variable speed thyristor DC motor controller is built and tested. I am now working on mounting the box and fitting for the ATC controller. Then it's just the limit, home, and emergency stop switches.
My setup is based around using Probe Basic Lathe... especially being able to make parts using the conversational mode - which for me is a game-changer!

Please follow these steps for tuning:
1. Set C00.04=0 to switch to manual mode.
2. Confirm the inertia ratio (using the drive's automatic inertia identification function).
3. Fine-tune the speed loop (C01.01, C01.02):
Gradually increase C01.01 until slight noise or vibration occurs, then back it off by 15–20%;
Gradually decrease C01.02 to eliminate steady-state speed error, but do not set it too low, or low-speed creeping/oscillation may occur.
4. Fine-tune the position loop (C01.00):
Gradually increase the value to shorten positioning time and reduce tracking error; if overshoot occurs, back it off by 10–15%.
5. Acceleration feedforward + velocity feedforward.
6. Adjust friction compensation:
Measure the friction torque in both the forward and reverse directions separately, then input the values.
However, at the 0.001mm (1μm) level, mechanical factors often limit precision more than electrical parameters—such as leadscrew backlash, thermal expansion, structural rigidity, and uneven guideway friction. If the steady-state accuracy remains stuck at a certain value after manual fine-tuning, it is likely a mechanical bottleneck that cannot be resolved by gain adjustments.

PCW wrote:

Does sound like an EMI issue.

Have you tried debouncing the limit switch signals?
 ( This can be done with the hal debounce component or with some
hardware, a hal parameter )

This seems the most likely problem and a simple solution. I did go through your Hal and ini files shared earlier and could not see anything obvious wrong.

I probably wouldn't add a max limit signal if I was sharing a single home/limit switch but I don't think that will make any difference. Are you using proximity sensors or switches? normally open or closed? if prox sensors, are they pnp or npn?

See if you can install a wifi dongle on your garage pc and get it on your network. Then you should be able to create a network share of your home folder you can reach from your main PC to configure and share Gcode files

Does sound like an EMI issue.

Have you tried debouncing the limit switch signals?
 ( This can be done with the hal debounce component or with some
hardware, a hal parameter )