I always enjoy reading about other people's printers, so I'll share mine I just finished.

It's a BLV Cube with a full enclosure, 7" touchscreen connected to a Pi 4, heavily modified toolhead, and some cosmetic tweaks. Really a great design, but everything could always use some upgrades!

Features/improvements from original design:

• Precision Piezo Z-probe
• Dual 5015 part cooling fans
• V6 hotend with Bondtech direct-drive
• 300x300 magnetic bed
• Raspberry Pi with Duet 2 Ethernet
• Lots(!) of LEDs

Possible upgrades:

• Watercooling for hotend and part cooling fans
• Better bed (currently I have a cheap aluminum bed with integrated heater)
• Toolchanger

A little bit of history:

This is my second printer build. I started out with a Printrbot, and designed my own printer using hardware from the Printrbot (just a standard CoreXY with linear rods, etc.). It worked quite well for about 5 years, with some significant hardware revisions and upgrades. I wanted to build a bigger and better one, using the significant lessons learned while building and upgrading, and I had some designs floating around in my head. I was originally planning on building it with V-slot, until I came across the BLV Cube, and loved it. From that stemmed this printer.

Now for the good part: Pictures!

Detail of the gantry:

Detail of the toolhead:

Messy electronics

Feel free to ask questions, and enjoy!

Edit: Added files for front panel. STL.zip.txt (rename to stl.zip)

@Phaedrux I have separate 5v and 24v power supplies with the grounds connected. The pi and the 5V_EXT pins of the duet are powered by the 5v supply, which is always on. The duet switches the 24v power supply via a relay.

I believe that undervoltage event is due to me switching off the 24v supply once since the duet was last reset.

Interesting. I use nearly the exact same settings as you do, but the main difference I think is the part cooling. You have a single fan blowing from one side, and I have two fans blowing from both sides at an angle. I think what may be happening is that there is turbulence where the two airstreams converge on my duct, and this causes the heat to build up. I might try redesigning my cooling duct so that the two airstreams are more aligned.

Also, I really like your quick change toolhead. Very compact.

@chrishamm All appears to be good. I'll update when the current print finishes.

Update: Print finished successfully and with no unwanted artifacts. That seems to have solved it!

Not sure if this is already known, but I think I have encountered a bug. On the first couple layers of a small object, the temperature setpoint changes, and the fan turns on to 100%, according to my slicer settings. However, the hotend struggles to keep up, and faults with "temperature rising too slowly". I do have a pretty powerful fan, but I'm also using a block sock. This is with a v6 hotend. I did tune with the new algorithm using M303 T0 S245, which did activate the fan.

@chrishamm All appears to be good. I'll update when the current print finishes.

Update: Print finished successfully and with no unwanted artifacts. That seems to have solved it!

@chrishamm I actually am using a Duet2 an SBC mode, but would be happy to test.

Alright, I've managed to capture a DCS log of an affected print. It seems like an underrun of the movement buffer, but it also happens sometimes in the middle of travel moves, so I'm not really sure there.

dsf_log.txt

Also, a picture to better show what I mean.

All those little blobs are what I'm talking about. They're caused by the print head dwelling for a bit at that location.

@Phaedrux I have separate 5v and 24v power supplies with the grounds connected. The pi and the 5V_EXT pins of the duet are powered by the 5v supply, which is always on. The duet switches the 24v power supply via a relay.

I believe that undervoltage event is due to me switching off the 24v supply once since the duet was last reset.

@oozeBot @TypQxQ No, what I am describing is different. I can only describe it almost like if your jerk is set too low on curved segments, only that it happens randomly and not only on curves, if that makes any sense.. It doesn't loose steps, but it's as if the controller hangs for a bit. I'll see if I can get a video.

I think what you both are experiencing is similar, and I have also experienced it way back on 3.1.1. If my travel speed was too high, it would loose steps exactly as in your videos. Haven't tried it without compensation, I should try that.

I can confirm that this does NOT occur in standalone mode. I have tested the same file in SBC mode and in standalone mode and get no jerkiness in standalone.

@dc42 @chrishamm anything else I can do to help?

Edit: DCS log coming soon

Sorry to bring this back up, but after updating to RRF 3.2-b3 I am still observing unwanted jerkiness during print moves. As the print head is moving, it stops for about 50ms at a time randomly, occurring roughly 1-2 times/10s. M122 shows no unusual information:

