Gcode / PP problem on Parallel Passes (gouge in middle of milling piece)

Hi there,

A few details of what I’m using:
Arduino Ramps 1.4 board running Marlin
Dewalt 660
Repetier on Mac
Martin DB Post Processor
Fusion 360

Project is a terrain map. Toolpaths created in Fusion from mesh / stl file.

Trouble is only on parallel passes, pocket milling all good.

Pictures and Gcode uploaded. 1002 is a rough parallel pass, 1003 is the finishing one.

Edit: Problem is happening on the first cut of the milling. The issue is not showing up in Fusion 360 simulator or a third party nc viewer at all.
Gouge is from centre to east (as per fusion view), but centre to north (as per MPCNC home axes).

1003.gcode (2.3 MB)

1002.gcode (1.7 MB)

1 Like

Oh, that is a bummer. And it is a very cool looking topo map.

That is a rambo, not a ramps.

Did it plunge and then travel out or travel in from the outside? Did you stop it or did it continue after that?

I wonder if one of the drivers overheated. Is there a way you can hook up a 12V fan and cool the drivers?

One potential problem is that you are pushing Z too fast and likely losing steps…assuming you have not already modified your Marlin firmware.

G1 Z-17.978 F1000

I found that I lost steps at feedrates over 600mm/s, and Ryan’s EstlCAM setup recommends 480mm/s as the rapid/max feedrate.

If you are using the personal/free version of Fusion 360, then recent changes mean that the Z gets pushed as fast as X and Y. On an MPCNC, the lead-screw-driven Z axis cannot be pushed as fast as X and Y and steps are lost. The “solution” is to limit the Z feedrate in the firmware. You can send the following two g-codes once (it is a persistent change):

M203 Z8 ; Limit Z feedrate to 8mm/s (480mm/min)
M500 ; Save the changes to EEPROM

Not related to your question, but I’ve done a couple of these maps. I used a Contour finishing pass and was very happy with the results. Any stepping tended to be hidden in the structure of the terrain.

Thanks Jeff. Rambo sorry, thank you.

It plunged straight down, went out to the edge and then down to the start of the cutting toolpath. I kept it running as I wasn’t sure if this was the actual depth of the model. I had thrown out 3 test versions before this so I wanted to see this through to the end. Anyway, the problem is at the very beginning.

I ran it again this morning with the tool set higher in the air but I separated out the instructions one by one. When doing this, it moved straight to the corner without plunging. I have zero clue what this means.

And yes a bit of a bummer, but I’ve turned the issue into a feature for this one. Pretty happy with it, just needs clean up and finish… Keen to figure out what is going on though.

1 Like

Robert thank you.

The feed codes are completely puzzling to me, e.g. I see F2500 when I haven’t inputted that at all. Everything should be metric but perhaps this is a difference in mm/s to m/min?
I did see a G21 error code now that I think of it. But this makes no sense, Fusion is all in metric and Martin’s PP specifies that everything is metric.
I get what you’re saying re Z feedrate, of course the Z axis can’t travel the same as X & Y. I’m on the monthly Fusion subscription.

So if I have this correct, I place in that gcode into the start of the job file? Or just when the machine starts up, then load my gcode and run the job.

I also don’t understand why the print time is so far off the actual time, is that a common issue? And what can I do to nail this down and fine tune please.

Contour finishing pass is genius, the marks will add to the feature.
Have you any advice for cutting down milling time on terrain maps? Adaptive clearing seems very slow. Pocket clearing seems better and I pushed this to 3mm depth per pass without problems. 4-flute flat end mill.
Perhaps a second pocket pass with 1mm depth and then a contour finishing on a ball end bit?
Or is there any way to run 2 passes that are less than 8 hrs (time in work - I don’t like to leave it running when I’m not there). Image above was done over 3 days, approx 5 hours per pass/job. I’d love to get this done in 1 day.

The feed codes are completely puzzling to me, e.g. I see F2500 when I haven’t inputted that at all.

I’m guessing the F2500 is a rapid movement. If you are using the personal/free version of Fusion 360, then I’m surprised to see it. It may be an artifact of Fusion 360’s recent changes to its personal/free version combined with the Martin DB Post Processor. Most people on this forum that use Fusion 360 use the guffy post processor. The values are in mm/min.

So if I have this correct, I place in that gcode into the start of the job file? Or just when the machine starts up, then load my gcode and run the job.

No. You only have to run it once. After that the new values are saved in the EEPROM. You can type this g-code in from Repetier-Host. You can type it into a text file saved with a .gcode extension and run it of an SD card. Note that the value for the M203 is in mm/s not mm/min.

Contour finishing pass is genius, the marks will add to the feature.

It’s probably going to add time, but I had near zero finishing to do at the end of the run.

I don’t have advice on speeding things up. I only cut a few, smaller terrain maps. There are many active people on the forum that have far more cutting experience than I do. I would suggest you open a topic just on this issue. Note the 4-flute end mill is raising red flags for me when combined with the DW660.

