Chilipeppr, Fusion360, and Sending Reposition after Tool Change

So I output my GCODE using fusion360 with the grbl post processor. I use chilipeppr to run my gcode. After a tool change you send a rapid so that you go back to the last position. When this occurs the Z axis changes at a slope while the X and Y change. If the X and Y are far enough away it gives the Z enough time to lower far enough to collide! Is there any way to change this behavior? Is this chilipeppr or fusion360’s post processor?

I was thinking I could manually edit the gcode to insert a position change to just the x and y so that you send that command first and then the next command it processes is the XY and Z coordinates. I would rather this just happen automagically though.

I think this previous post can answer your questions.

1 Like

Yep, that’s exactly what it is. It’s heading for your existing G28 position. I had two nasty crashes that way!

I have now set my G28.1 (G28 home) to a position 20mm in on both the X and Y, and down 10mm from the homing top of the Z. Since I did that, no trouble at all!

My G28 is always my home position. It returns there just fine as of now. It raises the Z axis to max then juts over in the X and Y for a tool change. Its the returning to the last coordinate once I am done with the tool change that gets me. It goes in a downward slope on the Z while they X and Y move . This means that if the X and Y distance is long enough the Z will have enough time to drop to a position that is supposed to be inside a pocket. However, its not inside the pocket yet and crashes into the side of the piece while trying to enter the pocket.

This doesn’t even cut the part because the spindle hasn’t even turned back on yet. If I am not mistaken you are at a location to take a cut and then a tool change comes in. So you G28 G91 Z0 out of there and change the tool. Then you need to send that last coordinate back to the machine so it returns to where it was before the tool change. Its this motion that causes my collision in its current form.

I just went and checked and it looks like the return to last position code it wants to run is a G0 Rapid move

Here is a screenshot from one of Johns youtube videos.

Now that is very interesting! Mine raises to my safety height (.600) before it starts the run back to home, then returns to that coordinate at safety height, and plunges again to reach the cutting area.

Hmmmm I am going to have to look more into this tomorrow. I would like to cut it to the correct tool change it occured on and see exactly what re-position it is trying to do. Because if it is indeed a rapid it is exhibiting the correct behavior. I need to manually cut the program into a smaller file. It is pretty large. Unfortunately this happened at about an hour in.

@DanBrown Where are you setting this safety height? Is it the retract height for each operation in fusion360?

This is what that operation looks like as far as heights go in fusion360

EDIT: Yep! Just checked and it wants to do a rapid back to the previous position after a tool change. This seems like a chilipeppr thing though does it not? My gcode doesn’t have a G0 move to last position after a tool change? It is strange that you don’t exhibit the same behavior. Do you hit that reposition button after changing the tool or do you just unpause the program?

MORE EDITS:
Here is the shortened GCODE:

%
(1001)
(T3  D=1.587 CR=0.794 - ZMIN=-6.668 - ball end mill)
(T4  D=3.175 CR=0 - ZMIN=-19.05 - flat end mill)
(T6  D=6.35 CR=0 - ZMIN=-19.05 - flat end mill)
(T7  D=3.175 CR=0 TAPER=90deg - ZMIN=-13.875 - spot drill)
G90 G94
G17
G21
G28 G91 Z0
G90

(Face1)
M9
T6 M6
S14000 M3
G54
M9
G0 X308.925 Y-0.051
Z15.24
Z5.08
G1 Z-1.969 F1016
G1 Y113.652
G19 G3 Y114.287 Z-18.415 K0.635
G0 Z15.24
G17
M5
G28 G91 Z0
G90

(2D Pocket5)
M9
T4 M6
S14000 M3
M9
G0 X26.681 Y99.37
Z15.24
Z-7.62
G1 Z-9.843 F1016
X26.679 Y99.366 Z-9.891 F338.7
G0 Z5.08
Z15.24
M9
G28 G91 Z0
G28 X0 Y0
M30
%

And these are the two reposition it does:
Send Reposition "G0 X0 Y0 Z0"
Send Reposition "G0 X308.925 Y114.287 Z15.24"

EDIT EDIT EDIT:
Confirmed by John that as I suspected this is standard behavior because of the rapid. After talking to some machinist friends it seems common to actually just know that this will cause a collision. Seems everyone has their own method of how they get into position.

I have noticed something else with chilipeppr. The Send Re-position command seems to do more harm than good? I just cut through a part because I sent re-position first and then unpaused after the tool change. The next gcode did an XY rapid and cut through the part. I have now been just unpausing after a tool change which seems to be executing a rapid to an XY and then a separate rapid to a specific Z. This is the desired behavior I was looking for. I wonder why it says “Make sure to issue the following gcode to get back to the position just prior to your tool change” and when this needs to be used?

Man, that is weird! I have run very few two-tool jobs, which might explain why mine have worked properly to this point… Could just be that I’ve gotten dumb lucky! I almost always break my job into multiple files, with a single file for each tool, and just run them concurrently.

Interesting to see, you’d expect it to at least make an effort to clear the surface!

Yeah it really is strange. I do 6-10 tool jobs all the time and have never ran into this issue. Its just that this job ends one operation on the outside right profile and then starts a cut in the middle after the tool change. This was done to avoid changing back into the 1/4" bit to do the final profile and normally I don’t do that so I am always inside the part.