CNC Lathe Scratch Build

I'm still not quite getting this. CNC systems usually have circular/conical interpolation so you can ask it to move in a circle or helix and the controller directly generates the XYZ moves to do this without going through a g-code step so the huge overhead of g-code interpretation is not required. Is what you are asking for in effect a generic interpolation mode, where for example it could move to follow a suitably defined curve without going through g-code?

Did the brief paper that I linked miss the point completely ?

… Just trying to learn a little from your adventure.

MichaelG.

Michael, that paper is exactly the issue and the guts of that paper is precisely the core of what I would need to implement, Unfortunately, as with most papers, they provide the gravy and very little, if any, meat! However, its not really to complex, especially if I limit the function to basics. We will see...

Interesting paper though - positioning accuracies of 6um, etc...!

Joe

Edited By Joseph Noci 1 on 27/09/2021 20:41:55

Difficult for me to explain - I lack the correct terms and the appropriate math insight!

The Gcode G02 X Y I J allows the mill to generate in interpolated ARC in the XY plane.This will cat an arc in the material at the appropriate position.

If that Gcode is preceded by G17, the ARC is in the XY plane, by G18, the arc will lie in the XZ plane, etc.

Similarly G02 X Z I K generates an interpolated arc on a lathe in XZ plane, but that arc is an XZ move, such as an arc on the end of a shaft in the chuck.

If you use a rotary axis in the mill, and constrain the Y axis (as in a lathe) , the lost Y axis has to be wrapped around the A axis and you would have to use a Gcode along these lines

G02 X A(angle) I J - this is then POLAR interpolated from Y to A to generated that curve. If you machine does not have that interpolater mode it will not work. J is for XY plane

Polar interpolation on the lathe is similar, but 'not quite' - 

For example here is the basic code to mill a 40mmx40mm square on the end of a shaft:

G12.1
G42 G0 X60. Z-5. C0. F.(feedrate)  # this line is the initial; position of X and Z ( and C = Y )
G01 X40.
C20.
X-40.
C-20.
X40.
C0.
G40 X60.
G13.1
G0 Z10. M05

The C axis is not given in angles or arcs - you treat it like a Y axis, cartesian position.

So read that file with Y instead of C, for a milling machine and it is basic XY move from corner to corner.

But the G12.1 Polar mode causes the controller to convert the 'Y' position to a set of cordianted C axis and X moves...

Joe

Edited By Joseph Noci 1 on 27/09/2021 21:42:25

Edited By Joseph Noci 1 on 27/09/2021 21:42:50

**LINK**

https://www.kadirilkimen.com/thepolarbear/

Could this open-source project be useful?

That looks interesting, John.

There's also a 'Polarizing Converter' that may be of some use to Joe here. There is no 'C' axis label available, but if the basic conversion is OK, then it might be a simple Search & Replace in Notepad.

Martin.

The method chosen by the PolarBear designer is to post-convert a standard, non-polar Gcode file into cartesian and angular segments. That is as we discussed in our posts. To expand on the downside - A polar interpolation kinematic would interpret the polat Gcode commands and generate output 'commands' ( step pulses, ie, the smallest resolution increment possible on a given machine) driving the axes along the cut path. To obtain that same resolution ( which you DO need if you look carefully at the hyperbolic path motion for our square in the C axis) in a post-processed Gcode file would mean thousands, maybe 10's of, Gcode lines converting Polar to small coordinated X and Caxis moves. In addition, the surface finish suffers because the feed rate cannot be properly interpolated down to individual Gcode moves, and so impossible to maintain any constant feed rate or material removal rate.

In the standard Caxis/Xaxis G12.1 interpolation, feed rate is normaly inverse time as well, which gives constant cutting edge feed, while the Caxis motion rate can vary hyperbolically

See what Polarbear says..

I had to develop a postprocessor for g-codes:

**LINK**

This postprocessor imitates the polar movements that would be run by a cartesian controller. This works great too. But it is not efficient. It generates twice or more g-codes and it cannot run the machine at efficient feed rates. Even if we calculate the best feed rates, the firmware will treat the movements as cartesian and recalculate the decelerations and accelerations, which would be wrong for polar motions.

Therefore, without special firmware for polar and cross slide motion, the machine often runs at inefficient feed rates.

My brain is so wrapped around this C axis at the moment...head spinning.

