@littlehobbyshop
I think I got it to work. There are two lines of sneaky variables that I missed the first time I copied the blocks over, had to do with the var iOutput = createReferenceVariable({prefix:"I", force:true}, xyzFormat); // circular output1 and
var jOutput = createReferenceVariable({prefix:"J", force:true}, xyzFormat); // circular output variables being missing in my initial modification to your post.

For whatever reason, it is not working with a custom print profile, but I changed over to the stock "ABS 1.75mm" print profile and it was generating G3 commands for a flat donut shape.

unofficial rrf machine with arc smoothing.cps

1032.gcode

I think modifying the stock print profiles in certain ways may affect the curve fitting.

@bot I agree, fitting after the fact is not optimal but it is a step in the right direction. Probably leverage existing code from their CAM workspace to make it work.

I was reading the current roadmap blog post for Fusion 360, and it seems they are working on implementing G2/G3 support. (Also adding support for resin printers but I think the vast majority of Duets are used with filament printers.

Fused Filament Fabrication (FFF) Improvements

After the March 2020 update, Fusion 360 became a slicer for FFF printers overnight. As awesome as this release was for FFF, it had a couple of kinks. The team has, since then, been working hard at improving the usability and fixing any and all reported issues. You can expect to see a continued investment in this area. We are adding new printers, new post files and new functionality update after update. Some of the key projects that excites us are around G2/G3 support, new infill types, dual extrusion improvements and overall increased performance around toolpath generation.

Stereolithography (SLA) / Digital light projector (DLP) 3D Printing

FFF and metal powder bed fusion printers are great and all, but 3D printer processes are very diverse, and we want Fusion 360 to support all kinds of printing techniques. We are working on enabling SLA and DLP print preparation such as integrating printer workspaces, SLA/DLP specific support generation methods, packing parts within the platform, and slicing models for these types of printers. We can’t wait to see what you design and print using Fusion 360.

https://www.autodesk.com/products/fusion-360/blog/fusion-360-roadmap-update-2020/#Additive

(They do have a section on their forum for adding feedback for the FFF slicer part of Fusion 360, so I would think a fair amount of Duet users could give them some good, critical feedback on the quality of toolpath generation, needed features, issues, etc.)

I would like to present the Hydra 400 - a tool changing 3D printer with a 400mm cubed build volume, rigid frame made from 3030 and 3060 aluminum, integrated filament bay, and heated enclosure. We will be using the Duet 2 Wifi with a DueX5 to power all of the steppers and associated things we will be including.

I and my senior capstone team at my university have spent the last 7 weeks designing this, and will build the machine in the fall. The tool changer mechanism we are using can be found here: https://www.thingiverse.com/thing:3365456 all credit goes to the original designer, and many thanks for him releasing it open source. At this point the design is about 95% complete, with some small details here and there that still need to be figured out.

This forum and its community have provided a huge source of inspiration for this project. As project lead, the knowledge gained from this forum and others enabled me to very quickly and efficiently determine the most feasible design choices for our limited amount of time given for design, allowed me to make quick design choices, and effectively demonstrate to our professor that though our scope of work is large, we would be able to deliver upon all of our stated goals.

We are planning on releasing our design files, full bill of material with links to where we are sourcing components, and config.g and Cura machine profiles once we are finished with the project; open source is the whole reason behind the state of the 3D printing industry currently and we would love to contribute to it.

As the title says, the slicer in Fusion 360, while still a little rough, now has the ability to apply 'Arc Fit Optimization' for models.
Super stoked about this development, and I am actually surprised they got around to implementing it this quickly given how slow they have been with other needed updates for other environments (namely adding weld symbols in the drawing environment)

Seems that the new fiber printer from Desktop Metal (competing with Markforged obviously) is using a Duet with a Panel Due and also using the tool changer concept from e3D (and what seems to be at least an e3D nozzle if not an entire v6 hotend assembly

https://www.desktopmetal.com/products/fiber/

@t3p3tony Our main inspiration was the e3D ToolChanger! As soon as I saw videos of that I knew i wanted to do something similar for my senior project.

My team and I only have around 8 weeks to do the design of the machine, so that open source cable driven tool changer mechanism seemed like the cheapest, easily made/modified, and most reliable method we could find. It would have added to our scope of work to also design a tool change mechanism from scratch, and although doable it seemed more practical to make use of and modify a preexisting design.

We're using Markforged-style kinematics for the XY axis, and I haven't seen much on the forum about people actually making use of that kinematic class in the firmware so it will be interesting to get that working.

@Phaedrux @arhi @littlehobbyshop

Look for this line in the RRF post processor (or your own custom one):

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

Beneath that, copy and paste this block:

// used for arc support or linearization
tolerance = spatial(0.002, MM); // may be set higher i.e 0.02?
minimumChordLength = spatial(0.25, MM);
minimumCircularRadius = spatial(0.4, MM);
maximumCircularRadius = spatial(1000, MM);
minimumCircularSweep = toRad(0.01);
maximumCircularSweep = toRad(180);
allowHelicalMoves = false; // disable helical support
allowSpiralMoves = false; // disable spiral support
allowedCircularPlanes = 1 << PLANE_XY; // allow XY circular motion

And farther below that, in the functions section, paste this below the onLinearExtrude function.

function onCircularExtrude(_clockwise, _cx, _cy, _cz, _x, _y, _z, _f, _e) {
  var x = xOutput.format(_x);
  var y = yOutput.format(_y);
  var z = zOutput.format(_z);
  var f = feedOutput.format(_f);
  var e = eOutput.format(_e);
  var start = getCurrentPosition();
  var i = iOutput.format(_cx - start.x, 0); // arc center relative to start point
  var j = jOutput.format(_cy - start.y, 0);
  
  switch (getCircularPlane()) {
  case PLANE_XY:
    writeBlock(gMotionModal.format(_clockwise ? 2 : 3), x, y, i, j, f, e);
    break;
  default:
    linearize(tolerance);
  }
}

Those are the only differences I can currently see between the generic FFF post processor and the Prusa post processor.

Note: I still have not tested this yet. Also, it may be worth looking in to the variables defining circular moves, i.e. minimumChordLength and seeing what those may change.

If it uses sensorless homing normally, wouldn't installing a normal endstop switch correct for that issue?

@TypQxQ

I have dual Y steppers plugged in to the Z-axis stepper port, with the X plugged in as normal. Only thing I needed to do to get the kinematics to work correctly was to invert a number in the motor matrix. Without the second Y-stepper racking was very severe.

@Phaedrux @arhi Scratch that, those additions aren't quite enough. Using the Prusa post however does generate G3 moves! It cut a roughly 1100kb file to around 500kb. Still trying to get the 'rrf' post to function correctly

@Phaedrux @engikeneer

;Z-Probe
M307 H3 A-1 C-1 D-1	             ; Enables usage of expansion header pins for BL Touch 
M558 P9 H3 F150 T5500 R0.2 A15 S0.01 ; BLTouch, set dive height, probe speed, travel speed, 
				     ;number of times to probe a single point, tolerance when probing multiple times
G31 X-16 Y-42 Z1.49 P25              ; X,Y offset, Z trigger height, P is signal threshold
M557 X-74:74 Y-42:42 S37:21          ; Define mesh grid
M376 H2.2			     ; Define mesh taper height (2.2mm), removes compensation above this height

; Axis Limits
M584 X0 Y1 Z4:2 E3 	       ; two Z motors connected to driver outputs Z and E1
M671 X-158:152 Y0:0            ; leadscrews at left (connected to Z) and right (connected to E1) of X axis
M208 X-102 Y-106 Z-0.05 S1     ; Set axis minima and low homing switch position
M208 X100 Y100 Z200 S0         ; Set axis maxima

Lead screw positions are relative to 0,0, and by buildplate is slightly off center. Possibly this is the main issue?

; bed.g
; called to perform automatic bed compensation via G32
;
M561 ; clear any bed transform
G30 P0 X-100 Y0 Z-99999    ; probe near a leadscrew, half way along Y axis
G30 P1 X84 Y0 Z-99999 S2 ; probe near a leadscrew and calibrate 2 motors

; --> Start G-code <--
G21     ;metric values
G90     ;absolute positioning
M107    ;start with the fan off
G29 S2  ;clears existing bed heightmap
G28     ;home all 
G32     ;motorized gantry plane correction
G32     ;
G32     ;repeated 3 times 
G29     ;mesh bed compensation 
G1 Z20 F6000 ;move the nozzle to Z=20mm
G1 F100 E5 ;extrude 5mm of filament
G92 E0  ;zero the extruded length

@engikeneer

The heightmap is cleared before every print as a start, and mesh leveling only happens after homing and tramming. However, I am not resetting my z-axis zero after every tramming command. I can see now how that would be an issue. Probe offsets should be optimal, as well as leadscrew positions.

First thing I will try will be to insert a G28 Z command after every tramming attempt and see if that solves the issue.

It is strange, though, as I do not remember this being an issue when I first switched to independent dual z-axis stepper control.

If that does not work I will post relevant files to see if someone can spot an error in what I have configured.

Hello all,

Wondering if anyone has any suggestions for me: currently my pre-print routine consists of zeroing all axes, running an autotramming of the gantry 3x times, and then running a mesh bed compensation.

What I have noticed is that the right side of my build plate is always closer to the nozzle, and the left side farther away at the beginning of the print. I am using a BLtouch, multiple probes per point. I had assumed probing multiple times per point, along with autotramming three times, would ensure that my gantry is planar to my build plate, but it seems this is not the case.

Does this seem like a mechanical issue, or possible due to the multiple probings/accuracy issues with the BLtouch?

It is a real shame that Autodesk's personal use policies have detracted from the addition of a barebones 'arc fit' function for their slicer in F360. I just thought it was a neat addition, and implemented very quick compared to other features, but it got overshadowed immediately by removal of features. I feel the better direction would have been to stagger some features behind cheaper paywalls (i.e. $10 USD/month for 5-axis CAM, $10USD/month for simulation, etc) vs locking everything behind a commercial subscription when it is likely a majority of their current user base are not commercial.

(edit: spelling)

@bot said in Fusion 360 FFF Slicer: G2/G3 Generation Now in Preview:

They already removed importing of "professional" cad formats last year or early this year. So, no more STEP, IGES or SLDPRT/ASM for free users.

Actually, STEP/IGES are still allowed.

https://www.autodesk.com/products/fusion-360/pricing?_ga=2.5665779.1578081928.1600206184-2086964182.1571363456

Interestingly enough, apparently you can still export to an Inventor part/assembly file, but not import! Very odd.

@bearer

There is no mention of changing import options, so you could conceivably still import .step or.iges files. Also, Fusion project files can still be exported, so a workaround for storage of only 10 projects could be exporting the project and archiving it on a local storage solution and then re-uploading it when needed. Not sure what archived/active means, I don't see the difference between continually 'archiving' and then making a document 'active' unless the process is annoying enough to make it an unwanted step in the modeling workflow.

I think these changes were brought about from people abusing the personal license for commercial uses. Even then, a yearly subscription for Fusion 360 is only around USD $500, which is a lot cheaper than the major CAD/CAM players (Solidworks, Inventor, Solidedge, etc). (Yes, cheaper is relative, five hundred dollars isn't an insignificant amount of money)

@littlehobbyshop
I think I got it to work. There are two lines of sneaky variables that I missed the first time I copied the blocks over, had to do with the var iOutput = createReferenceVariable({prefix:"I", force:true}, xyzFormat); // circular output1 and
var jOutput = createReferenceVariable({prefix:"J", force:true}, xyzFormat); // circular output variables being missing in my initial modification to your post.

For whatever reason, it is not working with a custom print profile, but I changed over to the stock "ABS 1.75mm" print profile and it was generating G3 commands for a flat donut shape.

unofficial rrf machine with arc smoothing.cps

1032.gcode

I think modifying the stock print profiles in certain ways may affect the curve fitting.

@bot I agree, fitting after the fact is not optimal but it is a step in the right direction. Probably leverage existing code from their CAM workspace to make it work.

@Phaedrux @arhi Scratch that, those additions aren't quite enough. Using the Prusa post however does generate G3 moves! It cut a roughly 1100kb file to around 500kb. Still trying to get the 'rrf' post to function correctly

@Phaedrux @arhi @littlehobbyshop

Look for this line in the RRF post processor (or your own custom one):

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

Beneath that, copy and paste this block:

// used for arc support or linearization
tolerance = spatial(0.002, MM); // may be set higher i.e 0.02?
minimumChordLength = spatial(0.25, MM);
minimumCircularRadius = spatial(0.4, MM);
maximumCircularRadius = spatial(1000, MM);
minimumCircularSweep = toRad(0.01);
maximumCircularSweep = toRad(180);
allowHelicalMoves = false; // disable helical support
allowSpiralMoves = false; // disable spiral support
allowedCircularPlanes = 1 << PLANE_XY; // allow XY circular motion

And farther below that, in the functions section, paste this below the onLinearExtrude function.

function onCircularExtrude(_clockwise, _cx, _cy, _cz, _x, _y, _z, _f, _e) {
  var x = xOutput.format(_x);
  var y = yOutput.format(_y);
  var z = zOutput.format(_z);
  var f = feedOutput.format(_f);
  var e = eOutput.format(_e);
  var start = getCurrentPosition();
  var i = iOutput.format(_cx - start.x, 0); // arc center relative to start point
  var j = jOutput.format(_cy - start.y, 0);
  
  switch (getCircularPlane()) {
  case PLANE_XY:
    writeBlock(gMotionModal.format(_clockwise ? 2 : 3), x, y, i, j, f, e);
    break;
  default:
    linearize(tolerance);
  }
}

Those are the only differences I can currently see between the generic FFF post processor and the Prusa post processor.

Note: I still have not tested this yet. Also, it may be worth looking in to the variables defining circular moves, i.e. minimumChordLength and seeing what those may change.

@Phaedrux Not quite sure, as I haven't tried to use it yet (was planning on later today). Hoping it's easy enough to reconfigure the Prusa post-processor for a Duet compatible output while retaining arc support.