Toolpath is scaling my Y axis?

[gentwistle]

I am moving to Fusion after years of running my school's CNC router on RhinoCam.

When I post a toolpath generated in Fusion, my Y-axis appears to be getting scaled down. I posted the same toolpath using RhinoCam. All three axes are correct, so I know it isn't about retuning the axis motors.

I can try to add G51 code to adjust the scaling, but I'd like to find a more elegant solution.

Is there a setting somewhere that I may have changed the toolpath scaling? I am new to Fusion, so I worry I missed or didn't understand some setting. The scaling does not appear in my drawing. 

One test toolpath I used was a simple 2"x2" square. Going over the g-code, it was outputting moves that should have resulted in this shape- the math checks out.

Further background: The CNC is old, and is currently being run from Mach3 with some hardware changes internally. It is a Precix (which I do not recommend), I have used the machine builder to make a digital twin of my machine, and that is the one specified in my setup. I have also modded the post processor to set custom default settings (to make it easier and safer for students to use).

Thanks for any leads-

Graham

[Garrett_Wade]

This sounds like an issue on the machine side. If the gcode shows its outputting the correct code you may have something setup wrong downstream.

Double check setup in the controller, any pulley/gears at play and if its steppers check microstepping on the drivers to see what those are set to.

[gentwistle]

Thanks for the reply, Garret.

That's what I thought at first, but when I sent the same job via my old CAM, it was accurate. If the problem is in the CNC machine, it would show up in with Gcode from either CAM source, no?

[seth.madore]

@gentwistle can you share the NC code that is produced by both CAM packages so we can compare the output and play "what's different"? They should have either a .txt or .nc file extension, rename as needed and attach 🙂

[gentwistle]

thanks, @seth.madore I have attached the two posts. I found the lines where the bit was doing the outside pass of the square, and the X and Y values check out. The target square was 2" on a side, my bit was 0.216diameter and the X and Y travel distances were 1.784 for both posts- Fusion and Rhino. I put some whitespace around the relevant lines if you want to look for yourself.

[seth.madore]

As you have found, the math of the g-code does certainly check out. Thus, I would start looking at a couple things:

1) Your Rhino CAM post produces a few different preparatory g-codes at the beginning of the file, as compared to what Fusion produces. This may be a dead-end, as I'm doubtful that this is the cause.

Fusion:  

G90 G94 G91.1 G40 G49 G50 G17
G20

Rhino:

G00 G49 G40.1 G17 G80 G50 G90
G20

 The other difference, and I think this may be the source of issue: arc moves. Rhino is not permitting any arc moves, but rather, is turning arcs into point-to-point moves. We can start by enabling "Radius Arcs" in the post processor dialog. If that shows no improvement, then I would suggest editing the post processor to prevent any arc moves from being output (it will break it into point-to-point moves).

You're looking for this line in the post:

 

Taken from the manual:

 

[HughesTooling]

@gentwistle  How much under size is it in the Y? Looking at the G gode the RhinoCAM stepover is a lot smaller than the Fusion stepover. Any chance it's just flex in the machine? The Y axis on routers tends not to be as rigid as the X. Have you tried adding a finish pass with a small step over?

Here's a backplot of the 2 toolpaths.

[engineguy]

@gentwistle 

I suspect that @seth.madore is pointing in the correct direction regarding the Arcs, disable the Arc outputs and you will just have the Point to Point. 🙂

Just a thought, you say the CNC is very old and is being controlled by Mach3, from what I have read it is possible that it is a very old version of Mach3 in the controller which in the early days did use G40.1 and G40.2 to switch the TC, this was dropped later and the G91.1 (Incremental Arcs) adopted.

Something to try might be to change the G91.1 to G40.1 and see if the code from the Fusion Mach3 Post Processor will then run correctly, although I doubt it, if so then it is an easy change to have the PP output the G40.1 instead of the G91.1 so the old control software may accept it. Just a thought 🙂

[HughesTooling]

At first I thought arcs would be the problem but because it's quite a way from the origin if you backplot with ABS arcs it's very obvious it's wrong! Could be the machine is set to ABS arc centres and the code is Incremental and the control is doing something clever to stop these big arcs but I doubt it.