Mach3 Post Am I doing something wrong?

[richcournoyer]

I was taught that you should never edit the posted output, except for an emergency's, but I cannot understand why the Mach3 post processor does a rapid XY movement before raising the Z. (ALWAYS).  

So what am I doing wrong?

Is air a button I should be pushing or an item I should be checking off prior to  posting?

Example:

M5
M9
T1 M6
S8000 M3
G54
M9
G0 X0.7829 Y-0.9994   <----- RAPID  X,Y Movement

G43 Z0.6 H1 <----- THEN raise those Z AXIS

What I think the output should be: (edited by hand)

M5
M9
T1 M6
S8000 M3
G54
M9
G0 Z0.6  <----- RAISE those Z AXIS
X0.7829 Y-0.9994  <----- THEN - RAPID  X,Y Movement
G43 Z0.6 H1  ( redundant Z move which I don't care about)

Reference information: the machine I am using is a Shapeoko3, with a GRBL controller (VER 0.9)

FYI: I also tried the Carbide3D post processor and get the same result (XY rapid before Z axis lift)

[AchimN]

There should be something into your program like this:

G90 G94 G91.1 G40 G49 G17
G21
G28 G91 Z0.
G90

(2D-FACE)
T1 M6
...
G0 X80. Y-24.375
G43 Z16. H1

G28 G91 Z0 should do a full retract along the Z-axis, so your tool is at the very upper end of your machines Z-axis.

That is why the post is moving XY first and then Z.

Of course you need to set this home position into your control.

You can do a google search for "mach3 homing".

[richcournoyer]

Sorry, I didn't include the top header

(T1 D=0.25 CR=0. - ZMIN=-0.75 - FLAT END MILL)
G90 G94 G91.1 G40 G49 G17
G20
G28 G91 Z0.
G90

The machine IS homed, but there is NO retract, just a rapid XY, as I have stated.

[HughesTooling]

How are you homing the machine, a lot of these small machines don't have limit\home switches so the machine home (G53) is not set properly. G53, X0Y0Z0 would normally be set at the maximums of travel for each axis.

Mark

Edit just to clarify, the line G28 G91 Z0 will move the Z axis to the machine home (fully retracted).

[HughesTooling]

Here's a link to some info on G28, it's for LinuxCNC but it should be pretty much the same for Mach3.

http://linuxcnc.org/docs/2.6/html/gcode/gcode.html#sec:G28-G28_1

And some info on how to use offsets.

http://wiki.linuxcnc.org/cgi-bin/wiki.pl?CoordinateSystems

Mark

[richcournoyer]

Thanks Mark,

Somehow my reply did not get posted so here it is again.

By machine does have the homing and limit switch option.

This is how I home my machine:  I entered $H at the MDI command line.  The machine will travel to the back right corner until it touches all three limit switches (XYZ) and setting the machine's 000.

This is how I set my part's home position into the machine memory (of course, after I've actually located the position of the Part)  I can do the following command: G10L20P1X0Y0Z0.  (P1 = G54, P2 =G55, ETC. I will use the appropriate work offset depending upon which set up I have on the table)

Once the above is accomplished, I load the program and hit cycle start.  And here is where the problem starts, because it does it first does a rapid XY move.

I hope this information can assist you in determining the problem.

Richard

[HughesTooling]

Do you have any info on supported G codes, does it support G28. Another option can you test using G53 G00 Z0.0 to see if that returns the Z to it's home. You might want to test with G53 G01 Z0.0 F100.0 to give you a chance to hit the stop, that assuming you are working in mm.

Mark

[richcournoyer]

As you were writing this note I was doing exactly that, researching how G28 is supported by GRBL.  The last line on this note says it all:

(from the Shapeoko forum)

You set the G28 position by moving the machine to the position you wish to set and issuing G28.1. G30 is set the same way, but with G30.1. These commands do not take any values, and in v0.9 and possibly v0.8c of Grbl, passing a value will cause the machine to move.

Once they are set, you can issue the G28 or G30 command and the machine will move all three axis, at rapid speed, to the predefined position.

Note: These commands will not raise the Z axis before moving the X and Y so use caution.  <-----------------------*********

Which is exactly what I am seeing her on all my Fusion 360 programs, and why I was asking how I can get a Z (Small positive number, e.g. Feed or clearance height) added to my future programs before the XY rapid move.  

I know this is not difficult to manually, when the NC editor pops up when I am posting my programs. (but it's just not good practice).

I think what needs to be done is that I ( or somebody, hint) needed to modify the Mach3 post to do the Z move, before the XY rapid and call it a Shapeoko Post (Also Need to remove the Canned Cycles since they are not supported by GRBL).  

Note The GRBL post processor is a good work around for drilling without using a Canned Cycle, but not for milling, thats another story for another time)

[HughesTooling]

Have you tried the G53 G00 Z0.0 as that is a lot better way of doing it, just adding a Z50. hard coded is not a good idea as sooner or later you'll run into the limits and the program will error out.

Also there is a GRBL post included with Fusion and it has all the canned cycles removed, have you tried that one, was there a problem with it? It uses G28 for Z retracts but would be easy to change to G53.

Mark

[richcournoyer]

