Slicing G-Code curves from solid (not mesh) geometry.
-
I'm back and forth in Fusion and Cura constantly when doing prototypes and I can't say the workflow has been an issue. Export STL, import and slice, send to Duet. Frankly it's a breeze compared to the obtuse setup of Fusion. The slicing is very slow as well, and cura isn't exactly fast. The gcode produced isn't anything to write home about. Pretty basic. Lacks a lot of the finesse options of Cura. Dealing with corner cases becomes the most important thing in my opinion. There's nothing there yet that could convince me to switch over to it, and I really don't think they have the commitment and depth of talent there to make it into a true competitor for the existing slicers. But who knows. If they give it the same attention they have given to CAM, there might be a time when it becomes pretty powerful. And I guess anything is possible with the post processing?
-
what he said (except less doubt about talent, but more so on comittment)gimme true arcs and we'll talk
-
Effort would probably be better spent moving away from vectors and to nodes. Have a few different classes of node such as a corner (or must hit) node and path nodes (with a variable must be within x). Then let the controller do the per machine settings rather than the slicer too far away from the coal face.
-
...of course what I have just described is one node with a value of 0 or something else...
-
Interesting and they added 3mf export (unfortunately only in the Manufacturing space)!
And I like this support structure:
-
@OBELIKS The support structures were hard for me to understand on a complex model. I had to walk away and laugh, because I thought it was outputting garbage. Seems the supports are trying to "anchor" down edges -- I suspect these supports are lifted directly from Netfabb, but I don't know I've never gotten results from Netfabb in the trial period they gave me.
-
In this case it is trying to support the circle above with minimal waste. It is looking at bridges and making them shorter than a value.
-
Just posted...
https://www.youtube.com/watch?v=Yd0l2ZOQQek -
@gtj0 said in Slicing G-Code curves from solid (not mesh) geometry.:
Just posted...
https://www.youtube.com/watch?v=Yd0l2ZOQQekOoof. They make it look so easy to use!
-
@Phaedrux said in Slicing G-Code curves from solid (not mesh) geometry.:
@gtj0 said in Slicing G-Code curves from solid (not mesh) geometry.:
Just posted...
https://www.youtube.com/watch?v=Yd0l2ZOQQekOoof. They make it look so easy to use!
Yeah. I'm actually in the process of trying print. If I can get back to stable RRF3 release that is.
-
I gave it a go earlier with prusa/generic FFF settings. Print came out pretty nice, can see some slight Z banding which may just be my printer/filament (shows up more in the photo due to very bright LED light above the printer)
Found it a bit of a pain to setup and had no indication of print time or a good way of seeing what speeds at different parts of the print. Found it interesting it seems to move in the Z axis while bridging too, not sure what it was trying to achieve with that.
Edit: Also, I had to download an additive post process settings file, I just used the prusa one. https://cam.autodesk.com/hsmposts
-
Just looked at the video and it looks quite logical once you have enough information to wrap your head around it. Although it likely isn't ready for prime time yet, I must say that I am surprised at how fully featured it is for their first kick at the cat!
Maybe another upgrade or two and then it will just be a matter of spending some time to get used to the different user interface. -
Well, it does need work but the Fusion 360 team is usually good about taking feedback.
The post processors are just scripts and easy to modify which is good news because the metadata they write isn't really RRF compatible and there are some things that it does that aren't really wanted, like automatically homing.
