Additive / AnyCubic post / Painfully slow travel times

[tim.wallsXFXNQ]

Hi,

In my ongoing quest to coax good-quality prints out of the F360 slicer, my latest problem is that travel movements (i.e. movements without extruding) on the 'real' printer for F360 generated gcodes are *painfully* slow.

This doesn't just affect the time it takes to print, it also affects quality - it's like watching a snail slowly march across the print trailing filament any time the nozzle moves to another position on the part.  I could probably reduce this by increasing the filament-retract distance, but that's not going to help print times.

(The "travel speed" setting in the print settings panel seems to have zero effect on this - that was my first instinct to try.)

I presume this is something specific to the AnyCubic postprocessor.  I should say, gcodes generated from Cura do not have this problem.

Comparing the gcodes from F360 and Cura,

Preamble from Fusion360 generated file with slow travel problem:

;1001
;Firmware: Marlin
;Printer Name: AnyCubic AnyCubic Mega-X
;Print time: 17146s
;Extruder 1 Material used: 14288mm
;Extruder 1 Material name: PLA 1.75mm
;Extruder 1 Filament diameter: 1.75mm
;Extruder 1 Nozzle diameter: 0.4mm
;Extruder 1 offset x: 0mm
;Extruder 1 offset y: 0mm
;Extruder 1 offset z: 0mm
;Max temp: 220
;Bed temp: 70
;Layer Count: 100
;width: 300mm
;depth: 300mm
;height: 300mm
;center x: 150mm
;center y: 150mm
;center z: 0mm
;Count of bodies: 2
;Version of Fusion: 2.0.8950
G28 X0 Y0
G28 Z0
;--------------------------------
;Selected Profile: Colorfabb PLAPHP 1.75mm, 0.4mm Nozzle
;Selected Printer: AnyCubic, AnyCubic Mega-X
;--------------------------------
M140 S70
M105
M190 S70
M104 S220
M105
M109 S220
G21
G90
M82
G92 E0
G1 F236
G0 Z0
G0 X0 Y0
G92 E0
;--------------------------------
;Layer : 1 of 100
M107
;rapid-leaky
G0 X3 Y3.8 Z0.2
G1 F1800 E5
;bead-prime
G1 X297 F270 E44.114
G1 F1800 E39.114

Preamble from Cura generated file with no problems:

;FLAVOR:Marlin
;TIME:35856
;Filament used: 50.4251m
;Layer height: 0.2
;MINX:10.778
;MINY:52.3
;MINZ:0.1
;MAXX:289.458
;MAXY:242.955
;MAXZ:19.975
;Generated with Cura_SteamEngine 4.7.0
M140 S70
M105
M190 S70
M104 S200
M105
M109 S200
M82 ;absolute extrusion mode
G21 ;metric values
G90 ;absolute positioning
M82 ;set extruder to absolute mode
M107 ;start with the fan off
G28 X0 Y0 ;move X/Y to min endstops
G28 Z0 ;move Z to min endstops
G1 Z15.0 F80 ;move the platform down 15mm
G92 E0 ;zero the extruded length
G1 F200 E3 ;extrude 3mm of feed stock
G92 E0 ;zero the extruded length again
G1 F80
G0 Y20 F80
M117 Printing...
G5
G92 E0
G92 E0
G1 F1800 E-10
;LAYER_COUNT:100
;LAYER:0
M107
G1 F1800 Z0.175
G0 X31.421 Y79.15 Z0.175

Now, I know pretty much nothing about G-Code, but I believe the problem is that F360 never sets a feed-rate for its G0 moves.  If I am understanding what I read about the Marlin firmware, it has a single feed-rate for both G0 and G1 moves (apparently there is a V2 that has the option of separate feed rates for both, but AnyCubic at least doesn't seem to be using it.  In any event, F360 never outputs a feedrate for G0, so this wouldn't actually fix the problem on its own.)

That leaves the "rapid" moves actually travelling at the rate of whatever the last extrusion move was, which is undesirable.

