Upgrading all of the firmware/softwares resolved the issue. Thank you all for the help!
Best posts made by brendon
Latest posts made by brendon
RE: Extrusion not synced with motion during tpre/tpost on CAN boards
No luck, same results.
Extrusion not synced with motion during tpre/tpost on CAN boards
I have been having an issue with my ToolChanger/Duet3/config.g CAN board 'tools' where I can see them extruding during a move where they should not be extruding. If I call T-1, then T0, I will see the extruder push approx 5mm of filament through the nozzle during the 'gotoCenter' script. The tool should have stopped extruding during t0_prime, but there's a repeatable length of filament purged while traveling for the move in gotoCenter.
Edit: it is worth noting that T1, T2, & T3 work fine. The issue only happens with T0. All of the scripts are identical aside from x/y dock locations.
; tpre0.g ; called before tool 0 has been selected ; ;Unlock Coupler M98 P"/macros/changer/unlock" ;Move In G1 X-25.1 Y210 F24000 ; account for nozzle while approaching in y G91 G1 Z7 Y30 F24000 G90 ; wait for warmup ;M116 P0 ;Collect G1 Y245.0 F4000 G4 P150 ;Close Coupler M98 P"/macros/changer/lock"
;Move Out G91 G53 G1 Y-5 F24000 G90 ; make sure we have a tool M98 P"/macros/tool-detect/ensureToolHeadConnected" ;prime M98 P"/macros/priming/t0_prime" M98 P"/macros/calibration/gotoCenter"
; PRIME NOZZLE G91 G1 E8 F240 G1 E15 F150 G90 M400 G4 P5 ; WIPE G91 G1 Y-60 E-0.5 F24000; G90
G1 X140.8 Y80.7 F24000
The issue is repeatable in both 3.01_rc4/5. DSF 1.2.5. Toolboard firmware from 3.01_rc4/5 releases.
RE: Heated bed no longer controllable after software update
Nevermind, I found the issue in the release notes.
Duet 3 users: there is no longer a default bed heater. To use Heater 0 as the bed heater, put M140 H0 in config.g (later in config.g than your M950 H0 command).
Heated bed no longer controllable after software update
I updated a Duet 3 via ssh
sudo apt-get update sudo apt-get upgrade
and am now no longer able to see/control the bed temperature. I am unsure of what software versions I had been using, but I've included a portion of config.g and the current output from M122. Before the update the machine was running fine. The hot end is still working as expected.
; Heaters M308 S0 P"0.temp0" Y"thermistor" T97700 B4619 C9.743561e-8 R2200 ; define bed temperature sensor M308 S1 P"0.temp1" Y"thermistor" T100000 B4725 C7.06e-8 ; define E0 temperature sensor M950 H0 C"out0" T0 Q100 ; heater 0 uses the bed_heat pin, sensor 0 M950 H1 C"out1" T1 ; heater 1 uses the e0_heat pin and sensor 1
=== Diagnostics === RepRapFirmware for Duet 3 MB6HC v0.6 or 1.0 version 3.0 running on Duet 3 MB6HC Board ID: 08DJM-956L2-G43S4-6J1FA-3SJ6T-1B6QH Used output buffers: 1 of 32 (7 max) === RTOS === Static ram: 152720 Dynamic ram: 149872 of which 0 recycled Exception stack ram used: 216 Never used ram: 90408 Tasks: ETHERNET(blocked,844) NETWORK(ready,1984) HEAT(blocked,1200) CanReceiv(suspended,3808) CanSender(suspended,1476) CanClock(blocked,1424) TMC(blocked,212) MAIN(running,4452) IDLE(ready,160) Owned mutexes: === Platform === Last reset 00:01:37 ago, cause: software Last software reset at 2020-01-16 19:06, reason: User, spinning module LinuxInterface, available RAM 90408 bytes (slot 0) Software reset code 0x0010 HFSR 0x00000000 CFSR 0x00000000 ICSR 0x0444a000 BFAR 0x00000000 SP 0xffffffff Task 0x4e49414d Error status: 0 Free file entries: 10 SD card 0 not detected, interface speed: 37.5MBytes/sec SD card longest block write time: 0.0ms, max retries 0 MCU temperature: min 33.6, current 34.0, max 34.1 Supply voltage: min 23.9, 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 Driver 0: standstill, reads 22282, writes 14 timeouts 0, SG min/max 0/0 Driver 1: standstill, reads 22283, writes 14 timeouts 0, SG min/max 0/0 Driver 2: standstill, reads 22283, writes 14 timeouts 0, SG min/max 0/0 Driver 3: standstill, reads 22287, writes 11 timeouts 0, SG min/max 0/0 Driver 4: standstill, reads 22285, writes 14 timeouts 0, SG min/max 0/0 Driver 5: standstill, reads 22285, writes 14 timeouts 0, SG min/max 0/0 Date/time: 2020-01-16 19:08:03 Slowest loop: 2.66ms; fastest: 0.09ms === Move === Hiccups: 0(0), FreeDm: 375, MinFreeDm: 375, MaxWait: 0ms Bed compensation in use: none, comp offset 0.000 === MainDDARing === Scheduled moves: 0, completed moves: 0, StepErrors: 0, LaErrors: 0, Underruns: 0, 0 === AuxDDARing === Scheduled moves: 0, completed moves: 0, StepErrors: 0, LaErrors: 0, Underruns: 0, 0 === Heat === Bed heaters = -1 -1 -1 -1 -1 -1 -1 -1 -1, chamberHeaters = -1 -1 -1 -1 === GCodes === Segments left: 0 Stack records: 1 allocated, 0 in use Movement lock held by null http is idle in state(s) 0 telnet is idle in state(s) 0 file is idle in state(s) 0 serial is idle in state(s) 0 aux is idle in state(s) 0 daemon* is ready with "M122" in state(s) 0 queue is idle in state(s) 0 lcd is idle in state(s) 0 spi is idle in state(s) 0 autopause is idle in state(s) 0 Code queue is empty. === Network === Slowest loop: 0.46ms; fastest: 0.01ms Responder states: HTTP(0) HTTP(0) HTTP(0) HTTP(0) HTTP(0) HTTP(0) FTP(0) Telnet(0) Telnet(0) HTTP sessions: 0 of 8 - Ethernet - State: 2 Error counts: 0 0 0 0 0 Socket states: 0 0 0 0 0 0 0 0 === CAN === Messages sent 389, longest wait 0ms for type 0 === Linux interface === State: 0, failed transfers: 0 Last transfer: 14ms ago RX/TX seq numbers: 35121/2998 SPI underruns 0, overruns 0 Number of disconnects: 0 Buffer RX/TX: 0/0-0 === Duet Control Server === Duet Control Server v188.8.131.52 Code buffer space: 4096 Configured SPI speed: 2000000 Hz Full transfers per second: 0.71
Printer occasionally stops printing
Very infrequently, I see my printer lock up while it is printing. If it is going to happen, it will always happens immediately at the start of the print, perhaps after ~10 gcode commands. I cannot 'pause' the print through dwc, but I can press the Emergency Stop, which will give me control of the steppers again. If I simply try to start the print again, it will inevitably lock up at the same point. A full power-cycle is required for the system to print again. The same gcode will then run fine.
I don't mean to drop an issue without a repro path, but I figured it was worth mentioning that it has happened more than a handful of times up to now. System/software versions are in my signature.
RE: Z-probe (BLTouch) and dual z axis help on Duet 3
Thanks @triumphantduke for posting all of your work along the way. The wiring connections you mentioned and sharing your git repo for your config.g were very helpful for me in getting G29 working in only a few minutes. If you have the bltouch working on your end, could you mark the thread 'resolved' so people know that it contains an accurate solution?