Semiautomatic tool change, dynamic Tool Offset & Variables

Discussion about the arduino based g-code interpreter, grbl
Post Reply
rodcar125
Posts: 67
Joined: Fri Feb 06, 2015 5:00 pm

Semiautomatic tool change, dynamic Tool Offset & Variables

Post by rodcar125 » Wed Apr 08, 2015 6:14 am

Trying to implement this on my gcode for every tool change:

Code: Select all

first part of program
.
.
(Tool Change...)			
G90 G00 Z70                     //arbitrary Z safety height since I don’t have my S3 yet ):
X0 Y0 M5                        //go to a reachable position for manual tool change (home maybe?)
M0                              //pause program when tool change position is reached

**Actual tool change happens here, after done hit cycle start** (might be a good idea to keep power to motors on to avoid axis movement while changing the tool)

X10 Y400                        //arbitrary/permanent touch plate location
Z35                             //so probing wont take that long (careful with long tools?)
G49                             //delete previous tool offset
G38.2 Z0 F25.4                  //probe cycle to Z0 with 1 in/min feed rate
G43.1 Z[#5063 - TOUCHPLATE_THICKNESS]  //apply dynamic tool offset
                                       //variable #5063 is the standard storage location for the z coordinate
                                       //when the probe switch triggers
G00 Z35                                //return tool to safety Z height
M3			                            //turn on spindle
G4 P3			                         //give time in seconds for spindle get to desired speed
(End of tool change…)
.
.		
program continues
What it is known:
- grbl wont allow movement on M0 commands for safety issues as chamnit have previously stated on github if i remember correctly which i think is best
- M6 commands are not supported
- tool tables are not supported due to table managment resources needed
- variables/arithmetic is not supported by grbl in the gcode file

Case:
When the G43.2 command is completed without an error, the tool is touching the touchplate, motion stops and the Z coordinate is known. With this in mind, if there could be a variable TOUCHPLATE_THICKNESS or alike in the grbl settings for the user to set, then grbl could compute the offset internally whenever the G38.2/G38.3 is called and output/return/storage the value to a known variable, lets say COMPUTED_OFFSET.

If this could be done, then the code above would change to:

Code: Select all

.
.
G38.2 Z0 F25.4                  //probe cycle to Z0 with 1 in/min feed rate
G43.1 Z COMPUTED_OFFSET         //apply dynamic tool offset (SOME KIND OF POINTER WOULD NEED TO BE PLACED IN ORDER TO LET THE PARSER KNOW TO RETRIEVE THE VALUE STORED IN COMPUTED_OFFSET)
.
.
Pros:
with this, arithmetic within the gcode is not needed and it would only need those two variables (only one in the gcode with a predefined name)
tool table would not be needed since the dynamic tool offset is only set for the tool being used and recalculated with each tool change
this would eliminate the need for a specific GUI for tool offsetting
it could also eliminate the tedious task of slicing gcode files into subfiles for every tool change
could eliminate using some other method for tool lenght setting such as bit stop collars
would be repeatable, accurate and reliable
and you could virtually have any tool changes as you like without worring about how far the tool is in the shank when a tool change is done
only one variable handling would be needed from the parser (COM{UTED_OFFSET)

cons:
it would require the user to keep an eye on the machine for when the machine stops for a tool chnge (which he might already be )
if tool change takes too long, motors might get too warm? (if power to motors is on all the time to keep position)
dont know about how difficut / time consuming would be to adapt grbl code (or even if its possible)

Question:
How viable/hard would this solution be to implement on grbl? does it sound good or im just loosing my mind over this?

any comments are pretty much appreciated
Rod

chamnit
Posts: 376
Joined: Tue Aug 12, 2014 2:16 pm
Location: Albuquerque NM, USA
Contact:

Re: Semiautomatic tool change, dynamic Tool Offset & Variabl

Post by chamnit » Wed Apr 08, 2015 8:03 pm

Your first tool change workflow is pretty much what I had in mind for GUIs to implement. Grbl can't track everything like where your touch off plate is and the speed to approach it for every machine and setup, or if your using a touch-off plate at all. There are too many ways to do this same thing. In general, the GUI should be injecting these explicit tool change commands with all of the data managed by the GUI or by hand. Grbl should only receive the total tool offset. It's up to you and the GUI to determine what that is. AFAIK, there isn't an open-source Grbl GUI that does this sort of thing.

rodcar125
Posts: 67
Joined: Fri Feb 06, 2015 5:00 pm

Re: Semiautomatic tool change, dynamic Tool Offset & Variabl

Post by rodcar125 » Thu Apr 09, 2015 5:24 pm

Thanks for the response chamnit, I guess your right, The GUIs should inject those explicit commands to grbl along with variables management.
Well, ill just have to wait for someone to implement it since I do not know how to program GUIs ):
Ill start digging on that though.

Saludos

jarretl
Posts: 135
Joined: Mon Feb 24, 2014 2:50 pm
Location: Edmonton, AB

Re: Semiautomatic tool change, dynamic Tool Offset & Variabl

Post by jarretl » Fri Apr 10, 2015 4:26 am

Hey Rod,
Chilipeppr should be able to handle this (http://chilipeppr.com/grbl)

Basically, even though grbl doesn't recognize M6 commands, you can configure chilipeppr to pause gcode execution whenever an M6 is called which will allow you to perform your tool change.
Then you would use a macro to run the touch probe before resuming your gcode execution by unpausing from the gcode widget.

I've included a sample touch probe macro below, you could change the top three variables (offset, probespeed, and probedepth) to suit your needs and paste this directly into the macro area. Here is a screenshot of what you would need to do in the interface to make this work: http://i.imgur.com/06GR46h.png?1

Code: Select all

//Send probe command and listen for response
//On response, set tool offset to 'offset' distance specified below
var grblTouchPlate = {
	offset: 3.75,  		//the touch plate height offset
	probespeed: 100,	//the probe speed mm/min or inch/min depends on your grbl units setting
	probedepth: -10,	//the distance to probe downwards into the Z axis - inch or mm depending on your unit settings
	init: function(){
		// now subscribe to the probe
		chilipeppr.subscribe("/com-chilipeppr-interface-cnccontroller/proberesponse", this, this.probeResponse,1);
		macro.sendSerial("G38.2 Z" + this.probedepth + " F" + this.probespeed + "\n");
	},
	probeResponse: function(position) {
		//ensure probe completed successfully or exit without setting tool offset
		//This could be improved with G38.3 (grbl 0.9i) to simply try probing again to a deeper Z value.
		if(position === "alarm" || position.status === "0"){
			macro.status("failure");
			return false;
		}

		macro.status("probe responded with Z position: " + position.z);
		macro.status("setting G43.1 tool offset to: " + (position.z - this.offset).toString());

		macro.sendSerial("G43.1 Z" + (position.z - this.offset).toString());
		
		//unsubscribe now that we have our probe response
		chilipeppr.unsubscribe("/com-chilipeppr-interface-cnccontroller/proberesponse", this.probeResponse);
		return false;
	}
};

//start the probe.
grblTouchPlate.init();
Cheers,
-J.
Shapeoko 2 #4043; DW660

Post Reply