QTPlasmaC with six axis

Aciera wrote:

Not what is required here.
Well it may not work for your case, so apologies if I'm not being totally on topic but you have not really given much information about what you are actually trying to do other than '6axis complex pipe cutting' which could mean a lot of things.

I thought that might be clear as mud. I cannot describe it better than full 6 axis TCP coordinated moves involving XYZABC to create angled or bevelled cuts that are not uniform along any path but could be varied. Plasma cutting that is not limited to a flat plane but any point in the cartesian space.
Does that make sense?

Aciera wrote:

@ Rodw
Since 'Drag knife' gcode orients the c axis (ie the torch in this case) to the tool path it may work for sheets and probably also for pipe. You could define the bevel angle using the A/B axis and then the C axis would be used to keep the torch oriented to the tool path.

Wouldn't a drag knife be oriented along the tangential heading?
The torch needs to be normal (eg perpendicular) to that.

Apparently this is one thing Mach has it over linuxcnc. It reports the tangential heading.

@marius, sounds like you need a robot holding the torch.

There are two ways of using a tangential knife. One is s drag knife that pivots by itself to trail the movement of the x and y axis. The tip of the blade is situated ever so lightly of centre which will cause it to drag behind. The second way is to use a rotary blade and that is attached to a physical rotary axis. The rotary axis is programed by Gcode to follow a path.
Neither of the above will be useful for a plasma application. The only time one could use that principal is if the bevel is always the same. But then you still have to employ 5a xis kinematics to get proper path following.

A robot arm is more complex as it has only rotary axis. We are busy with just such a project but it is still early days.
Similar moves can be accomplished by the 5/6 axis gantry solution.

phillc54 wrote:

If you have cloned LinuxCNC then you should be able to checkout the branch with:

git checkout phillc54/qtplasmac_6_axes

 

Ok got it eventually. I think there was an issue with the server earlier as I could not clone master. I redid the whole dev again and I manged to switch to your branch. I will build and test now.

Wouldn't a drag knife be oriented along the tangential heading?
The torch needs to be normal (eg perpendicular) to that.

Absolutely, but that is just a 90° offset.

Apparently this is one thing Mach has it over linuxcnc. It reports the tangential heading.

Well maybe, but I'm not totally convinced that is really the ideal solution but of course I don't know how it is actually implemented in Mach. I built a sim config recently that calculates the heading angle in a custom kinematic using the dy and dx values from one cycle to the next. It works but it has it's quirks that make it unusable for any application where the tool/workpiece cost prohibit unforeseeable behavior in case of a glitch. With this approach even minuscule corrections coming from the planner can result in very large changes of the heading angle. In my opinion heading is something that should come from a CAM so it can be simulated before running on a real machine.
But again I don't know how Mach does it so I might not do it justice.




Anyway, mariusl seems to require full 6axis toolpath and the CAM that goes along with it. It will be interesting to see how that works out with the motion planner falling back to one line look ahead.

Phil can you send me your config that you used to test please?

Aciera wrote:

Absolutely, but that is just a 90° offset. I'm not totally convinced that is really the ideal solution but of course I don't know how it is actually implemented in Mach. I built a sim config recently that calculates the heading angle in a custom kinematic using the dy and dx values from one cycle to the next. It works but it has it's quirks that make it unusable for any application where the tool/workpiece cost prohibit unforeseeable behavior in case of a glitch. 

Yes, I tried working with dy, dx too and did not get a result.
By extending the state tags mechanism that returns the state of the trajectory to motion in real time, you have access to the drawing primitives. Given the current x,y position and the arc radius, the heading can be calculated.
Heading was a by product of my work to determine the arc radius in real time that Andy suggested I add to my project. The need for the radius is diminished due to aother developments taking place and its only just recently that I realised that the heading could have other uses on a plasma table. In my sim, it seemed to work reliably.

@rodw
I am not sure how reliable state tags is in all circumstances. Some time ago I recall a user on the forum getting random values from the motion.feed pins. I did some testing then then and found that if only the X and Y axes were in play then the value was correct but as soon as the Z axis was moved in gcode then the values would change. I don't know if similar issues affect other aspects of state tags or not.
This reminds me that I was going to revert the feed value we use in plasmac back to the cut feed parameter. I probably should test it again when I get some time...

Phill, that kind of makes sense. From memory, state tags may be limited to the planes that exist in gcode so not sure what happens when you add a third axes.
linuxcnc.org/docs/html/gcode/g-code.html#gcode:g17-g19.1
I added my own variables to state tags. Just don't trust my maths!
It really is a dogs breakfast the way info is passed from interp coded in C++ back to Motion coded in C