Mach 3 Y-axis zero shifting during job

[Anonymous]

Hey,

I'm pretty new to both Fusion 360 and CNC routing and milling. I have a pair of setups in CAM for a set of boxes I'm making (One for the sides, one for the floors). In both cases the Y-axis zero shifted mid-job, resulting in operations being performed out of position. I've attached a photo of the workpiece for the floors which shows this nicely. The operation at position 1 should have been performed at position 2. The G-code for that is line 2495 in the attached floors.tap

 

I'm using Fusion 360 on a Mac running macOS 10.12.2, and Mach 3 R2.61 on a Windows XP box, running a BZT PFE 1000-PX router.

What's especially weird is that the diagnostic display in Mach 3 shows everything in its correct place. (I've attached a screenshot of that)

There had been problems with the G-code generated by Fusion before for our Mach 3, and those had been solved by disabling useG28 and useM6 in the Mach3 post processor setup (mach3mill.cps), so the code I generated had those disabled.

After the problems with the first job (the walls), I talked to a few people in the shop and they were worried about G17, so I removed that by hand from the floors.tap file.

At this point my working assumption is that there's something that Fusion 360 is outputting that isn't supported by our version of Mach 3, but the more I look at the G-code (which I really don't understand that well yet) the less certain I am.

Has anyone in the community seen something similar? Should I be chasing this down with the Mach 3 folks instead?

Thanks,

Matt

[HughesTooling]

A couple of thoughts.

1. At the end of the job if you go back to your datum is it correct? If it's wrong I guess you're losing or gaining steps.

2. Removing G17 is not a good idea and mach does support G17,18 and 19. If there are any vertical arc in the program mach will not be switched back to the XY plane for horizontal arcs(G17).

Are you using R or IJ for your arcs? I seem to remember mach can go a bit haywire with IJK arcs in big files.

Mark

[HughesTooling]

Just looked at your code and back plotted using NC Corrector and you should not remove the G17s see below.

Here's an example of a lead out with G17 removed.

And here's how it should look.

Mark

[HughesTooling · Accepted solution]

---

@matt95E45 wrote:

Hey,

 The operation at position 1 should have been performed at position 2. The G-code for that is line 2495 in the attached floors.tap

---

There's nothing special in the code at that point, just a rapid G00 so I think your accelerations or speeds are too high for your steppers and they're stalling.

Mark

[Anonymous]

Hey, thanks for taking a look.

Unfortunately the Y-Axis shift was enough that the machine was probably going to crash into its endstops before it did another signficant rapid, so I had to hit stop and didn't get to see if it would recover.

Your point about G17 is noted, I won't remove it in future (I've attached the code Fusion 360 generated before I removed the G17's for comparison).

The only arcs in there are lead-ins and lead-outs, and they're using R.

[Anonymous]

> There's nothing special in the code at that point, just a rapid G00 so I think your accelerations or speeds are too high for your steppers and they're stalling.

That sounds entirely plausible. I'll recheck the rapid rate and lower it some and try again.

I'll let you know how that goes in a couple of hours...

Thanks!

[daniel_lyall]

your acceleration have it between 10 and 20 of your velocity.

And cut your velocity in half or at lest 2/3 of what it is now. If it come's good that is what the problem is, This is a common as mud problem and useing R is better than I and J.

[Anonymous]

After trying the job again without running the spindle and keeping the Z axis zeroed well off the bed, the problem recurred, in a different part of the job, but still a Y-axis problem.

It looks like it's probably a simple matter of cleaning the Y-axis gear and re-greasing: it's definitely nothing to do with the G-code, and probably nothing to do with the speed Mach 3 is using for rapids (the machine did a lot of identical rapids without problem before seizing on a Y rapid).

Thanks again for looking into the G-code so thoroughly, it was super helpful.

Matt

[Anonymous]

---

@daniel_lyall wrote:

your acceleration have it between 10 and 20 of your velocity.

---

 I'm not sure I understand what you mean here - that my acceleration is set to between 10 & 20 (%?) of my velocity and that this is bad, or that I should set my acceleration to between 10 and 20 of my velocity.

Unfortunately I don't have ready access to the Mach 3 settings being used, so I don't know what the setup there is.

---

@daniel_lyall wrote:

And cut your velocity in half or at lest 2/3 of what it is now. If it come's good that is what the problem is, This is a common as mud problem and useing R is better than I and J.

---

In terms of the feed rate during operations 1,800mm/min is well within the machine's rated max of 8,000mm/min, and there haven't been any problems during operations where the speed is controlled by feed rate in G-code, only during rapid movements. It does sound like reducing the Y-axis rapid speed in Mach 3 would be a good idea.

Thanks,

Matt

[daniel_lyall]

It turns out some machines have a problem with use R instead of i and j.

Your Y may just need a clean.

yes 10% to 20%

The best way I found to work out what is best to find the machines happy places and to see if it is dead nuts with Mach3, is to run some V carve/engrave letters and just running one axis at a time and seeing if it goes back to it's Zero.

This is where M3 can have problems lots of tiny moves in all direction. Doing it this way I can get 0.001 to 0.002 +/-0.001 per 1000 moves on any axis, Then when it comes to doing 2D cuts you can run it full wack and it's going to be good.

[Anonymous]

---

HughesTooling wrote: 

There's nothing special in the code at that point, just a rapid G00 so I think your accelerations or speeds are too high for your steppers and they're stalling.

---

---

@daniel_lyall wrote:

And cut your velocity in half or at lest 2/3 of what it is now. If it come's good that is what the problem is, This is a common as mud problem 

---

I've finally managed to get back on the machine and run some test files to see, and yes, it looks like some combination of cleaning and speed is a problem. I have a workaround (set High Feedrate Mode to not preserve rapids in the Linking pane of the toolpaths) and I think I'm set now...

Thanks everyone!

[Anonymous]

We are having the same problem. Everything looks fine, suddenly it shifts up to 3".

The home axis has been changed. The weird thing is we can run it again and it is fine. It is totally inconsistent.

The Mach 3 developers have looked at our code and said everything is fine.

[daniel_lyall]

At what point did this happen I had this happen 3 times in a row at the first tool change. there need to be more data for the fusion cam guys to fix the post or us Mach3 users do it. 

[Anonymous]

We are a college, it has been happening to many different students during a cut, it has happened many times on the middle of a third pass...and even when the router is going straight, it suddenly resets, and continues cutting up to 3" off where it was supposed to print. NOT a fusion file, came from Vcarve to Mach3. Mach3 guys couldn't find anything wrong with the files. To me it looks like a software bug, because it is inconsistent.... i.e. we run the same file again and it works fine.

[daniel_lyall]

If it happens in a cut the chances of it being fusion at fault is quite low.

Mach3 can chuck a random bug where it will not run a Gcode you restart Mach3 and it will run the Gcode.

All these bugs that come up in mach3 will never be fixed.

[Anonymous]

Yes, as I said before, not using fusion, or blaming fusion. Believe it is in the Mach3.