Fusion 360 to Carbide postprocessor - unexpected homing

Software Carbide Create
1

I’m using Fusion 360 (v 2.0.6670) and generating gcode via the Carbide 3D post processor (11/2/2019 version). Executing using UGS on my Shapeoko.

The code includes multiple G28 return-to-home commands. This means the bit starts at the WCS origin, moves to the MCS origin, moves back to the stock to start milling, finishes milling, and then moves back to the MCS origin. This is a lot of unnecessary movement. It also has the spinning bit traversing the rest of the wasteboard, possibly intersecting with a clamp.

Is there a way to turn off the homing commands without manually deleting them from the code? Or is there a post processor anyone can recommend that doesn’t include the homing cycles?

Here is some of the generated code with my comments:

%
(1001)
(T1 D=12.7 CR=0 - ZMIN=-1 - flat end mill)
G90 absolute distance mode
G17 select the X_Y plane
G21 unit selection - mm
G28 G91 Z0 return to home; relative distance mode; raise z axis 0 mm?
G90 absolute distance mode

(Face1)
T1 M6 This also gives an error in UGS
S17000 M3
G54 work offset (sets WCS origin?)
G0 X30.255 Y-17.21 rapid move to WCS origin offset
Z15
Z5
G1 Z0.27 F1000
G18 G3 X28.985 Z-1 I-1.27 K0
…
G18 G2 X23.27 Z0.27 I0 K1.27

G0 Z15 move to Z-axis WCS origin + 15mm
G17 select the X_Y plane
G28 G91 Z0 return to home; relative distance mode;
raise z axis 0mm Unnecessary command?

G90 absolute distance mode
G28 G91 X0 Y0 return to home; relative distance mode;
X axis + 0mm, Y axis + 0mm - unnecessary?
G90 absolute distance mode
M30
%

2

Maybe a workaround, use a word processor with search and replace to remove them then re-save as a text file.

3

G28 is not a “home” command (3d printing background?). Your G28 position is a user defined location that can be changed any time with a G28.1 command.

Move the Z axis only to the G28 position after moving the Z axis 0mm from where it currently is.

Move the X and Y axis only to the G28 position after moving the X and Y axis 0mm from where they currently are.

The zero incremental movement is necessary to specify the axis / axes that will move. G28, without a specified axis motion, will move all three axes simultaneously to the G28 location.

I don’t usually use automatic references to G28, but does the post processor have the option to disable calls to G28? I use a custom one based on generic grbl.

jpeg
jpeg621×545 36.3 KB

2 Likes
4

Thanks for the feedback! Yes, I had misunderstood the G28 command. I tried resetting G28.1 to the MCS origin, and now the unmodified code from the Carbide post processor works correctly. That is, I’m no longer getting unexpected “return to home” surprises. The cutter moves from the WCS origin, runs the cutting path, and then moves up on the Z-axis. No return to MCS origin. So I’m happy.

As an aside, the Carbide post processor does not have the option of eliminating the G28 safe retracts, although that is a moot point for now.

Thanks again!

5

Rats! I was premature in saying that problem was solved. It isn’t.

I moved my spindle to the home position (-1, -1, -1) and then executed G28.1. For testing, I then move the spindle to some random X, Y Z position out in my workspace. If I execute this code:

G90
G17
G21
G28 G91 Z0

I would expect the spindle to move in the Z axis to -1, and not move the X or Y position. Instead, what I get is that the spindle moves back to (-1, -1, -1) with all axes moving simultaneously. This makes no sense to me.

What the heck am I missing? It seems I have to either reset G28.1 for every job, hand-edit every gcode file that comes out of the Fusion 360 Carbide post processor, or else start a whole new learning curve to understand how to modify my own post processor.

Any thoughts would be appreciated.

6

Does this help?

More listed at: https://wiki.shapeoko.com/index.php/Commercial_Software

7

I personally use G53 commands to move to a repeatable spot on my table. Right or wrong, it works for me.

1 Like
8

That’s what should happen.

How are you sending the commands?

Here’s a link to my post processor:

1 Like
9

Thanks again for all the feedback.

Will - I did try the bCNC post processor. The nc file generated still used the G28 G91 Z0 code which is the source of my problem, But having another post to try is always useful.

James - I agree the G53 works. But I’m still hoping to understand why the code generated by most of the post processors I’ve tried - the G28 sequence – doesn’t work as expected.

Neil - thanks for the link to your post processor. I’ve tried it, and it is the only one so far that gives me the correct results. So that’s great.

As for how I’m entering the commands - I’ve executed several nc files generated by different post processors, and I’ve manually entered the commands at the console on the UGS. In all cases, G28 G91 Z0 results in all three axes moving simultaneously back to the machine home position, which is the position I originally set using G28.1. That is not right.

In fact, G28 G91 X0 Y0 does the exact same move; all three axes move simultaneously. So does
G28 alone. It’s as if only the G28 command is being interpreted; the axes codes are ignored.

Then I thought maybe there was a problem with the code sender - UGS, so I tried the bCNC sender, and got the same results.

By now I’ve generated 6 different nc files, all using different post processors, and run them using two different code senders, and also entered the commands manually, and in every case I get movement on all three axes when I should only get movement on the Z axis. (That is, for those post processors that generate code that use the G28 command. The ones that use G53 - like Neil’s - work fine).

At this point I assume I have a correct understanding of what G28 G91 Z0 is supposed to do, the post processor(s) generate correct code, and the gcode senders work correctly. So I can only conclude there is something wrong in the grbl setup on my Shapeoko.

Well, at least I have Neil’s post processor to generate useable code.

1 Like
10

I’m thinking you want to update to v1.1…I’m guessing you’re in v0.9?

EDIT: Yup…found this.
Looks like that behavior was updated to follow LinuxCNC after v0.9.

3 Likes
11

Yep, that’s the answer. :smiley: I’m in grbl 0.9. I’ll do the upgrade to 1.1. I am absolutely amazed that you could find this info, and almost instantly. How in the world did you find it? My searches turned up nothing.

Very, very much appreciate your help. Thank you.

3 Likes