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.

@MartinNYHC

I have mine working on my BLV with the duet3. It’s actually easier than it was with the duet2. I can share details and pictures in a bit if you’re interested.

@OwenD

I believe your sentiments are accurate and warranted, though whether it’s my fault for not seeing the fine print - if I was more aware of some of the limitations of the tool board (the ones I am most concerned with) I may not have immediately designed a hotend around it until they were part of the firmware. When I went to buy it (actually the second one, since there’s been an improvement since I bought the first) the vendor’s page didn’t have a link or any reference to the limitations of the hardware/firmware. I don’t think that would a stretch to ask that such links be required of authorized vendors. The lack of pid tuning via the tool board is a pain, even with workarounds. Now watching 3.2 make its beta rounds before even getting to a 3.3 beta is going to be a bit painful.

I don’t fault the development team, it is what it is - I’d be curious what items would be more important to people if the user base were polled.

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.

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.

@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

I got it fixed.

A stray strand of copper (I assume from when I was making my connections I didn't get all my cut strands cleaned up) had lodged under the connector housing, and likely shorting something. I didn't see it until I started looking at the solder joints with a magnifying glass.

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

@oozeBot thanks. I wanted to make sure because other than when I bought it, it would be hard to determine the processor short of examining the board. (The “I” models weren’t mentioned, so I don’t know if they are inherently the proper processor).

I use a meanwell RD-65a to supply 5/12v, combined with a meanwell 150w 24v psu (I have a ac heated bed). The Ed-65a works extremely well and is fanless so it’s quiet.

I have a paneldue 5i that was purchased from Filastruder last year. Can I safely assume I’d be fine to use this firmware? Short of disassembling my printer to look for the processor type, is there a “safe” date that’s a good way to determine the likelihood the hardware will be compliant?

@OwenD

I believe your sentiments are accurate and warranted, though whether it’s my fault for not seeing the fine print - if I was more aware of some of the limitations of the tool board (the ones I am most concerned with) I may not have immediately designed a hotend around it until they were part of the firmware. When I went to buy it (actually the second one, since there’s been an improvement since I bought the first) the vendor’s page didn’t have a link or any reference to the limitations of the hardware/firmware. I don’t think that would a stretch to ask that such links be required of authorized vendors. The lack of pid tuning via the tool board is a pain, even with workarounds. Now watching 3.2 make its beta rounds before even getting to a 3.3 beta is going to be a bit painful.

I don’t fault the development team, it is what it is - I’d be curious what items would be more important to people if the user base were polled.

@dc42

One request i would make is a future hardware change - add a jumper configurable “end of chain” resistor. I understand how the tool board was designed for use with the distribution board, but the tool board is extremely useful for single headed printers too. The termination resistor is kind of documented for this implementation of a tool board, but I can see it’s popularity by reducing wiring making it a popular approach. Allowing for wiring it up and then changing a jumper would make it much easier.

@I_Jedi

Sorry about being tardy. Real life has been a real b*tch, and answering questions has been sidelined. I’ll try and get you the revised code I did (because of the particular arduino I was using - adafruit mini) and the wiring. The wiring itself is far simpler than it was for the duet2, and connects to the io0 port. Keep in mind I still use the panel due, which generates the serial traffic, but the new settings that push data should negate the need for the panel due if you are so inclined to ditch it.

@MartinNYHC

I have mine working on my BLV with the duet3. It’s actually easier than it was with the duet2. I can share details and pictures in a bit if you’re interested.

Nice! Btw, I’m Nuramori.

Yes please!!!!!!!

Especially if the fan voltage allows for 24v as an option

Out of curiosity, do you have a terminating resistor on your can-fd line?