I tested this theory by manually editing the gcode and sprinkling some "F6000"s after the first few G0s, and it did indeed seem to behave much more as I would expect.

So, TL;DR version in three questions:

1. Is there a hidden setting somewhere in F360 labelled something like "use travel speed setting"?
2. Maybe someone at Autodesk would like to fix the postprocessor for AnyCubic (and possibly any others using the same firmware that might have the same issue?)
3. Can I copy the postprocessor and edit it myself to get a working version?  (Just a point to instructions on how to do this if it's possible would be gratefully received.)

Cheers,
Tim

[seth.madore]

So the solution is to ALWAYS have an F6000 output at every G0? This is interesting to me, since all the CNC I'm familiar with a G0 is a rapid with no feedrate attached to it. Is there any difference between a G1 F6000 and a G0 F6000?

[tim.wallsXFXNQ]

I think you might be asking slightly beyond my competence if I'm honest, but certainly you need to set the feedrate for every G0, it seems, or it will just use the last feedrate specified for G1 or G0.

Where you would have a problem just blindly adding F6000 to every G0 is if you had a pattern like this:

# On the AnyCubic, this will probably produce a spaghetti monster...
G1 F100               # Set the feedrate for the next extrude
G0 F6000 X123 Y456    # Rapid-Move the head to the next location
G1 X123 Y512 E10      # Extrusion move which I expect to be at the 100mm/minute I set above, but will actually ramp up to 6000mm/minute...

On the default Marlin firmware, the G0 would reset the speed also for the following G1, which would mess with things.

In other words, I think you basically have to treat G0 and G1 as synonyms for the same underlying command.  So, if you set the feedrate on every G0 that's good, but you have to remember to then set it to what you want in the following G1.

Fortunately, in the gcode file I looked at, it was the case already that every G1 following a G0 also specified the feedrate - so doing a simple search-and-replace of "G0" with "G0 F6000" has produced a working file, that is printing now, and so far the results are looking good!

According to this https://marlinfw.org/docs/gcode/G000-G001.html - "Marlin 2.0 introduces an option to maintain a separate default feedrate for G0", but it's not clear to me if that's an option that vendors choose to enable when they build the firmware, or an option enabled by another gcode command (if the latter, I've not been able to find it.)

Incidentally, it shouldn't be hardcoded "G0 F6000" I guess - it should be "G0 F(travel_speed_setting * 60)" (if I'm right in my belief that the travel speed setting in the Print Settings is mm/s, and in the gcode is mm/min.)

I can't do any experimentation at the moment because I'm going to let that test print run to completion, which will likely take another hour or two, but if there's anything you'd like me to test later please let me know!

Thanks,

Tim

[tim.wallsXFXNQ]

Edit; sorry, duplicate message.

[serge.quiblier]

Hello @tim.wallsXFXNQ 

There something strange, because in our test case we have for example :

M82
G92 E0
G1 F6000
G0 Z10
G0 X0 Y0
G92 E0
;--------------------------------
;Layer : 1 of 30
M107
;rapid-leaky
G0 X10 Y10.75 Z0.2
G1 F1500 E7
;bead-prime
G1 X90 F216 E10.762
G1 F1500 E3.762
;rapid-dry
G1 F6000
G0 X72.25 Y27.75
G1 F1500 E10.762

So for the line G0 X72.25 Y27.75, i would expect the printer to "remember" the feedrate outputted the line before using G1 F6000.

If forcing the F6000 on the G0 line solve the issue, you can do the following:

1- There is no such setting for the additive fff toolpaths.

2- If it's a global issue we can fix this.

3- If you want to fix this in order to be able to test further, you can do the following.

Search for the onRapid command :

function onRapid(_x, _y, _z) {

  var x = xOutput.format(_x);

  var y = yOutput.format(_y);

  var z = zOutput.format(_z);

  if (x || y || z) {

    writeBlock(gMotionModal.format(0), x, y, z);

  }

}

We will then alter the command so that it look like :

