Developments on my Home built 5C CNC Lathe - new spindle and progress on the ATC

As it was with my C_axis adventures - Andy having dug me out of that one - the first and major hurdle is knowing what you don't know...How to get the bit of C coded component to interface with HAL, LinuxCNC and the world...How to get the Spindle part of LCNC_Lathe to be the live spindle and not the main (headstock) spindle, etc...

I am still rather lost, but there have been a few knowledgeable moments, so I am going to keep at it till I have something around which I can ask useful questions..
Maybe in a week or so..
Thanks!

I have done so, also looked at various other folk's implementions - EMCO Compact-5, the Boxford types, etc..I have an 'implementation' of the ATC ( not the live spindle yet) which I will load tomorrow and see what it does..
Thanks

Thanks Andy!

Well, the ATC is working very well!  My Good Wife, a very good C/Python/etc programmer climbed in and helped me- we have a nice component for the ATC ( excluding the live spindle - that's next) , with some added buttons and failure indicators on the AXIS page and the whole thing works nicely.  I will post details in due course, source for the component, HAL/INI, the XML file for the added imagery, etc, as well as some photo's and a video of it working.
The Live spindle is now the issue..
Before I started on it's component I wanted to understand better how the G_code file would command the spindle and the coordinated C_axis motion.
This spindle is axial to the main spindle, so would only cut on the face of the workpiece normally.
Let's take a simple job - a 20mm diameter shaft in the chuck, and machining a hexagon head on the end of the shaft, say 5mm long.The Z motion is easy to comprehend - move till milling cutter is at stock start, and move in 5mm towards the headstock to cut the 5mm long hex.To cut the flats requires that the C axis and X axis move in a coordinated manner cutting the flat.
So I am trying to understand what G/M codes would perform this motion in Linuxcnc, and am not having much luck.

Trying a different approach I searched ( many many hours..) for CAM packages that were 'affordable'  and able to do such a hex head machining process. I found 2 packages, e-CamV4 from a fellow in italy and KipwareT from Kentech in the USA.
e-Cam about 300 Euro and KipwareT around $500.00 - both do C axis and Live spindle.
e_Cam allows basic cross section sketching of side and face of the job and does turn and end-face milling, such as the HEX end on a shaft. e_Cam is free to use on weekends.
KipwareT is much more Pro, and is more a conversational CAM SW, and seems very powerful.
Discussing with Kentech if they could provide a G-Code file of my hex head shaft, they requested I fill in a G-Code Live tool setting sheet which is used by the SW to append the appropriate G_codes for your machine.

Except, I do not know what G_Codes to use!

Anyway, they did a sample G_code file for me. I also did one with e_Cam.The two files could not be more different!  I tried to compare the G_Codes to LinxCNC's Gcode list, etc, and am lost.

I have attached the two G-code sample files ...

I would like top appeal to some LinuxCNC G_code boffins to please give me some guidance on this. I am not sure how my current C_axis implementation is going to work with this in coordinated C/X manner.

At a bit of a loss! 

 

EDIT:
After digging more, I suspect I need to use G12.1 and G13.1 ( Polar Interpolation modes) and this does not exist on LinuxCNC I believe.
In which case I may be wasting my time with a C axis and live tooling on this lathe..

So I am trying to understand what G/M codes would perform this motion in Linuxcnc, and am not having much luck.

I think, in order to use a 'regular' XYZ Gcode on a XZC machine you would need to create your own kinematic. 

I made a sim-config using a rough custom kinematic: forum.linuxcnc.org/38-general-linuxcnc-q...tics?start=10#212389

If you can get the required math done in a relatively affordable CAM then I would think that to be the better solution. The sample code you attached that uses XZC moves looks promising. 

So LinuxCNC has no polar interpolation for lathes. a Great pity. When I started this project I was really in the dark - did not know what I did not know, on every level! Did not realise that LCNC lacked this to start, and did not know that I needed this!

One only ends up discovering these things when you get to the stage where you start digging deep to understand...
The file I attached - the one with XZC moves - is also rather useless I fear.. It commands G18 mode, then has lots of arc moves with I/J which cannot work in XZ plane - J is only applicable in XY plane. Blindly changing all J to K does not work - results in 'Radius to end of arc differs from radius to start' errors galore as well.
Using G17 instead of G18 is inappropriate in a lathe...
I any case, I don't see how arcs could implement the likeness of a polar computation. the CAm would really need to break up the polar moves into (small) incremental C angle and X cordinated moves - No CAM I tried can do that.
All other CAM's I have evaluated - CAMWORKS, MASTERCAM, SPRUTECAM, EXCAM, etc, expect an industry style cnc machine - FANUC full monty, HAAS, Mori, Mazaak, Doosan, etc, and so expect full polar interpolation functions (D12.1/D13.1, etc) and don't do the math for a simpleton machine like mine..

Appears there is no useful solution here, not even a complex one. Have to take a breath and contemplate what next..

The last time I was programmed with polar coordinates was in school 20 years ago.  What do you need them for?  The CAD programs output everything? Seems only way is cam…
 

 Appears there is no useful solution here, not even a complex one. Have to take a breath and contemplate what next..

I've been following your progress with interest.

I, too, did not realize that polar interpolation was unavailable in LCNC.  I've been delving in to LCNC on my mill (retrofit about finished) as a training exercise for when my XZC live-tool lathe control dies.

Before throwing in the towel, you might approach some commercial CAM post processor vendors/authors about it.  It may be possible to have the post processor compute & output XZC moves without the use of G12.1.  Or at least post the question on the various CAM user forums and see if anyone else has a similar situation.

I use F360 for my lathe (Fanuc 21TB by Emco), and the post processor does not output G12.1/G13.1 moves.  It outputs straight X/Z/C moves, and there's just IK G18 moves (no J).

I think polar interpolation was created to make it easier to hand-program complicated moves on fairly simple part features.  CAM doesn't (or shouldn't) need the machine to interpolate anything; just to go where it's told.

-Ralph