Initial move

[rogierweekers]

I would like an option to let the machine first go to the safe height before the initial horizontal move command.

[Anonymous]

@rogierweekers 

Yes, every time!! Safety first always!! G28 G91 Z0

[HughesTooling]

What post are you using? Most of the postprocessors have the option to use either G28 or G53 to make a move to the machine home (Z axis) before any XY move.

For example, Mach3 below.

Mark

[thingswelike]

Yes, this has changed since the free edition rapids limitation.
Because it's not a G0, the PP doesn't know to separate out the Z-retract from the X/Y movements.
If you are starting at anywhere below the top height, this can ruin your machine!
Even if you are starting at the top height, it can mark your workpiece and clash into clamps, etc. Very dangerous.
I can live without full rapid movement, but I can't live with dangerous g-code.

I am now having to manually edit every piece of g-code that Fusion 360 outputs.

[HughesTooling]

---

@thingswelike wrote:

Yes, this has changed since the free edition rapids limitation.
Because it's not a G0, the PP doesn't know to separate out the Z-retract from the X/Y movements.

---

@seth.madore  Is there a workaround for this?

Thanks Mark

[Anonymous]

@HughesTooling 

@rogierweekers 

@thingswelike 

Anyone tried using the Manual NC Pass through option?

That could be Hard coded through at the start of the program.

Or possibly really Hard code it in the PP by putting a "writeBlock" line in where the G0 G28 G91 Z0 are written in like this:-

writeBlock("G0", "G28", "G91", "Z0");

If you can upload a copy of the PP you are using we can see where the line would be best placed.

This is the code output you will get using the above hard coding line in your PP:-

G0 G28 G91 Z0

Couple of options there for you, because the G0 is hard coded into the code then your CNC will do a Rapid move for you.

[thingswelike]

I've found a beta PP for Marlin that is doing a good job of fixing it, but I don't know what method it's using.
It seems that a few PP are being updated to fix this problem:
https://github.com/flyfisher604/mpcnc_post_processor/tree/v1.beta5

[seth.madore]

It was my understanding that this issue was caught very early in the release cycle and was fixed promptly. I suppose the first question would be: Is the OP (and anyone else reading this) at the latest update? We should be at 2.0.9719 as of Feb 20th, 2021

The second question for the OP is: What post are you using and can you share the Fusion file?

File > Export > Save to local folder, return to thread and attach the .f3d file in your reply

[thingswelike]

I can't speak for the OP, but I'm on the latest 2.0.9719 I guess it's difficult to nail as we're al using different PP, but until yesterday I was using the MPCNC Marlin PP: https://github.com/martindb/mpcnc_posts_processor

Edit: BTW - I don't do a homing routine as I dont use endstops. I just manually move the machine to the starting position and do a G92.

[rogierweekers · Accepted solution]

Thanks for all the replies. It did put me in the right direction.

I am using "othermill" (my machine is a retrofit deckel Fp3, made the controls with sigmatek plc and servo drives) In the postprocessor i put the following code 

writeBlock("G0","Z50","(modified by R.Weekers 21-2-2021. Safe height before any move)")

Put it in the function "onSection" after the variable declaration, on line before the first "if" statement.

Now the machine moves to Z50 before anything else.

The nc code looks like this now:

(1001)
(MACHINE)
( VENDOR WEEKERS)
( MODEL SIGMATEK)
( DESCRIPTION GENERIC 3-AXIS)
(T1 D=5. CR=0. TAPER=118DEG - ZMIN=-26.936 - DRILL)
G0 G90 G94 G17
G21
G0 Z50 (modified by R.Weekers 21-2-2021. Safe height before any move)