Manual tool change + tool lengh touch off

del

Is no one really using manual tool change with probe?
I looked at both setups and they all share the same problem and I could use some creative ideas to get around it and the tool change would then perhaps work fine in all scenarios.

Now it will break a programmed cycle if using multiple fixtures with anything else than G54. I can get around it by shifting G54 before moving to the next part. But if I run with G55 instead it will return to G54 after the tool change. I know I will want to have one tool do its work on all parts and then be changed for other tool before next operation. Like this it should work with no problem.

1)The basic problem is that G38.x does not give result in G53 system. As I said before, now I'm using G59.3 (which is set to 0) before probing. One way not to do it will be G53 G0 to probe position, then perform ultra-short probing G91 G38.3 Z.00001 (this is an example from other topic. Does G38 even care about G91?), store the result, then do real probing and calculate delta from the two results.

2) Another way is to get current coordinate system number and return to it after the tool change, or zero it in the process and then revert the values. I found a way to get the coordinate system number 0-9 from variable but there is no gcode to use that number again to select it. It would have to be an ugly if-elseif-elseif or case() thing.

3) Maybe even better would be to use the variable number of cs*20 + 5223 to get current Z offset and use that to get real value after probing? Less ugly? Does not require changing the coordinate system, is there anything else to consider?

Important thing is also to make it fail proof. The toolchange operation now has a timeout, and it would be very nice to return everything to a previous state if the change fails. Changing any offsets seems dangerous... There is another thread that got linked here: forum.linuxcnc.org/38-general-linuxcnc-q...-tool-change-problem
It is mentioned there that Fusion360 post processor assumes Z=0 for the tool change or Z max. I will look into that as a friend will be using it.

Other than "that" the toolchange is fine. It was mentioned that routine should get back to a position where it was called from - what do You people think/believe? Of this two examples none does this. What is left is an assumed "safe" height so if next move is to XY it can be safe but does not have to - It will be, if first op after TC is a move to safe Z and then to XY in part area. This does not consider having anything on the machine table that may stick up a little bit more than Zsafe. Any safety advices?

Thanks. I hope someone can read this and have a response.

I think that the sample config is meant to be only that, a sample.
Specific implementations are likely to have rather different requirements.

It shouldn't matter which coordinate system you are operating in, a G10 command should set the tool length data correctly taking in to account the coordinate system offsets.

Heh Marian - i basically have the same question. Did you ever find a solution to your question?

I have a toolsetter here for simple cnc machine yet it's manual changing the tool each time. What i would like is that it homes. I push the green button, then it should move to preset coordinates and measure tool length. Then move to preset coordinates where i have clamped the workpiece. After some time it should go back to home - and then ask for a new tool - and the proces above repeat itself.

But any other solution that improves the current situation here also are much appreciated

Note that even if i would build an autotoolchanger - it might be not repeatable load the tool at exact same spot. Just it manages to get in ok and that's all. Of course no good for quickly milling something - but heh - it's a simple machine that is not so accurate anyway. So after each toolchange again measuring the tool height in automatic manner seems pretty interesting to me.

Weird the feature is not there in linuxcnc. Is the commercial toolpath generating software this good that linuxcnc doesn't need to know all this?

If so which one for some sort of decent price can do that?

(as i'm currently struggling with pycam which doesn't even seem to know how to chamfer a workpiece with a chamfering cutter - instead it'll take an hour with a ball nose cutter).

Kind Regards,
Vincent

diep wrote: What i would like is that it homes. I push the green button, then it should move to preset coordinates and measure tool length. Then move to preset coordinates where i have clamped the workpiece. After some time it should go back to home - and then ask for a new tool - and the proces above repeat itself.
...
Weird the feature is not there in linuxcnc.

It sort-of is.

G-code was defined a long time ago and largely on the assumption that machines with interchangeable tooling had repeatable tool length. I don't think anyone back then imagined using the not-yet-invented ER collet directly in the spindle nose.
If you have R8 / CAT / ISO / BT / HSK etc etc tooling then you store the tool length in the tool table and every time you put a tool in it is in exactly the same position. (You can actually do this with an end-stop in your collet spindle, by the way)

With that sort of system M6 does a tool change and G43 applies an offset based on the tool table.

What LinuxCNC allows you to do is re-define what happens when T or M6 are found in the G-code.

Start LinuxCNC and look in the sample configs. Start the sim/axis/remap/manual-toolchange-with-tool-length-switch/ home it and try doing a tool change (M6 n MDI for example). You will see that the behaviour is pretty much exactly what you are asking for, except that the move to the tool change position followed by a tool length measurment happens when the tool is changed, not after a fixed length of time (which seems to be what you are asking for)

Much appreciated you explain that i can redefine gcode commands - that's very helpful!

Yeah it's good to know from how far linuxcnc comes if i read the struggle some had years ago needing to modify all the HAL and similar files.

I did find that sim directory in

/usr/share/doc/linuxcnc/examples/sample-configs/sim/axis/remap/manual-toolchange-with-tool-length-switch/

In that directory listed is a .glade .hal .ini and .ui file - how do i load those?

Can i double click on one of them?

And how do i take care i have a button in the linuxcnc-GUI underneath the 'home all' i like also a button 'set tool'.

I did find a good youtube explaining which g-code i'd need for that.
But no clue where to put this code so the linux-CNC gui knows how to deal with it.

with the values proposed except height of toolsetter

O <touch-to-zero> sub
G91 G21
G38.4 Z-20 F100
G0 Z1
G38.4 Z-10 F10
G10 L20 P1 Z-40.5 // my setter here seems to switch at 40.5mm or 41mm
G90 G21
G0 Z10
O <touch-to-zero> endsub

Where to put all this. Have a link to how to program linuxcnc-GUI?

My plan which might be good or not is to put a few steel bars on the bed at fixed positions at known locations. If i put there known distances (parallels) in between then i know exactly at which coordinates i clamp workpieces to the bed. So that's in my case most
parallels are 6mm thickness so clamp position is 6mm away from those 2 steel bars on the bed.
If i mill multiple sides of an object that might be very useful.

(everything in millimeters)
The homing goex to (X,Y) ---> (3,3)
Now the toolsetter also is at a known location i intend to put it at (X,Y) --> (50,0)

I can change tools then at (3,3)

Above the toolsetter is not so much space.
Z-coordinate where toolsetter loses signal is at -40.5mm or -41mm (must still precisely figure that one out - you bet i will.
With the bed at 0.00mm.

Idea i had what to make:

a) a button in the linux-cnc GUI

subroutine SetToolAndHome
- home all axis
- move to (50,0) <== toolsetter location
- carry out SUBROUTINE touch-to-zero
- move to (3,3)

b) a button in the linux-cnc GUI
if( current location is NOT (3,3) then SHOW ERRORMESSAGE to first home
move from (3,3) to Clamp Position

Then run the code PyCam generated here
for which i'll have to figure out what sort of supercomputer i have to buy to speed it up a tad producing gcode otherwise it'll take years to test some stuff there.