@T3P3Tony Here's a PDF I made that should help with what the "I" value should be for the toolboard, based on how it's oriented. Hope it helps.

Toolboard accelerometer orientation guide

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.

@JayJay said in PT100 with a Duet-3-6HC & Tool-Board-LC1 ?:

@Veti said in PT100 with a Duet-3-6HC & Tool-Board-LC1 ?:

i would suggest getting a pt1000 sensor

Thats not happening, if the supposed best control board cant accept an analog input from a P100 amplifier thats a pretty poor show.

I would rather rip out the Duet-3 , install the 32bit GTR PRO V1.0 and run Klipper/Octoprint with the dwc2-for-klipper-socket, a board I know is going to accept an analog signal.

The way you've responded comes off more as a troll than someone with an actual issue. So I'm clear, you're asking (demanding) that the TOOLBOARD support a PT100 sensor, but if it can't and won't, you're going to rip it out, buy new hardware, and HAVE to route wires from the head to the main board anyway, something that was a plausible solution with using the Duet3. You then say you're not willing to use a PT1000 because you'd have to buy additional hardware, and wait for it's delivery, so instead, that too is why you'd rip out a Duet3 and buy (and wait) for an entire new controller and hardware. Because why spend more money when you have parts.

I wanted to make sure I understand this logic.

@dc42 any chance that a future version of the toolboard could/would have the accelerometer baked into it, or an expansion header to work with say the adafruit board?

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.

I’m excited to see development in non-planar technology, especially for my industry (architecture/design).

@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.

Here you go.

From Adafruit

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

@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

@lael they’ve been great, and I only need two sets. They are also often used in food service to connect/disconnect fluids like soda syrup, beer taps, etc.

Like you said, it allows me to quick disconnect the hotend for whatever reason without any major disassembly, or if I want to locally drain it without emptying the entire loop.

@generisi that’s an old build. I ended up designing my own extruder and that’s been combined with a slice liquid mosquito.

@lael said in Pictures of water-cooling:

@nuramori Where did you source your self-sealing valves you've got installed on your liquid lines? They look like they would be quite helpful if you ever needed to do hotend maintenance etc.

They are Colder medical quick disconnects that are dripless.

PLCD16006 Quick-Disconnect Panel-Mount Hose Barb Fitting Body; Valved, 3/8" Tube ID, Acetal

@oozebot I had the same problem and a retune seems to be working. I’m wondering if it also was triggering my mid print stalls/crashes by silent faults.

Im not sure if this is related, but ever since the following happened, things are now printing well.

After the mid print stalls, I had a temp sensor fault. The sensor itself was fine, so I performed an auto tune with the new beta. The result was notably different than the values I had before (which were generated with beta 2). Once I did that, I then was getting temp faults on the bed. I then auto tuned the bed and that too were notably different values.

Once I used the new values for the heaters, everything has been running perfectly fine. The same gcode has completed without a stall for multiple prints of the same file.

@gloomyandy It was a dialog box stating that the machine had to be reset to continue - I didn't screenshot it, though I mentioned it in a previous post from me, with the exact wording. When that box comes up, there's no action possible, so I can't execute a M122 command to get data, and a restart wipes the ability to get the info related to the stall.

The original post contains M122 output from both the main board and the toolboard the one time I could perform a M122 command.

If it happens again, I'll try a USB connection to cull out info if possible.

@cadetc I use Moons 0.9 1.5 amp NEMA17's they work great, looking at the torque curve charts and my setup.

The stealthchop stuff that's commented out are from when I was experimenting with it (if that's what you are referring to with the M915 command - it was to set the registers on the driver)

I have been having the same problem with 3.4beta2, and just had it happen again on 3.4 beta3. I too am using a toolboard 1.1 with a v1.0 Duet3.

@dc42 unforunately, the issue was not resolved with the latest beta. I just had the same print I listed above, stall again, this time I could not pull any diagnostic, as the window said a reset was needed.

I get the following error:

Prerequisites
Duet Web Control
Version 3.4.0-b3

But I have that installed.