I’m guessing the F2500 is a rapid movement. If you are using the personal/free version of Fusion 360, then I’m surprised to see it. It may be an artifact of Fusion 360’s recent changes to its personal/free version combined with the Martin DB Post Processor. Most people on this forum that use Fusion 360 use the guffy post processor. The values are in mm/min.

Ok. I can’t get Guffy’s PP to work, the gcode file just doesn’t appear. Maybe this suggests a problem in my initial set up?
The Z feedrate is indeed coming from the feed per tooth, in turn from the cutting feedrate. 2500 / 60 / 10,000 = 0.00416. Why I have to divide by 10,000 I have no clue!

I think I’m having the same issue as this guy which you both commented on. I’ll try the M203 and report back.

The rapid feedrate from Fusion is probably also throwing my actual print time off, which I’m keen to refine. Or is this always going to be different and I shouldn’t worry.

No. You only have to run it once. After that the new values are saved in the EEPROM. You can type this g-code in from Repetier-Host. You can type it into a text file saved with a .gcode extension and run it of an SD card. Note that the value for the M203 is in mm/s not mm/min.

Ok thanks. So adjust the mm/s value to mm/min? Then run and it’s done.

I don’t have advice on speeding things up. I only cut a few, smaller terrain maps. There are many active people on the forum that have far more cutting experience than I do. I would suggest you open a topic just on this issue. Note the 4-flute end mill is raising red flags for me when combined with the DW660.

Thanks, I’ll open up a thread as soon as I sort this gouge issue.
The map is quite small, 250mm x 250mm. My machine is about 900mm square, giving about 450mm sq print/milling area.
The red flags for 4-flute - are less flutes better? For chip load on a heavy pass I assumed the more teeth the better. I’m not using it for a finishing pass.

When I run the code line-by-line, the machine didn’t gouge out the piece. It went straight to the starting corner. I have no idea what this means. Could this be a G1 linear move problem? As in the machine is moving along the axes rather than X & Y at the same time for a diagonal move? It’s all at the start of the operation, no trouble otherwise.

I think it’s solved!

CHANGES TO GCODE:
;Fusion 360 CAM 2.0.5357
;Posts processor: MPCNC_Mill_Laser.cps
;Gcode generated: Wed Jan 13 16:11:19 2021 GMT
;Document: Roundwood Final v1
;Setup: Setup2

G90
G21 REMOVED
M84 S0
G92 X0 Y0 Z0

;Probe tool - Not yet implemented

;Parallel1 - Milling - Tool: 1 - flat end mill
;X Min: -125.692 - X Max: 125.687
;Y Min: -125.692 - Y Max: 125.662
;Z Min: -18.428 - Z Max: 15
M400
M117 Parallel1 REMOVED
G1 Z15 F300
G1 X125.319 Y-124.996 F2500
G1 Z-16.112 F300
G1 Z-17.805 F500

The Z axis feedrate limiting is a big help but it didn’t solve the issue.

I removed G21 as this was giving an error code and M117 as I have no LCD.

It seems the M117 problem was allowing the machine to skip ‘G1 Z15 F300’ and screw up the following instructions. Perhaps take them individually, sending it out and down rather than diagonally. Have I got that correct?

Anyway it’s not doing it doing it so happy days.

I can’t get Guffy’s PP to work, the gcode file just doesn’t appear.

I’m not sure if the issue is that you cannot bring up the guffy postprocessor or if you run the postprocessor and don’t get a .gcode file. If the issue is the latter, then perhaps you are producing a .nc file instead and need to modify this setting:

Extension

…or perhaps you are not looking at the output location for the file.

If you cannot bring up the PP:

This is the release point I used for my guff PP:

On my Windows machine, I placed my post processor here:

C:\Users\rober\AppData\Roaming\Autodesk\Fusion 360 CAM\Posts

And in that directory, you need to put both files:

  • DIYCNC_Marlin20.cps
  • DIYCNC_Common.js

throwing my actual print time off

If you are talking about Machining Time, then I find that adaptive clearing time is way off, but values for most other tool paths tend to be accurate. I don’t know if the recent Fusion 360 changes impacted these times in any way.

The red flags for 4-flute - are less flutes better? For chip load on a heavy pass I assumed the more teeth the better. I’m not using it for a finishing pass.

With a router running at a fixed 30,000 rpm, and assuming a 1/4" shank bit, you would need to set your cutting feedrate way faster 500mm/min to have an “appropriate” chip load for a 4 flute end mill. For a given set of setting (rpm and feedrate), more flutes means each tooth is cutting less material per revolution. You want each tooth to be shaving material, not grinding the material. That is a why you see 1/8 shank, single and two flute end mills favored for this machine when using DW660.

Hi Robert,

Thank you. I have the .cps file in the right folder alright but I will try it again. I have it working on Martin’s one for the moment though.

I hear you re adaptive. Times are getting closer with the few attempts today. I guess this is just a case of refining as I go.

4-flute red flags, thank you. I never thought of it as grinding but that makes complete sense now.

Thank you again for your help and Jeff too. This one is looking really good. Next one is roughed out already with no gouge.

2 Likes

That looks awesome.

I love how the plys give you automatic altitude lines!

3 Likes