Surely this would do it?

Edited By blowlamp on 28/09/2021 12:46:59

Sent a request for the supported Gcode list - lets see!

Joe

Get the GSK980TDc manual here.

Get the GSK980TDc manual here.

Nope, No G12.1, G13.1 nor G112 / G113, so can't do!

And thats the story of my life..

Joe

Are you sure?

This is from the manual I downloaded.

Well....

I clicked on the link you gave and abt half way down is a table of supported G codes, and G12.1 et-al is missing so looked no further. After what you posted I downloaded the whole manual and it is as you say!

I need to dig some more - $3K is a lot of money, but if its not good money after bad, may just be my way out!

Thanks for this info!

Joe

There's a whole range of these CNC lathe controls here.

I notice UK ebay has a GSK980TDc available for a little over £1000 at the moment, but some of the buttons have Chinese characters - still worth a look, I think.

Martin.

Been some progress on the Polar Interpolation. The Polar Interpolation software is working well and tested with a simulator to verify the math. In fact, the math, and the software turns out about 20 lines of code, so very simple.

The big issue is in the integration with Linuxcnc itself - and this is in line with the usual Linuxcnc pains...

Switching from 'trivial-kinematics' (essentially cartesian kinematics, with arc's) to 'Polar-kinematics' (with G12.1 g-code - which we had to create and make Linuxnc believe it exists..) is not simple. Since the last axis position before G12.1 was a 'cartesian' one - with a relationship to the machine coordinate zero, and to the work coordinates zero, with tool offsets, when we enter the polar mode, we have to convert that position to a polar one, with the tool remaining in irs current position - so, forward and reverse kinematics, and right now it does not work because linuxcnc is rather convoluted in the way one has access to parameters related to all the machine and work coordinates.

This project was all about the challenge of the mechanics, never about the software - Boy, was I wrong!

I decided against the Chinese 'GSKxxx' type controls - scares me a little since when I ( and I will..) find some issue that the controller does not do, improper polar modes, or any thing even very small, there is nothing I can do about it...At least with Linuxcnc I can fool myself into the belief that I can make it work, even if it's now good time after bad!

Joe

Edited By Joseph Noci 1 on 05/10/2021 07:23:20

Sloowww progress, but at least it is progress.

The Polar interpolation is working well - I have not machined anything so yet, but with a sheet of aluminium centered on a shaft in the chuck and a sheet of paper glued to it, pen in the tool holder, I am drawing very respectable squares,hexes, etc on the paper.

issues to contend with now are re-homing the C axis when exiting the polar modes, etc, but those are minor and fairly simple.

However, I am frustrated now by what I thought was resolved and simple!

I am having a lot of trouble with tool offsets sometimes violating machine limits. This issue is specific to Linuxcnc, so general tool offset management and definition processes for Fanuc, etc, won't help...

Is there anyone who has a lathe running Linuxcnc who can chip in and help me understand the tool offsets procedure please...!?

As each hurdle is overcome, another looms large...

Polar Kinematics are fully ensconced in The Lathe's Linuxcnc controller and working very well,

I believe all the major Linuxcnc issues are at an end, with only a few minor things to still fiddle with.

My Good Wife has again proved to be a Star - She decided to work fully with the Linuxcnc source-code since we had some show-stopper issues in machining 'Polar' parts - She eventually found a bug in Linuxcnc, and the Developers agreed and fixed it! So we now have a fully working C axis Live Tool Lathe!

Tool offsets are all implemented and working. The fun started when I began to machine test pieces. I did a simple hexagon on the end of a 40mm OD plastic bar, and a U shape across the face of the same sized bar. The U shape is particularly challenging as the milling cutter approached the center of the bar - at that point there are small movements in X with large C axis Rotations.

The first result of the machined U ...

Around the centre the cut lines have a 0.2mm deviation - they are parallel, but offset.

This was due to tool height, 0.2mm below spindle centerline.

This photo shows the 8mm milling cutter cut a slot part way through the bar face, then withdrawn and then the bar rotated 180deg in the C axis and the cutter then brought in again.

The cutter cut 0.2mm low each time, hence the offset seen below.

The ATC was then raised with 0.18mm brass shim - still a tad low - and another U machined.

This shape made sense and showed that the Live Tool X offset ( G54) was in excess by 0.3mm / 2 ( since the Gcode for these modes are always in 'Diameter Mode'. This clearly shows that the left and right ends of the U are almost at the correct heights, since that is related to tool height and not to X position, while near the center, at the bulge, the C axis is almost at 90 deg, ie, the U sides are vertical, and so X offset plays a big role.

This error in X offset ( since all tools are referenced to the master tool in station 1) is due to an error in tool-1 X offset because of poor Homing repeatability and accuracy. I use Hall effect sensors, and extensive tests show no better than 0.2mm spread in detection. So the sensors have to be hugely improved.

Sorry about the crappy red text - it says the bulge is due to the X tool offset error of 0.2mm

I then machined the U again, but this time setting the Live tool offset AFTER Homing, ie, eliminating the Home deviation - this could be done each time the machine is switched on, then home would not matter, but that is a pain...Good Home sensors are imperative.

The left side of the U shape below is about perfect. The right side not so much... Further investigation reveals that it is actually the bottom right of that edge that bulges out - and that is due to not-so-good resolution on my C axis encoder - 4096edges which gives 0.08deg, with a servo deadband of 3 edges which is 0.24deg accuracy at best, with an additional 0.08deg on top of that for position repeatability. So, I need a much better encoder - 8000 edges or so..2000 pulses. The Hex is off course much better, and much easier to achieve good results - the C axis encoder contributes less error since the x deviation versus C angle change is never as disproportionate as when the cutter is near bar centre. The hex is actually very good within 0.02mm in dimensions which in plastic is not bad.

In polar/Live tool mode, every little error has to be fixed, any play, offset, etc is critical, and tool height is King...

Will try do a video of the lathe cutting stuff in Polar with the live tool.

Joe

EDIT _ get rid of grinning smiley's...

Edited By Joseph Noci 1 on 18/11/2021 17:17:26

Still No video of the lathe doing some Live Tool Stuff...

I had more than enough of LinuxCNC , and all things Linux, for a while....So am tackling some of the many bits still to be done on the lathe - Coolant pump and piping, Swarf/Splash guards, etc. Coolant is a bit of an issue on a CNC lathe like mine - The tool changer does not incorporate coolant feed pipes for each tool, like the big CNC machines do. I will have one spout, and that means the coolant is sometimes aimed at the wrong place. The spout can be set up reasonable well for most facing/turning/threading tool tips - they are more or less in the same place when selected, give or take 10mm or so. However, a drill bit, boring bar and the live tool center are not so simple. So the Spout has to be 'fixed', ie, does not travel with the carriage, but aims at the workpiece and must really flood it. I also intend to use a positive displacement coolant pump to have good pressure to blast swarf away...

Coolant will be neat cutting oil - Castrol Ilocut™ 510 MP,  a chorine and heavy-metal free, multi-purpose neat cutting oil. It can also be used as a hydraulic oil confirming to ISO 6743/4 Type HM, so I wonder if using a thin hydraulic oil is also possible?

So while the design concepts for all that brew, I continued with the Splash guards. This encloses the lathe entirely, to be fitted with a perspex front panel for viewing. I cannot get the flexible acrylic matl in Southern Africa, so Perspex it is..

Also have to think a bit about lighting internally - IP66 lights don't exist here...

The Guards so far-

Edited By Joseph Noci 1 on 13/12/2021 20:56:05

Looking very impressive.

Hi Joseph, on the polar kinematics issue, I don't know if you saw MG's post on a "polar drawing machine" a week or so back, but when I saw it I immediately saw the point you were making! As a result I've been idly wondering about using the technique to do laser engraving of a clock dial - it would make for a simpler machine than having 2 linear axes perhaps.

Somewhat related, I see that there is a CamBam plugin to do C-axis mapping of X or Y axes, which I think is mainly of use for doing cylindrical engraving, but as far as I know it can't map X and Y into polar coordinates.

Will your joint changes to LinuxCNC make it into the main thread or just be a fork? Sounds like it could be a good feature.

The lathe is looking good! Did you make any progress with the tool touch-off system? I was just thinking today about how I could integrate my electromagnetic approach more into the lathe structure. At the moment I have to loop the sensor over the workpiece and make connections to the chuck and toolpost for the excitation current, but this is often difficult with small components. I'm wondering how I could build the sensor into the toolpost structure itself.