Yesterday I visited the Duet3D booth and had the pleasure to meet the team and have a chat with David and Christian.
It made me realize just how much is going on behind the curtains and how much work and passion those guys are pouring into the development of new features and constant improvement of the overall system.
I am super excited about what's to come.
I hope you guys have a great last day at Formnext!
Max
Good morning!
I know that this has been discussed several times already. I started this thread to collect the available closed loop options for the Duet3.
I have two custom large format printers in the making. One with a build volume of 1000x1000x1000mm for printing architecture models and one with 500x500x1000mm for printing speaker enclosures. With a Build volume this large speed and reliability are essential. Therefore, a closed-loop motion system is a "must have" for my clients.
For the Duet3 I have found the following options:
Duet3 + Duet3 Expansion 1XD + external closed loop stepper drivers that accept step/dir signals
@dc42 I am aware that there is a closed-loop extension board in the making for the Duet3. Is there already a rough estimate on the release date or beta test?
Is there an alternative "of the shelve" closed loop solution available that support the CAN FD protocol?
Cheers,
Max
I would like to use the constant surface speed feature on my Duet based CNC-Lathe.
I am using a generic Haas turning post Processor with some minor adjustments that I have tested with Fusion360 or Solidworks+HSMWorks.
the constant surface speed GCode (G96) is defined on the Haascnc G-Code dictionary as follows:
"G96 commands the control to maintain a constant cutting speed at the tip of the tool. The spindle RPM is based on the diameter of the part where the cut is taking place, and the commanded S value (RPM=3.82xSFM/DIA). This means the spindle speed increases as the tool gets closer to X0. When Setting 9 is set to INCH, the S value specifies Surface Feet Per Minute. When Setting 9 is set to MM, the S value specifies Surface Meters Per Minute.
WARNING: It is safest to specify a maximum spindle speed for the Constant Surface Speed feature. Use G50 to set a maximum spindle RPM. Not setting a limit allows the spindle speed to increase as the tool reaches the center of the part. The excessive speed can throw parts and damage tooling."
Cheers Max
Indeed, I wrote a simple macro that sets the height of the dust shoe to the height of the spindle collet+ the current tool length. This macro is called after a toolchange or if one of the macros for mist cooling or dust extraction is called. Maybe I will add a demon later that updates the height of the dust shoe regularly during a job. But for now this will do.
I made a short video while running a tool change. Not having to fiddle with the dust shoe during toolchanges is already so much more convenient.
And with this start Gcode for PrusaSlicer the correct heightmap is loaded according to the temperature of the printbed.
{if first_layer_bed_temperature[0] <=40}
G29 S1 P"heightmap_roomtemp.csv"
{elsif first_layer_bed_temperature[0] <=70}
G29 S1 P"heightmap_60°.csv"
{elsif first_layer_bed_temperature[0] <=90}
G29 S1 P"heightmap_80°.csv"
{elsif first_layer_bed_temperature[0] <=110}
G29 S1 P"heightmap_100°.csv"
{endif}
Thanks everyone for your ideas and feedback. This is by far more elegant than my original idea. 
@bearer @Phaedrux
I have solved the issue by installing the unstable version (DSF Version: 2.1.3) of Duet Software Framework on Raspberry Pi. and also reverting back to RC11
The guide links to the stable version of the DSF and latest version of the reprap firmware which, at least in my case is not compatible and will lead to the "DCS is unavailable" Error.
cheers Max
Hey @bruce
Thank you so much for developing and sharing your post processor! I use it with the HSM-Works plugin directly in SolidWorks for my duet based CNC Mill.
Any chance to also include a profile for turning as well? I am in the process of converting a Lathe to CNC using a Duet3 6HC board. With lathe support, it would really be the "one post processor to rule them all" 
Cheers Max
@dc42 Thank you for your response.
Yes, I am running RRF 3.4.4 (Sorry, I forgot to mention that!)
With RRF 3.5beta1 on the EXP1HCL, the Y-axis motors now keep their position when closed loop mode is activated. 
With the release of the new Duet 3 Roto Toolboard I am not sure if a new smart effector is really needed. for me the main advantage of the smart effector was nozzle probing. But with the new Scanning Z-Probe Nozzle probing is already obsolete in my opinion. Of course you woul need to set the probe offset manually with a Scanning Z-Probe. To do this I use either a separate button style probe or I adjust the z height manually with baby stepping and run a simple macro to adjust the probe offset by the baby stepping amount and save the new probe offset in config-override.g.
I would still be interested in buying multiple smart effectors if they support the following points. some of them are obvious but for the sake of completeness...
And lastly not necessarily a must but it is nice to have options.
Since I use CPAP style part cooling and watercooling for the hotend I do not require fanports on the tool board. But I recon This would be a no-go for most users.
Just installed your UDL, thank you so much for your work!
-Max
I second this! The simplest way to determine when the nozzle is touching the bed, is to measure when the nozzle touches the bed.
I recon this feature could be used for Delta calibration since it requires a nozzle contact probe.
@dc42 I just had the same error as reported by @balajiramani . In my case, the error occurred during the first layer of a print job.
=== Diagnostics ===
RepRapFirmware for Duet 3 MB6HC version 3.6.0-alpha.5+1 (2024-08-31 17:51:17) running on Duet 3 MB6HC v1.01 (SBC mode)
Board ID: 0JD2M-999AL-D25S4-7J1D2-3SJ6K-T51V3
Used output buffers: 1 of 40 (18 max)
=== RTOS ===
Static ram: 135136
Dynamic ram: 96472 of which 0 recycled
Never used RAM 68768, free system stack 198 words
Tasks: SBC(2,ready,0.8%,796) HEAT(3,nWait 6,0.0%,369) Move(4,nWait 6,0.0%,333) TMC(4,nWait 6,2.8%,353) CanReceiv(6,nWait 1,0.1%,794) CanSender(5,nWait 7,0.0%,334) CanClock(7,delaying,0.0%,353) MAIN(2,running,93.9%,440) IDLE(0,ready,2.4%,29), total 100.0%
Owned mutexes: HTTP(MAIN)
=== Platform ===
Last reset 00:00:37 ago, cause: software
Last software reset at 2024-09-18 18:45, reason: User, Expansion spinning, available RAM 65064, slot 0
Software reset code 0x6012 HFSR 0x00000000 CFSR 0x00000000 ICSR 0x00400000 BFAR 0x00000000 SP 0x00000000 Task SBC Freestk 0 n/a
Error status: 0x00
MCU temperature: min 33.9, current 34.3, max 34.5
Supply voltage: min 22.7, current 23.5, max 23.6, under voltage events: 0, over voltage events: 0, power good: yes
12V rail voltage: min 12.1, current 12.1, max 12.1, under voltage events: 0
Heap OK, handles allocated/used 99/4, heap memory allocated/used/recyclable 2048/88/40, gc cycles 0
Events: 0 queued, 0 completed
Date/time: 2024-09-18 18:46:21
Slowest loop: 25.07ms; fastest: 0.07ms
=== Storage ===
Free file entries: 20
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 ===
Segments created 0, maxWait 0ms, bed comp in use: none, height map offset 0.000, hiccups added 0 (0.00/0.00ms), max steps late 0, ebfmin 0.00, ebfmax 0.00
Pos req/act/dcf: 0.00/0/0.00 0.00/0/0.00 0.00/0/0.00
next step interrupt due in 297 ticks, disabled
Driver 0: standstill, SG min n/a, mspos 8, reads 8720, writes 11 timeouts 0
Driver 1: standstill, SG min n/a, mspos 8, reads 8720, writes 11 timeouts 0
Driver 2: standstill, SG min n/a, mspos 8, reads 8720, writes 11 timeouts 0
Driver 3: standstill, SG min n/a, mspos 8, reads 8720, writes 11 timeouts 0
Driver 4: standstill, SG min n/a, mspos 8, reads 8720, writes 11 timeouts 0
Driver 5: standstill, SG min n/a, mspos 8, reads 8720, writes 11 timeouts 0
Phase step loop runtime (us): min=0, max=2, frequency (Hz): min=1913, max=2089
=== DDARing 0 ===
Scheduled moves 0, completed 0, LaErrors 0, Underruns [0, 0, 0]
=== DDARing 1 ===
Scheduled moves 0, completed 0, LaErrors 0, Underruns [0, 0, 0]
=== Heat ===
Bed heaters -1 -1 -1 -1 -1 -1 -1 -1 -1 -1 -1 -1, chamber heaters -1 -1 -1 -1, ordering errs 0
Heater 0 is on, I-accum = 0.0
Heater 1 is on, I-accum = 0.0
=== GCodes ===
Movement locks held by null, null
HTTP* is doing "M122" 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
File2 is idle in state(s) 0
Queue2 is idle in state(s) 0
Q0 segments left 0, axes/extruders owned 0x80000003
Code queue 0 is empty
Q1 segments left 0, axes/extruders owned 0x0000000
Code queue 1 is empty
=== Filament sensors ===
check 0 clear 0
Extruder 0 sensor: no filament
=== CAN ===
Messages queued 252, received 2403, lost 0, ignored 0, errs 315, boc 0
Longest wait 55ms for reply type 6041, peak Tx sync delay 50472, free buffers 50 (min 49), ts 187/186/0
Tx timeouts 0,0,0,0,0,0
=== SBC interface ===
Transfer state: 5, failed transfers: 0, checksum errors: 0
RX/TX seq numbers: 1854/1854
SPI underruns 0, overruns 0
State: 5, disconnects: 0, timeouts: 0 total, 0 by SBC, IAP RAM available 0x2858c
Buffer RX/TX: 0/0-0, open files: 0
=== Duet Control Server ===
Duet Control Server version 3.5.2 (2024-06-12 07:09:26, 32-bit)
HTTP+Executed:
> Executing M122
Code buffer space: 4096
Configured SPI speed: 8000000Hz, TfrRdy pin glitches: 0
Full transfers per second: 60.06, max time between full transfers: 125.2ms, max pin wait times: 33.5ms/14.1ms
Codes per second: 2.94
Maximum length of RX/TX data transfers: 4476/1040
I just tested 3.6.0-alpha.5+1 on our 5meter printer. The "homing jolt" on our CAN-connected Servo Drives is strong enough to make the servo drives go into fault mode 
Reducing the homing speed by 50% did help, but it still produces a loud "clonk"
Everything else is working as expected 
Setup: Duet MB6HC+ 3xEXP1XD+ EXP3HC
My small printer is flawlessly printing since an on our under 3.6.0-alpha.5+1
Setup: Duet MB6HC+ 3xEXP1HCL+TOOL1RR
four screw bed tramming and mesh probing with the SZP seems to be working as expected, I only had to reduce the pressure advance value by 50%.
I have noticed some short movement pauses during printing, these were also present in RRF 3.5.2, maybe increasing the movement queue length can help here?
Since setting up a "Continuous rotational axis" is not yet supported by RRF, I thought about a workaround to get a continuous rotational axis that won't interfere with the rest of the movement system...
To recap:
I use a stepper motor peristaltic pump on my CNC-Router to control the coolant flow while milling aluminum parts. My original Idea was to set up an extra Axis on the duet to control the stepper motor of the peristaltic pump. Right now this doesn't work since there is no option to run an axis continuously and progressing the axis in a loop would block other movements.
Here is my Idea:
So I need a stepper motor that can basically be controlled like a Fan in DWC. So why not use one of the duet's PWM outputs to generate the step pulses for an external Stepper motor Driver?
Please check the following on the software side:
Since the holes are spaced correctly, it is unlikely that you are loosing steps. But you can check the following to make sure it is not a mechanical issue:
See if the ballscrews are securely coupled to the motors
See if the ballscrew bearings have any play or are loose
Reduce your cutting feed and reduce your depth of cut to see if high feed speeds are bending your machine
Check if your motors are loosing steps: Position the spindle at a point outside your working area. Get something to mark this position. A dial indicator would be optimal. Mount the dial indicator so that it is stationary on your machine. Set the spindle against the dial indicator in die direction of the X or Y-Axis. Zero the dial indicator and note down the machine position. Then run your Program. When the Program is finished, move the spindle to the previously noted position. If the dial indicator is still close to zero, there should be no lost steps.
@droftarts said in [3.5.0-rc3+] M108 (cancel heating) is not working.:
If you run M109 et al in a macro, cancel it by sending M108 from the console in DWC; I think that shouldn’t be blocked.
Yes, that works. Thank you very much for clearing that up!
Okay now I am confused...
From the M108 description I understood that the purpose of this command is to break out of an M109, M116, M190 or M191 wait-for-temperature loop.
When I send an M190 S60 over the console followed by an M108, the input channel is blocked until the bed reaches its set temperature of 60°.
The same goes for macros:
;M108 test
echo "setting bed temp!"
M140 S60 ; set bed temp
G4 S1
echo "sending M108"
M108
Max
I just noticed that the M108 command is not working... at least it does not work in RRF 3.5.0-rc3+. Unfortunately, I have no system running a stable version for testing if the problem is limited to the beta.
Thank you very much for your feedback! Just to be on the side of caution. The Roto Toolboard should be ok with the 115W nominal power of the pheatus rapido?
According to the docs the current limit on the high current output of the Revo toolboard is 3.4A (80W @ 24V).
While this is totally fine for the intended use of the Roto tool board with the E3D Revo system (max 60W), most high flow hotends are well above 80W or even around 115W.
Since the full output current is only drawn during the first few seconds during heatup, I was wondering if the revo toolboard might be capable of handling currents higher than 80W for a short amount of time without damaging the high current mosfet?
I found this table for the phaetus rapido @24V. It illustrates the drop in current at different temperatures quite well:
