Lulzbot Mini V1 Duet Conversion



  • MVIMG_20200819_213848.jpg

    My Aleph Objects Lulzbot Mini V1 (such an unfortunate name) finally got some much needed upgrades. Managed to squeeze a Duet Maestro into the original housing and carefully filed some new cutouts for the ethernet and SD card. Also, got a V1 aerostruder at a slight discount, as they're being discontinued.

    Haven't used DWC/Duet since 2018, so I'm still working out some old GCODE habits, and trying to nail down the best pre-print/post-print macro setup, but she prints, and shes quiet at long last. No more serial tether, no more always on fans, it's amazing. I know Aleph Objects printers are already kinda expensive, but adding a duet really completes the professional look and feel of the printer while keeping the open source roots. I just wish they shipped with one.


  • administrators

    @pungoboy, thanks for sharing! I see that there are already several threads in the lulzbot forum (https://forum.lulzbot.com/) about converting the Lulzbot machines to Duet, although not the Mini. Perhaps you will add one?



  • I was planning on sharing some of my process and settings as soon as I get most of the kinks out, I will definitely cross-post to the Lulzbot forums. Still tweaking the startup macro to match the original firmware's wipe and probing sequence while making it less Cura-dependent. For instance, Cura would set the wiping and probing temps separate from the printing temps using Cura exclusive variables. My hope is to replace that with the filament macro functionality, so the standby temp is the probing/wiping temp for the loaded material and active temps are for printing.

    The original firmware also had some kind of baked in work coordinate offset, as the official printable area is 158x158 but the sensor disks and wiper are well outside of that, so I'm working that into Duet's G53-G59 system. Could just offset in the slicer but when I'm done I'd like the printer to be as slicer-agnostic as possible, since I change slicers more often than I should.


  • administrators



  • @dc42 I am doing it like this, currently:

    G90			; abs position
    G0 X5 Y5		; rapid to X5 Y5 (just off the sensor disk)
    G10 L20 P3 X0 Y0	; set this position as the origin of coordinate system 3 (creating hard printable area)
    G56			; set coordinate system 3
    M208 X156 Y156		; set new axis limits for print duration
    

    This way, the slicer can still behave as if interacting with a printer whose printable area is from X0 Y0 to X158 Y158 with no special offsets. When the printer is in machine coordinate mode, X0 Y0 ends up right on top of one of the sensor disks. The end/cancel macros put it back to machine coordinates and reset the axis limits, which I measured to be X165 Y180 Z163. Would love any input on making this simpler, but to me it seemed like the best way to avoid special tool/work offsets in the slicer.

    I suppose another option would be to default to the "printable" coordinates in config.g and only change to the "true" machine size coordinates in the macro for wiping the nozzle or doing the bed leveling, but to me it feels like six one way, half dozen the other.


  • administrators

    I suggest you read the link I gave you and use appropriate negative X and Y lower limits so that machine coordinates match the ones you want to use in the slicer.



  • @dc42
    Ah, I had overlooked the part about negative coordinates being allowed as minima, that is definitely an easier method for defining the print area. Thanks.


Log in to reply