=== Diagnostics ===
RepRapFirmware for Duet 2 + SBC version 3.2-beta3 running on Duet 2 1.02 or later + SBC (SBC mode)
Board ID: 08DGM-917N9-FLMS4-7JTDG-3SJ6J-9HV4G
Used output buffers: 1 of 24 (21 max)
=== RTOS ===
Static ram: 20636
Dynamic ram: 103772 of which 60 recycled
Never used RAM 5580, free system stack 124 words
Tasks: Linux(ready,79) HEAT(blocked,306) MAIN(running,381) IDLE(ready,19)
Owned mutexes: HTTP(MAIN)
=== Platform ===
Last reset 00:27:46 ago, cause: software
Last software reset at 2020-11-10 22:45, reason: User, GCodes spinning, available RAM 5580, slot 1
Software reset code 0x0003 HFSR 0x00000000 CFSR 0x00000000 ICSR 0x0041f000 BFAR 0xe000ed38 SP 0xffffffff Task Linu
Error status: 0x00
MCU temperature: min 30.3, current 30.6, max 30.6
Supply voltage: min 23.8, current 23.9, max 24.0, under voltage events: 1, over voltage events: 0, power good: yes
Driver 0: position 27804, ok, SG min/max 0/281
Driver 1: position 1608, ok, SG min/max 0/295
Driver 2: position 8662, ok, SG min/max not available
Driver 3: position 0, ok, SG min/max 0/279
Driver 4: position 0, ok, SG min/max not available
Driver 5: position 0
Driver 6: position 0
Driver 7: position 0
Driver 8: position 0
Driver 9: position 0
Driver 10: position 0
Driver 11: position 0
Date/time: 2020-11-10 23:13:11
Cache data hit count 2641989901
Slowest loop: 1.58ms; fastest: 0.13ms
I2C nak errors 0, send timeouts 0, receive timeouts 0, finishTimeouts 0, resets 0
=== Storage ===
Free file entries: 10
SD card 0 not detected, interface speed: 30.0MBytes/sec
SD card longest read time 0.0ms, write time 0.0ms, max retries 0
=== Move ===
Hiccups: 0(0), FreeDm: 153, MinFreeDm: 142, MaxWait: 0ms
Bed compensation in use: mesh, comp offset 0.000
=== MainDDARing ===
Scheduled moves 19876, completed moves 19837, StepErrors 0, LaErrors 0, Underruns [0, 0, 0], CDDA state 3
=== AuxDDARing ===
Scheduled moves 0, completed moves 0, StepErrors 0, LaErrors 0, Underruns [0, 0, 0], CDDA state -1
=== Heat ===
Bed heaters = 0 -1 -1 -1, chamberHeaters = -1 -1 -1 -1
Heater 0 is on, I-accum = 0.0
Heater 1 is on, I-accum = 0.6
=== GCodes ===
Segments left: 1
Movement lock held by null
HTTP* is doing "M122" in state(s) 0
Telnet is idle in state(s) 0
File* is doing "G1 X163.770004 Y147.505005 E-0.137980" 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.
=== SBC interface ===
State: 0, failed transfers: 0
Last transfer: 7ms ago
RX/TX seq numbers: 53001/53003
SPI underruns 0, overruns 0
Number of disconnects: 0, IAP RAM available 0x021ac
Buffer RX/TX: 400/1624-0
=== Duet Control Server ===
Duet Control Server v3.2.0-beta3
File:
Buffered code: G1 X162.728 Y146.619 E-0.07341
Buffered code: G1 X162.510 Y146.265 E-0.08215
Buffered code: G1 X162.298 Y145.707 E-0.11819
Buffered code: G1 X162.209 Y145.116 E-0.11819
Buffered code: G1 X162.248 Y144.521 E-0.11819
Buffered code: G1 X162.391 Y144.024 E-0.10221
Buffered code: G1 E-0.05000 F2400.00000
Buffered code: G1 X147.391 Y145.007 F14400.000
Buffered code: G1 E1.00000 F2400.00000
Buffered code: G1 F1500
Buffered code: M204 P1000
Buffered code: G1 X147.362 Y145.355 E0.01088
Buffered code: G1 X147.295 Y145.666 E0.00993
Buffered code: G1 X147.170 Y146.010 E0.01138
Buffered code: G1 X146.903 Y146.451 E0.01605
Buffered code: G1 X146.818 Y146.555 E0.00418
Buffered code: G1 X146.549 Y146.826 E0.01188
Buffered code: G1 X146.123 Y147.115 E0.01605
Buffered code: G1 X145.644 Y147.307 E0.01605
Buffered code: G1 X145.136 Y147.392 E0.01605
Buffered code: G1 X144.621 Y147.367 E0.01605
Buffered code: G1 X144.489 Y147.342 E0.00418
Buffered code: G1 X144.000 Y147.179 E0.01605
Buffered code: G1 X143.557 Y146.916 E0.01605
Buffered code: G1 X143.283 Y146.673 E0.01138
Buffered code: G1 X143.080 Y146.428 E0.00994
Buffered code: G1 X142.883 Y146.128 E0.01116
Buffered code: G1 X142.694 Y145.667 E0.01551
==> 1296 bytes
Pending code: G1 X142.606 Y145.171 E0.01570
Code buffer space: 2232
Configured SPI speed: 8000000 Hz
Full transfers per second: 31.10
File /opt/dsf/sd/gcodes/retraction_calibration_0.2mm_PETG__10m.gcode is selected, processing

I plan to get the DCS log and in-depth USB log soon.

Also, I will try in standalone mode as well, hopefully tomorrow.

Edit: added config.g

Just to add another data point, I have also experienced this same behavior. However, I am running a duet 2, also on corexy.
Edit: I have observed this since RRF 3.1.1.

I have experienced this exact behavior. The print head jerks, almost as if it's skipping a step multiple times mid-print. I am running a duet 2 with SBC on a corexy machine with rrf 3.2-b2 as well.