I'll try the G53 in a couple of days (Long weekend vacation) as far as the GRBL post nobody has been able to get it to work for milling. Error: 'bad arc format, (and the Shapeoko Forum recommends to use the Mach 3 PP.

[HughesTooling]

I've think the reason the GRBL post was failing was because it uses incremental arc centres but it was not setting the control to use them with a G91.1 at the start. Can you try the attached file. If you're using Fusion don't save it to the generic post folder, save to cloud or personal post folder. See this post for info on using the cloud.

Mark

[richcournoyer]

I snuck out into my shop very early to do some testing on your ideas and the results are as follows:

G53: (G00, G01) both work in sending Z home

Posts:  

OLD GRBL: Still getting Bad Arc Format No I/K

NEW GRBL (Adds a G91.1 into the header) Bad Arc Format No I/K 

[HughesTooling]

Ok I found another difference, the GRBL post used modal IJK moves and the Mach3 forced output of IJK on all arcs. I updated the post and changed it to use G53. At the start of the program it should move Z to the machine home and at the end it will move Z home then XY home. 

Test the post carefully and I'd better add this 

The accompanying advice and or non-standard post processor is provided as-is and without warranty of any kind, and usage is at the user’s own risk.

Although if the post works it should be made the standard post as the standard one doesn't work

Mark

[richcournoyer]

Good news and bad news.

The program posted wonderfully (no I/K Arc errors, and it's 1/10 the size of the mach3 post!!! (Ref 15k vs 153k). The program ran great, but G53 is ignored (sort of, let me explain). Before we load the program into the machine's memory, we enter this command:
G10L20P1X0Y0Z0

I think the G53 inside of the program is using this NEW Z0, which is at the part's Z0 surface.
Now at the program's end, the machine returns to the part's X0Y0Z0

I am not a Post Processor writer, but can't we just have the G0 Z(feed plane) placed BEFORE the X,Y move? It sounds like an easy fix, OR….See below.

The Shapeoko comes with a 2.5D CAM system called CarbideCreate. I looked at several posted programs I ran and noticed this:

G21
G90
G0X0.000Y0.000Z10.000 <- - - - - - - - This is how they lift the Z.
(TOOL/MILL,3.1750,0,1.0000,0.0)
M6 T102
M3 S15000
G0X-57.438Y-5.023

Is this something that you could implement?

Lastly, I recommend that we rename the Post to Shapeoko, rather than overwrite the GRBL post in case there are others (non Shapeoko) users who like it as is.

[HughesTooling]

I found a few screen grabs of the GRBL control and they all show the machine and work coordinates with the same numbers, that seems totally wrong I don't think you would ever end up in that situation. Seems like they don't know how machine coordinates and G53\G28 work in the rest of the CNC world. I'll have a look at removing all the G53\G28 code from the post as it could get dangerous if they implement it properly.

Here's an example screen grab I found, don't think I'd ever be in a situation where both coordinate system would be identical like this.

Are you sure there's no way to set G54 and leave G53 set to the machine home? What happens if you use a G54 before running the command G10L20P1X0Y0Z0, just wonder if you need G54 active.

Mark

[richcournoyer]

Are you sure there's no way to set G54 and leave G53 set to the machine home? Not that I know of.

The work order system (WCS) stay stored in non-volatile memory, until cleared or reset, so typing G54 comment G55, G56, etc. Will move the machine to its last known location in memory.

Ref: The only way to sent the machine back to X0Y0Z0 is to type $H (MDI line)

Hope this helps.

[HughesTooling]

I'm trying to figure out the best way to allow tool changes safely without using G28\G53.

I've got this at the moment.

G0 Z15.
(2D Contour2)
M5
G0 Z20. (Raise Z to 20 before tool change)
T4 M6
G0 Z20. (Move to Z20. after tool change)
S2555 M3
G54
M8
G0 X-10.034 Y-13.798
Z6.5

I think you will need a M00 to pause the program on both lines with the Z20 move. You need a Z20. move each side of the tool change because if you change from a long tool to a short tool the tool could plunge into the job\table.

So to allow tool changes where they might have a big difference in length the sequence will be

1. Move to Z20 with the current tool, pause.

2. Remove tool then hit start, this will load the next tool offset.

3. Move to Z20 with the next tool called and pause at new height.

4. Manually load next tool.

5. Hit start, run to next tool change

Mark

[richcournoyer]

Hold Everything!!! We don't do tool changes.

One tool, one program.

Next tool, rapid back to the part's home (WCS), and load/run the next program. That should simplify things. Sorry, I didn't tell you this earlier.

Why? Two part story

1. We can't do tool offset's in GRBL.  So what about setting tool's to the same length?  See #2

2. Long story that has to do with a persistent disconnect problem that Carbide3D hasn't solved yet. When we power down the spindle something happens with the pixies and it causes a software (Carbide Motion) to disconnect from the controller board.  Some owners see it 100%, I see it about 10% o the time 

[HughesTooling]

The worry is what if someone tries, if I don't put the code something like above you could crash the tool. Is there a tool library on the control, do you always set all the tools to tool one. I could put something in the post so it would error out if you try and use a tool that's not tool one.

Mark

[richcournoyer]

 No there is no tool library, and we've the community Teach people on the forum how to do a tool change, by making a separate program for each tool.