Duet3D Logo

    Duet3D

    • Register
    • Login
    • Search
    • Categories
    • Tags
    • Documentation
    • Order
    1. Home
    2. poofjunior
    • Profile
    • Following 0
    • Followers 4
    • Topics 15
    • Posts 47
    • Best 11
    • Controversial 0
    • Groups 0

    poofjunior

    @poofjunior

    40
    Reputation
    27
    Profile views
    47
    Posts
    4
    Followers
    0
    Following
    Joined Last Online

    poofjunior Unfollow Follow

    Best posts made by poofjunior

    • Jubilee Kits are live!

      Hey folks,

      At long last, Jubilee kits are now live and available through Filastruder!

      If you've ever wanted to explore toolchanging with a hacker-friendly platform that's ripe with customization potential, I hope that kits make Jubilee a fair choice in the bold new frontier of toolchangers. Jubilee is especially ripe to provide you with an ecosystem for designing your own tools, complete with a parametric solution for parking tools and the specs needed to make them fit.

      The kit takes everything you need to build the motion system, QCs it, and puts it into a box. That includes all the wiring (pre-crimped and labeled!), and even the assembly tools too (minus the soldering iron for inserts).

      In the next couple months we'll try to do the same with tools, but for now, this dramatically streamlines the build.

      Jubilee was 3.5 years of my work in grad school, and I'm thrilled that I get to share it with folks this way. Along the way, folks on Discord who built the project from source have battle-tested and improved it over the years. The Jubilee that's kitized today represents the latest-and-greatest as far as what we've learned as a community from playing with it.

      Finally, Jubilee simply wouldn't exist without the ecosystem of people who keep it afloat. That's a combination of the machinists making Jubilee's more complicated parts, the printer veterans producing the printed parts, and the vendors who have adopted Jubilee parts along the way to make the project a little easier to source. This kit was a collaboration with many of them; it wouldn't make sense to do it any other way!

      In part, through the serendipity of meeting Tony Lock at MRRFs and ERRFs back in 2019, Jubilees have been Duet-powered since pretty-much the start of this adventure. And with all the other things that can go wrong with toolchangers, it's nice to not have to worry about overheating motor drivers or underspec'ed connectors. Duet also made adding the toolchanging feature a breeze. (Far simpler, I admit, than when I was modifying custom firmware on other boards to make it happen.) Thanks a bunch to the crew moving the electrons in the right places at the right times!

      Cheers--and happy hacking!

      Project Page: jubilee3d.com
      and Machine Pics for the curious!

      posted in My Duet controlled machine
      poofjunior
      poofjunior
    • Duet + Jubilee + Instruments = Science!

      I'm building out an automated sonication work cell for a lab at school, and I wanted to share some of the more fun bits!

      For starters, I started with a Jubilee 2.1.x. The bed plate has been retrofitted for holding well plates with a laser cut fixture and some (no joke) battery clips from Digikey.
      IMG_20200822_153448.jpg

      Then I added two tools: a downwards facing camera and the sonicator.
      cubilee_tools_resized.png

      Next came the software. I couldn't drive the sonicator and camera with GCode directly, so I wrapped the HTTP interface in Python to get easier access to the custom tool commands. Since the tools don't need to be active while the machine is moving, this ends up working out.

      The camera is for dialing in the location of the well plate using the centroids of the 3 corner wells. (Doing this manually for now keeps the machine flexible enough to accommodate oddly shaped custom plates.) The sonicator is for zapping samples with ultrasonic vibrations. (Apparently this breaks down cell walls and DNA and makes it easier for scientists to measure some of the more rudimentary components. Honestly, I wish I could say more here, but I just the machine designer!)

      Here's the machine in all it's glory:
      IMG_20200822_154138 (2).jpg

      and... here's the dry run where the sonicator gets picked up and cycles between well plates and cleaning viles.
      https://www.youtube.com/watch?v=aem-JLtchbI

      I thought this'd be a fun share to showcase just how much you can do with a Duet with an extra layer of abstraction or two. In a nutshell, the Duet folks have done a fantastic job exposing interfaces to build robots of all kinds on top of their work, not just printers and cnc machines. I'll slowwly get the bed CADs on the Jubilee wiki if anyone wants to try some other sample handling mischief.

      posted in My Duet controlled machine
      poofjunior
      poofjunior
    • RE: Danal's passing

      This is heartbreaking news, but thanks for sharing.

      Danal and I only interacted online over the last 6 months, but he certainly left his footprints behind on my work in ways that really kept me going.

      Danal was the first person I know of to build a Jubilee and join the Jubilee Discord. When I kicked the files online back in September, Danal was the first person to find bugs and improvements for the documentation. In the months that followed, Danal took Jubilee and the rest of the community with him to a whole different level of capability by writing TAMV, a machine vision add-on enabling automatic tool offset alignment using an upwards facing webcam.

      But let's forget about project contributions for a second. Danal was the first one to jump onto Jubilee Discord, and his discussion points was always sincere. And he became one of the chattiest community members, answering a multitude of first-timer questions and setting the tone for a warm discussion where new folks can learn from experts in a laid back session of IRC. In the tough world of online discussion forums, some earnest, light-hearted chat is hard to come by, but Danal was the one who set the tone for that. It was incredibly refreshing to engage with Danal online. Through his sincerity and responsiveness, it was like he believed that people would put their best feet forward if you did the same first.

      I will miss a ton of things about this guy. I'll miss his transparency, his willingness to solve a problem and then share a well-formed solution online in code. I'll miss his kindness, how he always tried to meet folks where they were at in answering their questions. And I'll certainly miss his excitement for this stuff. Seriously, Danal was one hell of a great human beings to have hanging around these parts of the internet with us. It's going to be tough without him, but I think it's on us to keep echoing some of his character in the stuff we do here.

      posted in Off Topic
      poofjunior
      poofjunior
    • Notes on a possible Input Shaping Implementation

      Hey folks,

      I would love to see input shaping implemented on the Duet. So I read-up on the math and took notes on how to do it fast on standard resource-constrained hardware. In a nutshell, I wanted to really "see" what was happening to the position signal when we apply input shaping to it.

      My "crash-course" notes on the math are here:
      https://github.com/Poofjunior/input_shaping_notes/blob/main/input_shaping_and_modifying_kinematics.ipynb

      In short:

      • Input Shaping requires running all position curves through a convolution with a special impulse sequence signal.
      • The impulse sequence signal requires measuring the natural frequency for each axis. Printer owners will need to run some sort of "self-test" routine with an accelerometer to collect the machine's impulse response.
      • Convolution is a pretty resource-intense operation, but since our second signal is an impulse sequence, the math simplifies dramatically and is actually pretty fast.
      • Technically, we're convolving our impulse sequence with our acceleration signal, but it turns out that it's equivalent to convolve the impulse sequence with either velocity or with position, so convolve with whatever's convenient.
      • because our position signal is convolved with an impulse sequence, it's impractical to solve for the inverse function (i.e: time as a function of position) analytically. But an iterative solver really shines here.

      I'll bet you'll get a lot of requests for this feature in the future, so I hope this helps the folks doing firmware digest what's actually involved in coding it up!
      (And if someone wants to point me to where in RRF that step times are being calculcated, I might just give this a go in a few months.)

      Finally if you have any questions on the math, feel free to reach out!
      Cheers!

      posted in Firmware wishlist
      poofjunior
      poofjunior
    • RE: Kit Recommendation: Two Materials 300x300

      @auser Looks like I'm getting to this one a bit late, but a kit for the frame has been in the works via Filastruder, and we're almost done aggregating everything. Our target is end of this month (Jan), which feels a bit surreal, since we've been at this for a good ten months now.

      The kit should totally eliminate the need for making your own wire harnesses, come with all the assembly tools except a soldering iron for installing the heat-set inserts, and leverage a Duet3 Mini + 3HC Expansion with 2 drivers to spare for tools by default. (There's also a hole mounting pattern for 2 additional 3HC boards.)

      Along the way, I totally revamped the default extruder tool to be Orbiter-based with support for the 1.5 and 2.0, and then support groovemount heatsinks, threaded heatsinks, and v6 and v7 heads, not to mention a bunch of clones. It also sports dual 5015 fans. More info on the Baby Bullet here, but the folks who've built one or modified one seem to be really happy with it.

      I totally acknowledge that building Jubilee is lots of work, but hopefully this will get folks much further out faster.

      Cheers--and have fun on your build--whatever platform you pick!

      posted in General Discussion
      poofjunior
      poofjunior
    • Standalone Config Snippets

      One of the quirks about multi-tool setups is that we can't readily add/remove standalone config.g snippets without editing the main config.

      That has to do with some config-related interdependence of commands. Here's an example.

      M584, which sets the drive mapping, requires that you declare all extruder drives at once like this:

      M584 E3:4:1.0:1.1
      

      Running M584 later in the config (let's say, to add a new tool), requires you to take what was already there and append to it manually like this:

      M584 E3:4:1.0:1.1:1.2
      

      This interdependence prevents you from adding config snippets to add/remove a tool without modifying the main config. The result is that you have to know in advance how many tools you have or will ever have. The other quirk here is that electronics setups may differ on multitool setups--even on machines with well-defined electronics options like Jubilee. Someone might use Duet3 with toolboards while someone else uses the 3HC's. I would love to know if there's a way to dynamically offer standalone snippets of tool-related config.g's without requiring that folks edit the main config.

      So here are my questions.

      1. for folks tweaking their machines often (like for multitool setups), does any sort of read-modify-write syntax exist? Something like:
      curr_m584 = M584
      curr_M584:1.2
      
      1. Is there any effort to make dynamic config generation for swapping tools any simpler using resources of the optional Raspi?

      Cheers--and thanks!

      posted in Using Duet Controllers
      poofjunior
      poofjunior
    • Additional Machine State Variables in the Push/Pop Container

      Duet has an awesome feature to snapshot the state of the machine, alter the machine state, and then restore it from the snapshot (M120 and M121: Push and Pop. It looks like only a subset of the machine state is captured though. Would it be possible to capture other motion-related state variables too, like those that specify acceleration values?

      Here's the use case: in a multitool setup, we can use the toolchange macros to alter the tool-less machine state when a particular tool is loaded. If it's a slightly heavier tool, we could reduce the acceleration values with M201. Upon releasing that tool, the prior acceleration values would be restored.

      posted in Firmware wishlist
      poofjunior
      poofjunior
    • RE: Kit Recommendation: Two Materials 300x300

      @auser There's no EU distributer for a kit now, but folks building Jubilees in the EU usually go to HighTemp3D for parts. I'd be open to looking for more folks willing to do kits.

      I totally acknowledge that shipping costs add up. Test driving a kit in the US is one way to help solve that issue, but not the last. Baby steps!

      And I'll gladly post an announcement when kits go live if I'm allowed to do some self-promotion!

      posted in General Discussion
      poofjunior
      poofjunior
    • RE: Duet + Jubilee + Instruments = Science!

      Thanks for the support, folks! This is a nearing-completion work-in-progress, but the plan is to make all reusable bits of this project (CAD files for the bed, python library for motion) shareable so that other folks have a starting point for similar non-printing mischief.

      @T3P3Tony said:

      Would be great to catch up in more detail at some point about generic plugins/libraries to streamline this for wider use cases.

      Aye--that'd be great. All that feedback from other threads really helped! For now, I swapped from DSF to HTTP to be able to let the same code command Duet2 and Duet3 setups. Longer-term, I'll probably make the interface selectable in the class constructor so that folks can pick either DSF or HTTP. Currently doing a light code overhaul so that the sonicator and motion control sections of the code can exist as separate projects with the duet motion interface being pip-installable.

      Thanks again for all the hard work on the Duet side, and more actions shots may follow!

      posted in My Duet controlled machine
      poofjunior
      poofjunior
    • Boilerplate HTTP connection code for Python-based UI

      Hi folks,

      I'd like to write a python-based that emulates the web behavior of being able to:

      • poll the state of the machine
      • send over simple GCode commands or entire files.

      First off, are there leads on doing this already? I'm super new to web programming, but I want to adhere to best practices for interacting with the exposed network-based API. From what I've read, I should be connecting to the Duet via websockets, not via http polling.

      I started by opening up dev-tools in my browser on DWC's main page, I was able to track down the connection on this URL:

      http://192.168.1.2/rr_connect?password=reprap&time=2019-10-30T17%3A29%3A0

      (My Duet has a static IP for now.) It looks like a password, date, and time are encoded too.

      Pasting that URL into a connection from Python's socketIO library throws a 404 with this code, though:

      import socketio                                                                                                            
      sio = socketio.Client()                                                                                                    
      sio.connect("http://192.168.1.2/rr_connect?password=reprap&time=2019-10-30T17%3A29%3A0")
      

      However, using vanilla HTTP Requests with Python works flawlessly:

      import requests                                                                                                         
      params = { "password": "reprap",
                 "time": "2019-10-30T17:29:0"
               }
      r = requests.get("http://192.168.1.2", params=params)  # this works!                                                                              
      r = requests.get("http://192.168.1.2/rr_status?type=1")  # this also works!                                        
      print(r.json()) 
      

      What do folks recommend? I could simply setup a thread to poll the machine state and send GCode from the main thread using the Python requests library. Is there a better approach?

      Thanks for taking a look and offering suggestions!

      Finally, it looks like others have visited this topic before, but the conversation ended without any leads:
      https://forum.duet3d.com/topic/441/web-ui-native-wrapper

      I also referenced the Duet Web UI code, but I'm not a web programmer by trade.

      posted in Duet Web Control python web ui python ui websockets
      poofjunior
      poofjunior

    Latest posts made by poofjunior

    • RE: Jubilee Kits are live!

      @arnold_r_clark none have reached out to me (or appeared to my knowledge), but I'll be sure to update the wiki and such if one does.

      I'll admit that getting everything into kit format was quite some work. Anyone outside the US looking to sell some might find that one way to get started could be a possible collab with the folks at Filastruder.

      @zapta thanks for the note! Link is now up-to-date!

      posted in My Duet controlled machine
      poofjunior
      poofjunior
    • Jubilee Kits are live!

      Hey folks,

      At long last, Jubilee kits are now live and available through Filastruder!

      If you've ever wanted to explore toolchanging with a hacker-friendly platform that's ripe with customization potential, I hope that kits make Jubilee a fair choice in the bold new frontier of toolchangers. Jubilee is especially ripe to provide you with an ecosystem for designing your own tools, complete with a parametric solution for parking tools and the specs needed to make them fit.

      The kit takes everything you need to build the motion system, QCs it, and puts it into a box. That includes all the wiring (pre-crimped and labeled!), and even the assembly tools too (minus the soldering iron for inserts).

      In the next couple months we'll try to do the same with tools, but for now, this dramatically streamlines the build.

      Jubilee was 3.5 years of my work in grad school, and I'm thrilled that I get to share it with folks this way. Along the way, folks on Discord who built the project from source have battle-tested and improved it over the years. The Jubilee that's kitized today represents the latest-and-greatest as far as what we've learned as a community from playing with it.

      Finally, Jubilee simply wouldn't exist without the ecosystem of people who keep it afloat. That's a combination of the machinists making Jubilee's more complicated parts, the printer veterans producing the printed parts, and the vendors who have adopted Jubilee parts along the way to make the project a little easier to source. This kit was a collaboration with many of them; it wouldn't make sense to do it any other way!

      In part, through the serendipity of meeting Tony Lock at MRRFs and ERRFs back in 2019, Jubilees have been Duet-powered since pretty-much the start of this adventure. And with all the other things that can go wrong with toolchangers, it's nice to not have to worry about overheating motor drivers or underspec'ed connectors. Duet also made adding the toolchanging feature a breeze. (Far simpler, I admit, than when I was modifying custom firmware on other boards to make it happen.) Thanks a bunch to the crew moving the electrons in the right places at the right times!

      Cheers--and happy hacking!

      Project Page: jubilee3d.com
      and Machine Pics for the curious!

      posted in My Duet controlled machine
      poofjunior
      poofjunior
    • RE: Kit Recommendation: Two Materials 300x300

      @auser There's no EU distributer for a kit now, but folks building Jubilees in the EU usually go to HighTemp3D for parts. I'd be open to looking for more folks willing to do kits.

      I totally acknowledge that shipping costs add up. Test driving a kit in the US is one way to help solve that issue, but not the last. Baby steps!

      And I'll gladly post an announcement when kits go live if I'm allowed to do some self-promotion!

      posted in General Discussion
      poofjunior
      poofjunior
    • RE: Kit Recommendation: Two Materials 300x300

      @auser Looks like I'm getting to this one a bit late, but a kit for the frame has been in the works via Filastruder, and we're almost done aggregating everything. Our target is end of this month (Jan), which feels a bit surreal, since we've been at this for a good ten months now.

      The kit should totally eliminate the need for making your own wire harnesses, come with all the assembly tools except a soldering iron for installing the heat-set inserts, and leverage a Duet3 Mini + 3HC Expansion with 2 drivers to spare for tools by default. (There's also a hole mounting pattern for 2 additional 3HC boards.)

      Along the way, I totally revamped the default extruder tool to be Orbiter-based with support for the 1.5 and 2.0, and then support groovemount heatsinks, threaded heatsinks, and v6 and v7 heads, not to mention a bunch of clones. It also sports dual 5015 fans. More info on the Baby Bullet here, but the folks who've built one or modified one seem to be really happy with it.

      I totally acknowledge that building Jubilee is lots of work, but hopefully this will get folks much further out faster.

      Cheers--and have fun on your build--whatever platform you pick!

      posted in General Discussion
      poofjunior
      poofjunior
    • RE: [3.3] 6HC+3HC+SBC Stuttering Motion on Small Contiguous Segments

      And it looks like switching to 3.4beta3 has totally fixed the stuttering! Thanks a bunch for the hand folks!

      posted in Tuning and tweaking
      poofjunior
      poofjunior
    • RE: [3.3] 6HC+3HC+SBC Stuttering Motion on Small Contiguous Segments

      @deckingman I tried bumping jerk up to 3000mm/min before posting since that's what I suspected also.

      @Phaedrux can do! (Yeah, this config confuses me too. I'm open to structural feedback there though!)

      M92
      Steps/mm: X: 200.000, Y: 200.000, Z: 1600.000, U: 30.578, E: 681.000
      
      M350
      Microstepping - X:16(on), Y:16(on), Z:16(on), U:4(on), E:16(on)
      
      M201
      Accelerations (mm/sec^2): X: 10000.0, Y: 10000.0, Z: 100.0, U: 800.0, E: 10000.0
      
      M203
      Max speeds (mm/min)): X: 18000.0, Y: 18000.0, Z: 1600.0, U: 9000.0, E: 8000.0, min. speed 0.60
      
      M566
      Maximum jerk rates (mm/min): X: 1000.0, Y: 1000.0, Z: 500.0, U: 50.0, E: 3000.0, jerk policy: 0
      
      M906
      Motor current (mA) - X:2546, Y:2546, Z:1663, U:670, E:450, idle factor 60%
      
      M913
      Motor current % of normal - X:100, Y:100, Z:100, U:100, E:100
      

      I'll mention that these get overwritten in the slicer, so this is what the Slicer is currently printing the part at. Superslicer is also lowering acceleration on outer perimeters to about 1500mm/sec^2 and then bumping it back up to 10000mm/sec^2 for everything else.

      Finally, I just updated to 3.4 Beta 3, and I'm partway through a benchy hull. I can say that, audibly, I can't hear the stuttering anymore. And visually, the hull just looks wayy better overall so far. I'll post again for the final verdict, but updating to the latest unstable release may very well have fixed it!

      posted in Tuning and tweaking
      poofjunior
      poofjunior
    • RE: [3.3] 6HC+3HC+SBC Stuttering Motion on Small Contiguous Segments

      @phaedrux can do! Here's my config.g file.

      I'll mention that I'm currently just printing PLA at ambient bed temp, and the bed heater is completely unplugged. A couple extra notes on hardware:

      • This is a toolchanger, so the U-axis is devoted to the tool locking mechanism
      • 3 Drives are devoted to Z axis motion
      • Only 1 tool (Orbiter + E3DV6 Copper Hotend) is currently provisioned (at the bottom of the config)
      ; Jubilee CoreXY ToolChanging Printer - Config File
      
      ; General setup
      ;-------------------------------------------------------------------------------
      M111 S0                    ; Debug off 
      M929 P"eventlog.txt" S1    ; Start logging to file eventlog.txt
      
      ; General Preferences
      M555 P2                    ; Set Marlin-style output
      G21                        ; Set dimensions to millimetres
      G90                        ; Send absolute coordinates...
      M83                        ; ...but relative extruder moves
      
      
      ; Stepper mapping
      ;-------------------------------------------------------------------------------
      ; Connected to the MB6HC as the table below.
      ; Note: first row is numbered left to right and second row right to left
      ; _________________________________
      ; | U(Lock) | Y(Right) | X(Left)  |
      ; | Z(Back)  | Z(Right) | Z(Left) |
      
      M584 X0.2 Y0.1            ; X and Y for CoreXY
      M584 U0.0                 ; U for toolchanger lock
      M584 Z0.3:0.4:0.5         ; Z has three drivers for kinematic bed suspension. 
      
      M569 P0.1 S0              ; X stepper reverse direction
      M569 P0.2 S0              ; Y Stepper reverse direction
      M906 X{0.9*sqrt(2)*2000}  ; LDO XY 2000mA RMS the TMC5160 driver on duet3
      M906 Y{0.9*sqrt(2)*2000}  ; generates a sinusoidal coil current so we can 
                                ; multply by sqrt(2) to get peak used for M906
                                ; Do not exceed 90% without heatsinking the XY 
                                ; steppers.
                                                  
      M569 P0.0 S0                ; U Toolchanger Lock reverse direction
      M906 U{0.7*sqrt(2)*670} I60 ; 70% of 670mA RMS idle 60%
                                  ; Note that the idle will be shared for all drivers
       
      M906 Z{0.7*sqrt(2)*1680}  ; 70% of 1680mA RMS
      
      
      ; Kinematics
      ;-------------------------------------------------------------------------------
      M669 K1                   ; CoreXY mode
      
      ; Kinematic bed ball locations.
      ; Locations are extracted from CAD model assuming lower left build plate corner
      ; is (0, 0) on a 305x305mm plate.
      M671 X297.5:2.5:150 Y313.5:313.5:-16.5 S10 ; Front Left: (297.5, 313.5)
                                                 ; Front Right: (2.5, 313.5)
                                                 ; Back: (150, -16.5)
                                                 ; Up to 10mm correction
      
      
      ; Axis and motor configuration 
      ;-------------------------------------------------------------------------------
      
      M350 X1 Y1 Z1 U1       ; Disable microstepping to simplify calculations
      M92 X{1/(0.9*16/180)}  ; step angle * tooth count / 180
      M92 Y{1/(0.9*16/180)}  ; The 2mm tooth spacing cancel out with diam to radius
      M92 Z{360/0.9/4}       ; 0.9 deg stepper / lead (4mm) of screw 
      M92 U{13.76/1.8}       ; gear ratio / step angle for tool lock geared motor.
      
      ; Enable microstepping all step per unit will be multiplied by the new step def
      M350 X16 Y16 I1        ; 16x microstepping for CoreXY axes. Use interpolation.
      M350 U4 I1             ; 4x for toolchanger lock. Use interpolation.
      M350 Z16 I1            ; 16x microstepping for Z axes. Use interpolation.
      
      
      ; Speed and acceleration
      ;-------------------------------------------------------------------------------
      M201 X2500 Y2500       ; Accelerations (mm/s^2)
      M201 Z100              ; LDO ZZZ Acceleration
      M201 U800              ; LDO U Accelerations (mm/s^2)
      
      
      M203 X18000 Y18000 Z1600 U9000    ; Maximum axis speeds (mm/min)
      M566 X500 Y500 Z500 U50           ; Maximum jerk speeds (mm/min)
      
      
      
      ; Endstops and probes 
      ;-------------------------------------------------------------------------------
      ; Connected to the MB6HC as the table below.
      ; | X | U |
      ; | Y | - |
      ; | Z | - |
      
      M574 X1 S1 P"0.io0.in"  ; homing position U1 = low-end, type S1 = switch
      M574 Y1 S1 P"0.io1.in"  ; homing position X1 = low-end, type S1 = switch
      M574 U1 S1 P"0.io3.in"  ; homing position Y1 = low-end, type S1 = switch
      
      M574 Z0               ; we will use the switch as a Z probe not endstop 
      M558 P8 C"0.io2.in" H3 F360 T6000 ; H = dive height F probe speed T travel speed
      G31 K0 X0 Y0 Z-2    ; Set the limit switch position as the  "Control Point."
                          ; Note: the switch free (unclicked) position is 7.2mm,
                          ; but the operating position (clicked) is 6.4 +/- 0.2mm. 
                          ; A 1mm offset (i.e: 7.2-6.2 = 1mm) would be the 
                          ; Z to worst-case free position, but we add an extra 1mm
                          ; such that XY travel moves across the bed when z=0
                          ; do *not* scrape or shear the limit switch.
      
      ; Set axis software limits and min/max switch-triggering positions.
      ; Adjusted such that (0,0) lies at the lower left corner of a 300x300mm square 
      ; in the 305mmx305mm build plate.
      M208 X-13.75:313.75 Y-44:341 Z0:295
      M208 U0:200            ; Set Elastic Lock (U axis) max rotation angle
      
      
      
      ; Machine Heaters and temperature sensors
      ;-------------------------------------------------------------------------------
      
      ; Bed
      M308 S0 P"0.temp0" Y"thermistor" T100000 B3950 A"Bed" ; Keenovo thermistor
      M950 H0 C"0.out0" T0                  ; H = Heater 0
                                          ; C is output for heater itself
                                          ; T = Temperature sensor
      M143 H0 S130                        ; Set maximum temperature for bed to 130C    
      M307 H0 A589.8 C589.8 D2.2 V24.1 B0 ; Keenovo 750w 230v built in thermistor
                                          ; mandala rose bed
      M140 H0                             ; Assign H0 to the bed
      
      
      ; Tool definitions
      ;-------------------------------------------------------------------------------
      M92 E681            ; Orbiter 0 steps per mm
      M350 E16 I1         ; 16x microstepping for Orbiter 0 Axis. Use interpolation
      ; Tool steppers on expansion board 1 (adapt this to your own set up)
      M201 E3600                ; Orbiter 0 Max Speed (mm/min)
      M203 E600                 ; Orbiter 0 Max Accel (mm/s^2)
      M566 E300                 ; Orbiter 0 Max Jerk (mm/min)
      
      M584 E1.0                 ; Orbiter 0 on 3HC Board 1
      M569 P1.0 S0 D2           ; Orbiter 0 Reverse Direction and Spreadcycle Mode
      M906 E450                 ; 500mA peak
                                ; E does not support expressions in 3.2.0-beta4
      
      ; Tool Thermistors and Heaters
      M308 S1 P"1.temp0" Y"thermistor" T100000  B4725 C7.060000e-8 A"t0_heater" ; Orbiter 0 thermistor
                                                ; Sx = Sensor Number
      M950 H1 C"1.out0" T1                      ; Heater for extruder out tool 0
                                                ; Hx = Heater number
                                                ; Tx = temp sensor number for this heater
      ; M307 H1 A1252.3 C361.3 D5.3 V24.0 B0    ; from pid tuning without sock
      M307 H1 A811.4 C309.4 D4.7 V24.0 B0       ; With sock
      M143 H1 S300                              ; Maximum temp for hotend to 300C
      
      ; Fans
      M950 F1 C"1.out3"                     ; Define Hotend Fan output
      M106 P1 S255 H1 T45 C"HeatBreakCool0" ; S = Speed of fan Px
                                            ; Hxx = heater for thermo mode
                                            ; T = temps for thermo mode.
      									  
      M950 F2 C"1.out6"                     ; Define Part Cooling Fan output
      M106 P2 C"t0_part_cooling_fan"
      
      
      M563 P0 S"Tool 0" D0 H1 F2  ; Px = Tool number
                                  ; Dx = Drive Number
                                  ; H1 = Heater Number
                                  ; Fx = Fan number part cooling fan
      G10  P0 S0 R0               ; Set tool 0 operating and standby temperatures
                                  ; (-273 = "off")
      M572 D0 S0.05               ; Set pressure advance
      
      G10  P0  X0 Y36.62 Z-3.3    ; Set Tool 0 XYZ Carriage Offsets
      
      
      
      M501                        ; Load saved parameters from non-volatile memory
      
      

      Ooh--I was wondering if there was a way to use the package manager to get the unstable packages. I'll give that a whirl now. Thanks for the pro-tip and the quick reply!

      posted in Tuning and tweaking
      poofjunior
      poofjunior
    • [3.3] 6HC+3HC+SBC Stuttering Motion on Small Contiguous Segments

      Hey folks, I've got an issue that looks eerily similar to this one. In a nutshell, a series of small contiguous line segments (like the hull of a Benchy) cause the printer head's XY motion to "stutter" as it travels through those moves. For slow speeds, this manifests as blobs. For faster speeds, this looks like smaller blobs but can also look like weird discolorations (testing on a somewhat translucent filament).

      I've tried:

      • running prints with XY Jerk cranked up to 3000 mm/sec
      • running prints with the firmware on 3.3 on both the 6HC and 3HC expansion

      but the problem persists, and I can visually observe the print head stuttering (and hear motion slow down too) during these sorts of moves.

      My setup is:

      • 1x Duet 6HC Mainboard + 1x Raspberry Pi 4 (SBC Mode) connecting to XYZZZU motor outputs on a Jubilee
      • 1x 3HC Expansion board connected to an Orbiter Extruder and copper E3D V6 Hotend

      Diagnostic outputs for firmware versions are:

      M122 B0
      === Diagnostics ===
      RepRapFirmware for Duet 3 MB6HC version 3.3 (2021-06-15 21:45:47) running on Duet 3 MB6HC v0.6 or 1.0 (SBC mode)
      Board ID: 08DJM-956L2-G43S4-6J1FG-3SJ6L-KB6UG
      Used output buffers: 1 of 40 (15 max)
      === RTOS ===
      Static ram: 150904
      Dynamic ram: 61808 of which 456 recycled
      Never used RAM 141024, free system stack 202 words
      Tasks: SBC(ready,5.0%,328) HEAT(delaying,0.0%,331) Move(notifyWait,0.0%,352) CanReceiv(notifyWait,0.0%,799) CanSender(notifyWait,0.0%,374) CanClock(delaying,0.0%,339) TMC(notifyWait,7.2%,93) MAIN(running,87.8%,922) IDLE(ready,0.0%,29), total 100.0%
      Owned mutexes: HTTP(MAIN)
      === Platform ===
      Last reset 00:01:40 ago, cause: power up
      Last software reset at 2021-08-23 12:37, reason: User, none spinning, available RAM 138136, slot 0
      Software reset code 0x0012 HFSR 0x00000000 CFSR 0x00000000 ICSR 0x0440f000 BFAR 0x00000000 SP 0x00000000 Task SBC Freestk 0 n/a
      Error status: 0x00
      Step timer max interval 155
      MCU temperature: min 36.2, current 36.5, max 36.5
      Supply voltage: min 24.0, current 24.0, max 24.0, under voltage events: 0, over voltage events: 0, power good: yes
      12V rail voltage: min 12.0, current 12.1, max 12.1, under voltage events: 0
      Heap OK, handles allocated/used 0/0, heap memory allocated/used/recyclable 0/0/0, gc cycles 0
      Driver 0: position 0, standstill, reads 17703, writes 0 timeouts 0, SG min/max not available
      Driver 1: position 0, standstill, reads 17701, writes 0 timeouts 0, SG min/max not available
      Driver 2: position 0, standstill, reads 17701, writes 0 timeouts 0, SG min/max not available
      Driver 3: position 0, standstill, reads 17701, writes 0 timeouts 0, SG min/max not available
      Driver 4: position 0, standstill, reads 17702, writes 0 timeouts 0, SG min/max not available
      Driver 5: position 0, standstill, reads 17702, writes 0 timeouts 0, SG min/max not available
      Date/time: 2021-08-30 19:18:23
      Slowest loop: 0.29ms; fastest: 0.04ms
      === Storage ===
      Free file entries: 10
      SD card 0 not detected, interface speed: 37.5MBytes/sec
      SD card longest read time 0.0ms, write time 0.0ms, max retries 0
      === Move ===
      DMs created 125, maxWait 0ms, bed compensation in use: none, comp offset 0.000
      === MainDDARing ===
      Scheduled moves 0, completed moves 0, hiccups 0, stepErrors 0, LaErrors 0, Underruns [0, 0, 0], CDDA state -1
      === AuxDDARing ===
      Scheduled moves 0, completed moves 0, hiccups 0, stepErrors 0, LaErrors 0, Underruns [0, 0, 0], CDDA state -1
      === Heat ===
      Bed heaters = 0 -1 -1 -1 -1 -1 -1 -1 -1 -1 -1 -1, chamberHeaters = -1 -1 -1 -1
      === GCodes ===
      Segments left: 0
      Movement lock held by null
      HTTP* is doing "M122 B0" in state(s) 0
      Telnet is idle in state(s) 0
      File is idle in state(s) 0
      USB is idle in state(s) 0
      Aux is idle in state(s) 0
      Trigger* is idle in state(s) 0
      Queue is idle in state(s) 0
      LCD is idle in state(s) 0
      SBC is idle in state(s) 0
      Daemon is idle in state(s) 0
      Aux2 is idle in state(s) 0
      Autopause is idle in state(s) 0
      Code queue is empty.
      === CAN ===
      Messages queued 27, received 39, lost 0, longest wait 0ms for reply type 0, peak Tx sync delay 4, free buffers 49 (min 49), ts 15/15/0
      Tx timeouts 0,0,0,0,0,0
      === SBC interface ===
      State: 4, failed transfers: 1, checksum errors: 0
      Last transfer: 1ms ago
      RX/TX seq numbers: 2755/2755
      SPI underruns 0, overruns 0
      Disconnects: 0, timeouts: 0, IAP RAM available 0x2c810
      Buffer RX/TX: 0/0-0
      === Duet Control Server ===
      Duet Control Server v3.3.0
      Code buffer space: 4096
      Configured SPI speed: 8000000Hz
      Full transfers per second: 36.08, max wait times: 18.2ms/0.0ms
      Codes per second: 0.31
      Maximum length of RX/TX data transfers: 3592/868
      

      on the mainboard and

      M122 B1
      Diagnostics for board 1:
      Duet EXP3HC firmware version 3.3 (2021-06-15 16:12:41)
      Bootloader ID: not available
      Never used RAM 158696, free system stack 4400 words
      Tasks: Move(notifyWait,0.0%,160) HEAT(delaying,0.0%,104) CanAsync(notifyWait,0.0%,69) CanRecv(notifyWait,0.0%,82) CanClock(notifyWait,0.0%,71) TMC(notifyWait,7.3%,63) MAIN(running,91.4%,338) IDLE(ready,0.0%,39) AIN(delaying,1.3%,263), total 100.0%
      Last reset 00:01:41 ago, cause: software
      Last software reset data not available
      Driver 0: position 0, 420.0 steps/mm,  standstill, reads 63628, writes 15 timeouts 0, SG min/max 0/0, steps req 0 done 0
      Driver 1: position 0, 80.0 steps/mm,  standstill, reads 63633, writes 11 timeouts 0, SG min/max 0/0, steps req 0 done 0
      Driver 2: position 0, 80.0 steps/mm,  standstill, reads 63633, writes 11 timeouts 0, SG min/max 0/0, steps req 0 done 0
      Moves scheduled 0, completed 0, in progress 0, hiccups 0, step errors 0, maxPrep 0, maxOverdue 0, maxInc 0, mcErrs 0, gcmErrs 0
      Peak sync jitter 0/13, peak Rx sync delay 178, resyncs 0/0, no step interrupt scheduled
      VIN: 24.3V, V12: 12.2V
      MCU temperature: min 30.2C, current 31.4C, max 31.7C
      Ticks since heat task active 141, ADC conversions started 101669, completed 101668, timed out 0, errs 0
      Last sensors broadcast 0x00000002 found 1 146 ticks ago, loop time 0
      CAN messages queued 947, send timeouts 0, received 832, lost 0, free buffers 37, min 37, error reg 110000
      dup 0, oos 0/0/0/0, bm 0, wbm 0, rxMotionDelay 0
      

      on the 3HC expansion board.

      Finally, I should mention that this setup prints some good-looking small parts with simple geometry like XYZ calibration cubes.

      If anyone has any suggestions, I'm happy to give them a go. Cheers, and thanks!

      posted in Tuning and tweaking
      poofjunior
      poofjunior
    • RE: Standalone Config Snippets

      @deckingman yeah; this is certainly useful, but I'm looking for something more general purpose.

      On my end, I'm the maintainer of Jubilee and the Discord crew of folks building Jubilees or Jubilee-inspired machines. Jubilee is a toolchanger, so lots of folks approach building one with a custom tool setup in mind, but plenty of folks also share tool designs. I'm looking for something that can make the configuration readily adaptable to anyone's tool setup, not just mine. And then, on top of that, for folks sharing the same tools, it would be great to offer standalone snippets on the wiki or on Github that can stand separately from the machine configuration. High level, my ideal goal would be for anyone to be able to dynamically switch tool setups without ever having to touch a config.g file. Rather; there's some in-between abstraction like a GUI that automatically assembles the config for you.

      posted in Using Duet Controllers
      poofjunior
      poofjunior
    • RE: Standalone Config Snippets

      Hmm, I suppose I'm looking for an easier way to quickly re-configure a machine. For the most part, that's a pretty rare thing to do, since most folks configure their machine once or occasionally when they upgrade/tweak hardware.

      But for machines whose configurations can change frequently (tool changing machines that add/remove various tools), it would be nice to have an easier way to manipulate the machine configuration in a way that's not so highly interconnected.

      I certainly can't ask the Duet project to support this kind of flexibility for hobbyists who want to switch tools on-and-off. But I do think that having a less-interconnected config.g or, higher level, an alternate api for changing machine configuration, would lower the bar for folks interested in playing with toolchanging setups. And I think that Duet supports tool-changing setups best so far.

      If folks developing the Duet would be willing to consider something like configuring the machine via Object Model upload (via text file or other), I could jump on that API to build an abstraction that lets you easily add/remove tools. Otherwise, I'd probably look at using jinja templates to abstract the config-writing/editing process a bit more.

      I'll keep my eyes peeled on project updates for anything that could make machine reconfiguration easier. In the meantime, thanks a bunch for chiming in!

      posted in Using Duet Controllers
      poofjunior
      poofjunior