Thank you everyone at Duet3D, here on the forum and in the greater RepRap community. I started working on an idea for a Cartesian printer in January 2016. I finally printed the first thing on it today, and I couldn't have done it without the work, commitment, and help from everyone!
Especially, thank you DC42 for the ongoing development work on the main branch of the firmware. It's amazing.
Now the fun part begins: tuning and tweaking the prints.
@bberger I have submitted a Pull Request to PrusaSlicer to include those integrations: https://github.com/prusa3d/PrusaSlicer/pull/8087
I just finished modifying PrusaSlicer to have more precision and remove some silly flow math that was just adding noise to the GCode. Check it out, let me know what you think!
The main benefits are that toolpaths won't be simplified as much, which results in the complete elimination of misaligned layers segments, E values in GCode will be output to 6 decimal digits of precision instead of 5, and the aforementioned removal of Slic3r flow math.
[Edit: Update! Fixed extrusion rate inconsistency in latest version, link below updated to newest release. See my post here.]
Release (Win64 binaries only, sorry) (updated link to fix for changed tag/updated release)
Github Repo (default branch).
@oozebot I might have incorrectly assumed it was in the latest beta. It's in the 2.5.0 alpha0 (master branch) which they have not released yet.
It's included in my latest release from yesterday: https://github.com/n8bot/PrusaSlicer/releases
Also included in that release is the ability to get machine limits from the configured duet printer host. Also, improved print time estimates.
Credit where it is due, I was not the first: https://forum.duet3d.com/topic/4193/icesl-printer-profile?_=1590196676685
This is my first coding project, so please explore it with a heavy amount of scrutiny.
IceSL is a pretty neat slicer that has some incredible features. It also allows total customization of GCode output with LUA scripting. See below excerpt from my README.
RepRapFirmware Configurable Printer Profile (Addiform_RRF) for IceSL
- [x] Created on 2020-APR-20 by Nathan Buxton for Addiform
Addiform_RRF adds the following features:
- Support for firmware retraction.
- Support for volumetric extrusion.
- Support for relative extrusion.
- Compatibility with RRF tool changes.
- RRF-specific GCode output.
- S3D output emulation for toolpath visualization and print info formatting.
IceSL is a state of the art slicer (STL → G-code) with advanced modeling capabilities.
IceSL has the following novel slicing features, and more:
- Variable layer-height optimization.
- Geometry-based print setting modifiers.
- Paint to specify seam locations.
- Advanced tree-like support structures.
- Supports based on toolpaths, not only meshes.
- Paint to specify support locations.
- Hollow prints with self-supporting cavities.
- Advanced and experimental infill options:
- Progressive infill patterns that can smoothly vary in density along height.
- Cubic, Tetrahedral and Hierarchical infills.
- Ability to create custom infill types.
- Active temperature control, which ensures tools are heated and cooled just in time for their use.
- High-precision slicing with controllable simplification.
- Minimum layer time, with customizable wait GCode.
For more information about IceSL:
These aren't perfect, but they are the first prints I've tried at ridiculous resolution on my newest printer.
They are printed in PLA on an FDM printer, with a Duet 2. The mini face is 1/6th scale head scan with millions of polygons... there is an exaggerated amount of detail added to the mesh to provide "pore data" for the print, hence the bumpiness. It is printed at 25 micron layer heights with a 0.25 mm nozzle. The tower is printed with the same nozzle and extrusion width but with 40 micron layers, it is 20 mm x 100 mm x 0.25 mm (wall thickness). I'm printing straws at this point (at the same time the world is banning them! lol).
I just made a breakthrough! I've been chasing my tail trying to fix the inconsistency in the extrusion rate produced by the E values in combination with the X/Y values in GCode.
I spent weeks debugging, tracing values, determining that everything was working basically perfectly. What was going wrong!?!?
The X/Y vectors were being rounded AFTER the calculation of extrusion amount. Therefore, the calculated extrusion amounts were no longer valid. Funnily enough, the fact that there was excess precision to begin with WAS the problem. The solution, for this build, is simply to increase the X/Y GCode decimal precision to 6 places. Now, by far, the most consistent extrusion rates I've seen! No more random infill segments with sudden rising extrusion rates.
Stiffness != strength. Stiffness is just the slope of the stress/strain curve: ie, how resistant to bending it is.
This would fail at a much lower stress than the steel sample. It would simple resist bending to the same degree as the steel (before the PLA breaks). The steel would not break at anywhere near the stress levels the PLA would.
I will begin work shortly preparing a rudimentary minimally-viable custom PrusaSlicer build to support concurrent printing of multiple objects. So far, the plan would be to copy and modify the sequential object printing feature to interleave the two object g-codes instead of outputting them sequentially. M596 and M400 would be emitted when needed. Is there anything else that would be required or helpful to get started testing this? At first, time estimates and other helpful features would not work.
The T word of M207 refers to the unretract speed, not the tool. You have set your unretract speed to 0 mm/min, then again to T2400. I do not know how problematic that is, but it's not correct. You should put P0 to refer to tool 0.
https://duet3d.dozuki.com/Wiki/Gcode#Section_M207_Set_retract_length
@r4ffers Did you try this print with different E jerk/accel?
@r4ffers Make sure your slicer start gcode doesn't disable PA. Check every .g file on your SD card, too.
@r4ffers One thing I would try if I were you would be to increase the E jerk a little, and drastically decrease the E acceleration. You never need that much E accel. It becomes completely pointless -- essentially no E acceleration is ever applied because there are not enough steps to interpolate speeds across.
Try E Jerk 500 and E Accel 2500.
@mortarart Sorry, I meant the parts that are attached to the stepper. You have to ensure that the stepper will actually stall, and not just damage everything in its path.
AFAIK this is totally fine and there is zero chance this will damage the electronics. You could reduce current while doing so to make sure no mechanical damage is possible.
DC42 had technical reasons for choosing the placement. There was already concerns that it was not fully contained close enough to the beginning of the file. I think if the thumbnail is at the end the performance of loading it would suffer dramatically? I forget.
@ccs86 sadly this is why I've not yet tried IS. All my prints are highly segmented to the point that IS would seldom play a role.
Sounds like I should try Cura 5.0!
@v3dprinting what is your nozzle diameter set to under printer settings?
IIRC, PrusaSlicer has different behaviour if the extrusion width <= nozzle diameter
Perhaps, increase the default extrusion width to .42 or .45. Otherwise, PrusaSlicer might be choosing different weird values for you (I forget the exact behaviour, but PrusaSlicer likes to do lots of things).
@v3dprinting I was not aware of elephant foot compensation on S3D. Are you manually creating that by using multiple processes?
Also, PrusaSlicer defaults like to have weird extrusion widths and layer heights for the first layer. Triple check that there is not some funny setting somewhere you didn't expect. Use explicit widths instead of percentages, and don't leave any extrusion widths blank otherwise Prusa will automatically choose a weird number for you. Make sure your nozzle is set to the right size too. In some of those auto-selected width cases, prusa uses the nozzle width to determine things.
