Started a new thread as the other got swamped with comments on licensing.
My post-processor has been updated to include arc support (G2 and G3 commands) to make use of the feature added to Fusion in the last update.
There are various options in Fusion that have to be enabled to allow this feature to work, see the following video https://youtu.be/aggdtzpNrPw?t=185
Check the readme for usage and other functions.
I posted my post-processor. You can find it here:
https://github.com/LittleHobbyShop/RRFPostProcessor
Thought I'd share here that Fusion 360 March update brings FDM/FFF slicing in the Manufacture environment.
https://www.autodesk.com/products/fusion-360/blog/march-2020-product-update-whats-new/
It's sparse at the moment but usable. I have managed a quick test cube. There are plenty of settings available but obviously it's just the start and there are omissions and probably bugs too.
The most difficult part for me was start and stop gcode, it's not available in the format we're used to yet. It can be adjusted via the already existing post-processor system in Fusion but it's not easy. I'm sure this will change in time given the number of FFF users that will try this and we'll have the usual textboxes before long. Likewise, there are no entry points for layer change or tool change scripts.
Fortunately, thanks to RepRap Firmware this will be easier to overcome than any other system I'm aware of. Almost all of my start and end scripts are already in firmware on the Duet board and I used an existing post-processor for the BigRep (found in the Fusion 360 post library) and tweaked it.
So, if you intend on having a go with this, get moving your start and end routines from your slicer into the start.g and stop.g files in RepRap Firmware and add M0 to your end script in the slicer.
I'll have another look at the tweaked post-processor I used and see if I can clean it up enough to share here. Caveat, I've never written a post-processor before so downloader beware!
@dc42 I think this post needs deleting and updating
Workaround for disabling generated toolpath control of extruder and bed heaters. Enable Heater Control (Default: Yes) decides whether the slicer should include commands to control initial warmup of the extruder and bed, followed by shut off at completion of the print. Enable for simplicity, disable if you want to use other methods (eg. the filament system) to control extruder and bed temps. The post-heat macro property remains but is not necessary if heater control is disabled, in that case any methods that would otherwise go here can be moved to start.g.
Re-instated M0 H1 at end of print
Right now this is probably as far as I can go functionality wise. the idea was always to strip out any excess gcode commands and so far that has been done so it will stay as it is until the next Fusion update or they release more documentation.
I think you need to set your R value in M453 to your spindle max. Expected frequency for your controller is 1-3KHz so F needs to be between 1000-3000.
PWM control is on the duty cycle of the wave not the frequency, frequency stays constant once you've set it.
M453 is set once then speed changes done with M3.
M453 C"out9" R12000 F2000
M3 S12000 ;Should get 10V
M3 S6000 ;Should get 5V
I posted my post-processor. You can find it here:
https://github.com/LittleHobbyShop/RRFPostProcessor
Added post-processor properties
@gtj0 Unfortunately adding H1 to M0 is pointless at the moment, the heaters are turned off automatically by the toolpath generator at the end of the routine which can't be edited. Much like the purge line. There may be a workaround, I'll keep at it.
Update 26/06/2020
Added a fan speed property. Fusion currently only presents a setting to disable the fan for the first few layers, for the rest the fan will run at 100%. This setting lets you change that value.
Assuming everything else you've printed to date is in the correct orientation and not mirrored. I'd say you have the model mirrored in the slicer. Does the preview in the slicer look correct? If not, flip along either x or y, not both.
Take a look at this: https://github.com/DanalEstes/MultiDuetWebMonitor
This and other community projects here: https://duet3d.dozuki.com/c/Community_Projects
@t3p3tony for me, per drive would be best independent of the mix ratio. I think retraction as per the mix ratio doesn't really allow for difference in material properties that would affect retraction.
I'm mixing a paste with a pigment. So I have the paste in a large syringe and it has a very different viscosity to the pigment. The pigment is in a much smaller syringe and I would want to avoid retracting that more than absolutely necessary so that I'm not pulling paste up into the pigment. I hope that adds some context.
@jay_s_uk I'm aware of that. As per the title I have multiple extruders on a single tool for mixing using M567 mix ratios.
It would be great to have independent control of retraction of each extruder on a tool. My application for this is a mixing paste extruder. My extruders have very different characteristics and could really do with different retraction settings, looking through the documentation before the build this appeared to be possible but I obviously misread/misunderstood.
In the object model "retraction" seems to belong to the tool rather than the extruder which I find a bit odd as it is a movement exclusive to an extruder.
So I'd really like to be able to use something like the following
M207 P0 S0.5:0.8 F600:120 Z0:0.5
OK, so have quickly checked on the Duet2 Wifi. Same behaviour.
I did find this reference https://forum.duet3d.com/post/265794
Where the M200 behaviour is described as resetting to linear extrusion when a print file starts. I did another check with a macro and found that M200 volumetric extrusion only lives as long as the macro itself. It's unexpected behaviour tbh but appears to be deliberate and the same is being applied to the tool change macros.
Macro looked like this:
M200 D1.75
M200
Which resulted in this console output, the first M200 being manually sent via the web console.
I'm not able to test yet but it would seem if you're wanting to run a volumetric extrusion job and have tool changes, you might have to call M200 after each tool change? Or perhaps it persists because the tool change is being called as a "sub macro" of the print file? I don't know, if it's documented somewhere I can't find it.
This behaviour needs documenting in the GCODE Dictionary really. Since the move to WikiJS I'm not sure how to contribute.
@jay_s_uk I have a Duet2 Wifi machine so will check on there also, also running 3.3. Might be helpful, should've thunk of that earlier! Will move to the discord if it's not a problem on the Duet board.
@jay_s_uk OK, I might give it a try this weekend but there's no changes listed to M200 in the changelog
@jay_s_uk Thanks I did check that yesterday and considered it but it's still listed as an unstable build and I'm mid build on this slightly experimental machine so was a bit wary of throwing possible firmware problem shenanigans into the mix.
I'm going to have to update soon though I'm going to need the tool independent retraction update to M207.
@phaedrux Sorry, missing the basics. I'm on 3.3 at the moment, due to it being the STM32 version from TeamGloomy running on a BigTreeTech GTR. Latest release from them. It's a self build paste extruding machine (syringes).
M200 is applying when run within a macro or from config.g. So far it seems only the tool change files are the issue.
I am trying to set filament diameter in either tpre or tpost files. Neither actually sets the filament diameter and sets volumetric extrusion. When I run the same command in the web console, it applies just fine?
@thekm That script is fantastic! Works a treat for me. Please create a post of it's own if you haven't already.
Edit: Oh you already did. Very nicely done!