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.

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

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:

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.

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.

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!

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

2. Is there any effort to make dynamic config generation for swapping tools any simpler using resources of the optional Raspi?

Cheers--and thanks!

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.

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!

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.

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!

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

@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!

@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!

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!

@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.

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!

@t3p3tony Yeah to be honest, having an alternate means of configuring the machine by simply importing an Object Model would be slick. Since it's basically just a json dict or dictionary-like, being able to upload one could let us write custom WebUIs that simply output an Object Model as a text file. What's more, it could be hierarchical. So the machine could look for an object model file first; then patch it with individual commands from a config.g file if one exists. That would give you backwards compatibility.

I've been tempted to write a config generator script that figures out the order of commands and produces a config. From there it's not much work to wrap it with a couple webpages that enable dynamic tool adding/deleting. But that approach seems a bit backwards, since the Object Model already has the structure I want. There's just no way (AFAIK?) to import one from a file.

Thanks for looking into options on this!

@engikeneer hmm having a way to just define the config as the object model would actually solve this problem! But AFAIK, there's no way to simply paste the object model in a text file.

Unfortunately, pulling out tool-related configs into a standalone macro doesn't work for the M584 reason mentioned above. In a nutshell, to add a new extruder drive, you need to know about the existence of all the others.

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

2. Is there any effort to make dynamic config generation for swapping tools any simpler using resources of the optional Raspi?

Cheers--and thanks!

@phaedrux I am very excited for it! Thanks for the heads-up.