Added support for tool changes via Gcode

[Festivejelly]

This PR is for adding tool changes via Gcode.

One must first measure their tool offsets from the primary tool (T0).

Process to use this for a grooving tool and boring bar

To do this first zero the axis as normal by selecting T0 then doing a light facing cut, zero Z Then do a light turning cut, measure the diameter and Press B.

Next remove the stock and place a some tube stock. Remove T0 from the quick change tool post and insert a boring bar.

Next slowly jog the boring bar to the face of the tube and note the Z value (this is your Z offset)

Now slowly job the boring bar inside of the tube and take a light cut. Now look at the value of X on the controller and we deduct this value from our original "outside" value. This will tell us how much offset the cutting edge is from the original.

We can now save these values in the code and repeat the process for other tools.

Note this might not be super accurate but I got decent repeatability on a quick change tool post.

I welcome any comments or improvements.

My process for doing this is running it between jobs rather than mid jobs. I simply back the Z out before changing the tool and issuing the command.

[Festivejelly]

Thanks for the comments ill work to adjust.

[Festivejelly]

I will get around to doing this but right now I have some family commitments so might not get to look at it for a week or so.

[kachurovskiy]

Let's put this on pause for now until there's more clarity on how we want to handle tools in lathecode. If you need offsets in GCode, it should be possible today by using to relative coordinates.

[Festivejelly]

Let's put this on pause for now until there's more clarity on how we want to handle tools in lathecode. If you need offsets in GCode, it should be possible today by using to relative coordinates.

In lathe code maybe we could define the offsets at the top of the file. That way it could all be handled in the generated Gcode. But you probably would still want the T command so that it retracts and pauses so that you can manually swap the tool.

The way ive been doing it is manually creating the gcode and I have 1 file for each tool operation. It does work quite well and at the end of each file I do a retract and the beginning of the new file I do a tool change.

But it would be better to have it all in 1 file and have it pause and retract as needed. But yeah one would need to figure out how to build that into lathe code.

[fmw626]

The way ive been doing it is manually creating the gcode and I have 1 file for each tool operation. It does work quite well and at the end of each file I do a retract and the beginning of the new file I do a tool change.

Hi @Festivejelly I would be quite interested to see how your current workflow looks like. Any chance for you to show us?

[Festivejelly]

The way ive been doing it is manually creating the gcode and I have 1 file for each tool operation. It does work quite well and at the end of each file I do a retract and the beginning of the new file I do a tool change.

Hi @Festivejelly I would be quite interested to see how your current workflow looks like. Any chance for you to show us?

So for most things I use lathe code to generate the gcode. Then I use my tool https://festivejelly.github.io/LatheGcodeVisualiser/ and I paste the gcode in there. I then look through it to make sure it all looks okay using the preview. And then I send it via the gcode sender option.

Then if I need to change tools I use the tool change option either in gcode (T0 - T3) or I press whatever tool I want to select in the controller:

For things like boring operations and internal grooves which are not yet supported by lathe code I just write the gcode by hand and visualise it using my tool to make sure it looks right.

On my setup T0 is a parting off tool/outside grooving tool. T1 is a boring bar and T2 is an internal grooving tool.

So first gcode operation I cut the outside profile using T0. Then once the gcode is finished ill select T1 on the controller, and ill send my own gcode.

It does require the code in this PR to work. In order to figure out the offsets its quite easy. T0 becomes your zeroing tool, so all offsets are relative to this tool.

So I zero T0 as normal, take a light facing cut, measure diameter, enter that diameter into the Nano controller, then hit A. I then zero the Z by taking a light facing cut and pressing Z.

Next I move the tool away from the work, I remove T0 and I put in T1. I now move the tool slowly towards the face of the work. put a piece of paper on the face and move the tool towards it slightly until I feel a drag. Then I look at what the number is on the Z readout and I note this down minus the thickness of the paper (usually 0.1mm). So for my boring bar its something like -15.3mm offset from the zero on T0 meaning that its 15.3mm ahead. So I note that number down for the Z.

Next I need to take a turning pass internally so that I can figure out the offset on the X. So I just use the turning operation for this, I take a light pass internally, measure the diameter and I can compare this to the diameter it thinks it is on the X.

So lets say earlier when I did my calibration for T0 after I did my light pass I measured diameter to be 30mm that would be 15mm radius. So when im on the outside of the part it should read -15

But ive had to move the toolhead in to use the boring bar, so I just look at how far I moved it in. For example I might now have a reading of -10 which means I moved in 5mm so the offset on the X for the tool would be Z-15.3 and X5

You can follow the same process for any tool, external or internal just be sure not to reset the zero after removing tool0 because they are all relative to that.

I plan on doing a more visual guide for this soon.

This will only work with a decent quality quick change toolpost. I use a wedge type and the repeatability is good enough for what I need it for.

So once ive calibrated the offsets for all the tools I just put those into my code. Here are mine for example:

struct ToolOffset { float xOffsetDu; float zOffsetDu; };

// Tool offsets in deci-microns (DU). 1mm = 10000 DU. ToolOffset toolOffsets[4] = { {0, 0}, //primary tool always 0,0 {53750, -58000}, //internal grooving tool 5.375mm X, -5.8mm Z {57750, -69000}, //trepanning tool 5.775mm X, -6.9mm Z {0, 0} // not configured yet };

Hope my wall of text makes sense. Any further questions let me know.

[fmw626]

Thank you for taking the time to write this rundown @Festivejelly, i will try to replicate your workflow on my setup and let you know how it goes :)

[Festivejelly]

Im still working on this PR FYI, been a bit inactive due to work and family. On my branch ive added G10 support to specify tool offsets. Just need to do some testing

[kachurovskiy]

@Festivejelly thank you for pushing the envelope here - I welcome all and every development based on NanoEls - but we probably won't be merging this feature into the main code until there's a clear use case for it and measurable interest from users.

Would it be correct to say that this feature isn't strictly required to implement your Web UI? It can be emulated by a couple lines of already supported GCode IIUC.

[Festivejelly]

@kachurovskiy fair enough. I'll merge it on my fork. Its not strictly needed I guess but its not good practice to have too much logic in the web UI as it means people will be dependant on it working properly. Where as if the tool change code is baked into the controller people can use whatever interface they like.