function onRapid(_x, _y, _z) {

  var x = xOutput.format(_x);

  var y = yOutput.format(_y);

  var z = zOutput.format(_z);

  feedOutput.reset(); // to force output of feed rate even with the same value

  var f = feedOutput.format(highFeedrate);  // added for feedrate output

  if (x || y || z) {

    writeBlock(gMotionModal.format(0), x, y, z, f); // add the f

  }

}

@seth.madore  fff printer doesn't act like a cnc machine. With a cnc machine, G0 has a fixed speed defined by the mtb, and may or not be interpolated. The fff printer firmware/hardware doesn't really differenciate G0 to G1, it's interpolated, with the feed defined in the move, or the actual feed rate.

Regards.

______________________________________________________________

If my post answers your question, please click the "Accept Solution" button. This helps everyone find answers more quickly!

[tim.wallsXFXNQ]

Hi Serge,

Thanks again for your answers :).

Weird; when you say in your testcase, you mean your testcase outputs that G1 F6000 line?  Because it's definitely not generating it for me :-(.  You can use this project if you need a different test case: https://a360.co/3kDiT9F

Re. the following:

1. There is this, though:

(Edit - ahh, I misunderstood on first reading.  So, is this what I will get with the highFeedrate variable?  Is it converted to mm/min already by the time the code in the postprocessor sees it?)

2. Super.

3. Great - only problem is, I have literally no idea where to even start looking for the file to edit; is there an idiot's guide around somewhere?  (Not an idiot's guide to programming, that's my day job - rather something that can save me hunting for the right files to edit, and how to know F360 is using my copy of the file and not something it's plucked from the cloud somewhere...)

[serge.quiblier · Accepted solution]

Hi @tim.wallsXFXNQ 

1- This is sometime used, but there is 2 différents rapids feed rates.

Sometimes the pure output is F15000 for the XY only moves. But in the post we are ceiling the value to the high feedrate defined at the top of the post. Some Z only move are using the feedrate from screencapture.

We have in the milling workspace/postprocessor the ability to convert G0 moves to G1 moves with a high feedrate.

(1- some machine doesn't have speed control for rapid, so you cant' modulate, 2-others don't interpolate, making dogleg move instead of straight lines. 3- user preferences..)

3- Here is a link to references for editing the postprocessor:

https://forums.autodesk.com/t5/hsm-post-processor-forum/technical-faq/td-p/7473258

2- this step will take some time, Making the change, submitting for review, waiting for checking and approval.

Have a nice day.

Regards.

______________________________________________________________

If my post answers your question, please click the "Accept Solution" button. This helps everyone find answers more quickly!

[tim.wallsXFXNQ]

Ahh, it looks like that link at 3 is exactly what I need; thank you, perfect.  Now I have a weekend project ;).

I should say as an aside, now that I have initial teething troubles out of the way, I'm liking what I see.  In particular, I notice that the F360 generated gcode does a much better job of things like the modelled thread in that example than I get with ->STL->Cura workflow.  I don't know if that's blind luck, or if the F360 slicer is able to skip the conversion to mesh and make smarter decisions knowing the true geometry, but either way it makes me want to stick at it.

Thanks again, & have a great evening (or day, depending where in the world :).)

[tim.wallsXFXNQ]

Hi Serge,

Just thought I'd drop a quick update.

I think I found the root cause of my problem; and I don't think I actually needed your change to the post (although since I've made it now anyway, I may as well keep it - so thank you for that anyway.)

So, for anyone else reading this thread - what I did discover is that the value for "highFeedrate" is being set from the post-processor Properties table, and seems to be set there by default to a value in inches (236) regardless of whether or not the document unit is inches, and regardless of what the "output units" are set to in the Post Processor window.

It seems F360 does in fact update the feedRate before each rapid move (which is output as a G1 Fxxx instead of a G0, but for as long as the Marlin uses the same feedrate for both it'll work fine - when the firmware switches to treating G0 differently is when your patch to the post will be needed), but it was being capped by setFeedRate at 236mm/min by that faulty highFeedrate parameter.  Change that to 6000, and we're good :-).

