One thing I did was collect all the old and torn silicone socks I had lying around and made a wipe.

I just sliced off the sides and kept the face, then alternated them with washers. Used RTV on the bottom to bind them.

The one thing that I used quite often and rely on for several reasons was the gviewer in octoprint. I have seen the fork of the viewer that has been done by someone who's name I can't remember at the moment, but it's not the same tool as in octoprint. It may seem to get relegated as a nonsense or convenience tool at times on the forum here, but the combination of slider to view future layer pathing, and also (near) real time indication of what the print head is doing and intended to do has saved my prints and lowered my blood pressure more often than not. Even if a DWC plugin that would mimic that as close as possible would be fantastic - the code is open, and iirc in python. If there's a plug-in API, I would even try and migrate that somehow. Personally I'd love to see it as part of DWC.

This is the only thing I was missing from octoprint. Having the gcode viewer would close the door on my need for it. .

Here’s mine.

So you'll need to change the M305 command to something like:

M307 H0 A___ C___ D____ V____ B0 ; change the values after running a PID autotune

M308 S0 P"spi.cs1" Y"thermocouple-max31856" K"c" ; Configure the bed temp sensor. This is the equivalent to your old one, assuming you're using the daughterboard on the duet and not on an expansion board.

M143 H0 S120 ; limit the bed temp
..
..
M950 H0 C"bedheat" T0 ; define the bed heater and bind the sensor we configured above to it.

The M950 have to come after the sensor is first configured.

@gtj0 I had to change it to make sure it backs off of the endstops first, since the issue seems to be that it will error out if it's too close. Here are my files. While they work, I still at times will get the error. A few tries will eventually get it to "home", or worst case I disable the motors and manually move it away a bit. I also had to slow down the speed of approach to the endstops.

I have a BLV cube, so the Y axis is a max, not a min, fyi...

; homex.g
; called to home the X axis
;
G91 ; relative positioning
G1 Z5 F1000 S2 ; lift Z relative to current position
G1 H1 X-355 F4000 ; move quickly to X axis endstop and stop there (first pass)
G1 H2 X5 Y5 F3000 ; go back a few mm
G1 H1 X-355 F360 ; move slowly to X axis endstop once more (second pass)
G90 ; absolute positioning

; homey.g
; called to home the Y axis
;
G91 ; relative positioning
G1 Z5 F2000 S2 ; lift Z relative to current position
G1 H1 Y355 F4000 ; move quickly to Y axis endstop and stop there (first pass)
G1 H2 Y-5 F4000 ; go back a few mm
G1 H1 Y355 F360 ; move slowly to Y axis endstop once more (second pass)
G90 ; absolute positioning

; homez.g
; called to home the Z axis
;
G91 ; relative positioning
G1 Z5 F1000 S2 ; lift Z relative to current position
G90 ; absolute positioning
G1 X162.5 Y162.5 F6000 ; go to first probe point
G30 ; home Z by probing the bed

G91 ; relative positioning
G1 S2 Z5 F100 ; lift Z relative to current position
G90 ; absolute positioning

; homeall.g
; called to home all axes
;
G91 ; relative positioning
G1 Z5 F2000 S2 ; lift Z relative to current position
G1 H1 X-355 Y355 F4000 ; move quickly to X or Y endstop and stop there (first pass)
G1 H1 X-355 ; home X axis
G1 H1 Y355 ; home Y axis
G1 H2 X5 Y-5 F3000 ; go back a few mm
G1 H1 X-355 F360 ; move slowly to X axis endstop once more (second pass)
G1 H1 Y355 F360 ; then move slowly to Y axis endstop
G90 ; absolute positioning
G1 X152 Y166.4 F4000 ; go to first bed probe point and home Z
G30 ; home Z by probing the bed
G32 S2

G91 ; relative positioning
G1 S2 Z5 F100 ; lift Z relative to current position
G90 ; absolute positioning

ok, I split the difference and put a 2.49k pullup resistor between 3.3v and the stop. all is well now!

Thanks to everyone.

The pattern is related to worm drive systems in general, and teeth engagement. There are a few folks that have done quite a bit of analysis, and the harmonic is repeatable, and is a factor of the contact/engagement pulses that occur as the teeth engage, flex, and transition to the next, in concert with the worm gear. I can scrounge up some of the data and graphics that support this.

Sorry about that. I messed up on the catagory selection.

Looking over my Misumi rails, there's a recommended amount of cumulative movement distance before lubricating. It made me think how would I even know that, then figured that may be a nice and useful feature to have as part of an overall printer utility. This way I can review the aggregate distance traveled by a rail guide, and lubricate accordingly. Maybe even have an editable trigger value that then sends a custom reminder message upon start of the machine or a print.

I just flashed the update, and now it works fine. Odd, but I'll take it.

I used a dropbox hotfix to 3.1.0 and I'm totally locked up. Can't get to where I can access the web page. says can't connect. sigh

One more observation from digging around in the logs. The lost connection seems to also happen when the cron job to update the pi4 clock kicks in.

Some more info - looked into the logs on the SBC, and this corresponds to the event (daemon.log)

May 13 23:36:24 duet3 DuetControlServer[740]: [warn] Lost connection to Duet (Timeout while waiting for transfer ready pin)
May 13 23:36:24 duet3 DuetControlServer[740]: [info] Connection to Duet established
May 13 23:36:24 duet3 DuetControlServer[740]: [error] Failed to switch off remote heater 1: Response timeout: CAN addr 20, req type 6013, RID=1278
May 13 23:36:24 duet3 DuetControlServer[740]: [info] Cancelled printing file 0:/gcodes/CFFFP_3DBenchy.gcode, print time was 1h 47m
May 13 23:36:24 duet3 DuetControlServer[740]: [info] Emergency Stop! Reset the controller to continue.

The only other seemingly relevant message popped up in the message.log and kern.log, both identical:

May 13 23:13:54 duet3 kernel: [   14.228273] ICMPv6: process `dhcpcd' is using deprecated sysctl (syscall) net.ipv6.neigh.eth0.retrans_time - use net.ipv6.neigh.eth0.retrans_time_ms instead

But never could get an error message or any indication what had happened.

Since I’ve been using the toolboard, printing hadn’t failed, but finally did, with a message. Same symptoms, random freeze.

Error message was “Board 20 does not have input handle 1000.”

The toolboard has a can ID of 20.

Any indication what would generate that?

I have a BLTouch on my toolboard, if you need some help.

Currently I'm using IO1 for the optical endstop. While I wait for the new piezo controller board, I'm using IO0 with a BLTouch, but it was intended to replaced with the piezo controller. I'm working with Pyr0ball (the developer) on how to get i2c working to change settings on the controller, and also output the z-probe signal on the same connector, instead of needing two (one for i2c communication, and another for actual z-probe communication with the duet3).

What extruder are you using?

My fallback will be wiring back to the Pi4 that pairs with the duet3, but for elegance, I'm hoping I won't have to. Going to the toolboard would be the most ideal.

I saw that - I wasn't sure if that meant physical changes to the board. I'm hoping not.