Gsender Z Height Issue

[Jowilmei]

Not sure what is wrong, I just want to document this issue.

Machine seems to revert to a predetermined Z-height no matter where I zero it to initially. It is also not adhering to my CAM heights (traverse height) As it basically decides to traverse at zero.
Let’s say I move to the top of the Z travel, zero all, then start my job.
The machine travels to about -55-60mm.
Same story when I start at the low travel, it moves up to an unwanted position.
I set the WCS in Fusion360 to match Gsender.

I reset the controller to factory settings.

Please help.

[CrookedWoodTex]

I dropped and broke my crystal ball.

Can you tell us indicate what machine and version of gSender that you are using?

Also, explain how you are setting your bit to Z-zero.

[Jowilmei]

Sorry.

I have the 30x30Longmill MK2. Using Fusion 360,

I set my z-zero with the Autozero touchplate, but have since tested with the Z-zero button on Gsender. Both methods results in the same unwanted movement.

[NeilFerreri]

@Jowilmei

Using Fusion 360

What post processor?
Are you using G28?

[Jowilmei]

I am using the Fusion 360 post processor function.

I am not sure what G28 is exactly. but have the WCS set to G54 on both the post processor and Gsender.

[NeilFerreri]

@Jowilmei

Fusion 360 post processor

You choose a post processor when you generate your gcode. What post processor are you choosing?
When you post process, there is an option for “safe retracts”… What is yours set to?

[Jowilmei]

Changed safe retract to the clearance height set in the toolpath. I have that height set to 10mm above the stock height.
This does stop the z-axis rezeroing behaviour, but it not affect the tool path.

The tool stays at zero when moving to its cutting toolpath.

[Jowilmei]

I also changed the GSENDER safe height to 10 mm with no change to the toolpath.

[Jowilmei]

[NeilFerreri]

So it moves XY before Z?

That GRBL post needs some work. Looks like the same issue here. Use my post processor instead.

How to force Fusion 360 to do clearance Z move before x/y translation

That’s a post processor problem. Feel free to use mine here. If you really want to use the grbl one that’s in the Fusion Library, you can swap these two lines: writeBlock(modalCodes, gMotionModal.format(motionCode.multi), xOutput.format(position.x), yOutput.format(position.y), feed, additionalCodes[0]); and writeBlock(gMotionModal.format(motionCode.single), gOffset, zOutput.format(position.z), hOffset, additionalCodes[1]); so the Z axis move is first. They are lines 1601 & 1602 in the grb…

[Jowilmei]

Wow, thank you for being so helpful. I want to learn more. On who does the issue lie?

Purely Fusion360 or Gsender?

What do recommend I use to learn about G-code.

[NeilFerreri]

@Jowilmei

On who does the issue lie?

Purely Fusion360 or Gsender?

In this case, neither. Whoever wrote the post processor.
My post processor is linked in that other thread. It should take care of the issue.
Gcode is pretty simple, essentially just XYZ motions with a few other commands splattered in.
Post processors take the CAM program’s generated toolpaths and translate them into gcode for your machine. Fusion post processors are written in JavaScript, but none of it is all that well documented.