Maybe it would be better for Autodesk to default that value to nothing-at-all (which I assume would then let the post processor's logic - which does try to pick a value based on the document units - prevail) than to a value that only makes sense for machines that measure in perches, chains and furlongs (do such things really exist?)

(I may modify my post to just ignore that property entirely, but that doesn't seem an ideal fix for everyone - but maybe the setFeedRate method capping at that faulty parameter when (onParamater(feedRate,...)) is called is unique to the FFF post, in which case maybe it is.)

Cheers!

Tim

[serge.quiblier]

Hello @tim.wallsXFXNQ 

Here is an explanation on the management of the rapid feedrate for the fff additive workspace.

The print setting define a Travel Speed.

This feedrate is then passed to the post using the onParameter function.

In the example the feedrate will be 250 * 60 = 15000 mm/min.

The onParameter will call a function setFeedRate

// user defined functions

function setFeedRate(value) {

  feedOutput.reset();

  if (value > highFeedrate) {

    value = highFeedrate;

  }

  writeBlock(gFormat.format(1), feedOutput.format(value));

}

This function will eventually limit the feedrate below the highFeedrate value. This value is defined at the top of the post.

highFeedrate = (unit == MM) ? 6000 : 236;

So depending on the unit the value will either be 6000mm/min or 236in/min.

We are using regression tests on the fff posts. And our expected result for inch and millimeters output are as follow:

So we have the expected values for inches output, or millimeters output.

What is the unit for your Fusion file? And for the gcode output?

Or can you provide a file so we can have a look at what is going on?

Regards.

[tim.wallsXFXNQ]

Hi,

I'm not referring to the feedrate in the travel speed in the print settings, I'm referring to this beauty:

...whose default value of 236 "somethings" (but obviously a default set by someone who works in inches) overrides all the good work of the highFeedrate = (unit == MM) ? 6000 : 236; line in the post and just forces it to 236 mm/min.

Unfortunately I don't have more time to devote to this right now, I'm dealing with the fact that the monstrosity that is Eagle is constantly crashing while I have a job to finish (CER_227090947, CER_227090428, buggy 1980s interface fans.)  But if I get a chance one evening I'll dig in more.

[serge.quiblier]

Hello @tim.wallsXFXNQ 

What is your OS?

Because on Windows 10 with a european setting (French).

I don't have this behaviour.

As you can see the high feedrate if 6000 and t's also 6000 in the tooltip as default value.

Regards.

[tim.wallsXFXNQ]

Hi Serge,

OS: Mac OS X Catalina (10.15.7)

System locale: Romanian (ro_RO.UTF-8), Units of Measurement: Metric

F360 Preferences - Default Units - Design: mm

F360 Preferences - Default Units - Manufacture: mm

F360 Preferences - Default Units - Simulations/Gen Design: Metric (SI)

Document Units - mm

 

Where does F360 get those defaults from?  I notice that with other posts in the default library, that value is zero - only with the Generic FFF (and my own personal post derived from it) do I see 236.  So assuming it gets it from the post itself, then maybe this line...

highFeedrate = (unit == MM) ? 6000 : 236;

...isn't doing what you think it should?

[serge.quiblier]

The highFeedrate is defined in half of all the Autodesk posts for Fusion.

And yes it's taken from this initial line you mentioned.

It's seems that the Mac release of Fusion has a bug.

I don't know if it's the post engine when retrieving the data, or Fusion when using/displaying it!

I will report the issue.

Have a nice day.

[Anonymous]

PROBLEM SOLVED - Thank you tim.wallsXFXNQ!

My speed is now 25.4 times faster while traveling between printed sections!!

Thanks for the tip to change the "(Built-In) High Feedrate" from the default 236.22 to 6000.

236.22inches x 25.4mm/inch = 6000mm

I've had my ANYCUBIC MEGA S for only a week and now I got a great improvement with this tip!