Best posts made by Diamondback

Maybe a bit broader, but having the file editor as some sort of non-modal popup that can be moved/minizmized/changed in size would be quite helpful in a bunch of situations. Bonus points if we can open multiple files at once.

@dc42 Thanks for adding this in 3.5 rc2 Very useful
(The sensor here is almost 1m away from the extruder, so in case the signal looks too noisy, that's why)

cc @herrtschaefer

Thanks for all your work and dedication, can't wait to see what 2023 brings along.

I'd like to get some discussion going on a toolhead specific board for toolchangers.
Here's my current setup on the toolhead:

• 1x Stepper (the coupler)
• 3x Endstops/switches (X-Axis, Z-Probe, "Tool-Present" switch)
• 1x Accelerometer with USB cable used for data transmission
• 1x Dotstar 8x8 grid

Overall that's a fairly chunky amount of cables being routed to my toolhead, so I would really like to see some sort of solution that involves just running power and CAN over there.

The 1LC toolboard covers almost all of it, but I don't think it can do the dotstars and it's also quite bulky in size and with a bunch of stuff I don't need (heater output, fan outputs)

So having a slimmed down version of that would be amazing.

Alternatively, a board that can do all of the above and at the same time connect to the actual tool via pogo pins (ie another stepper driver, some more IO etc, that way you'd have one board that covers both the head logic as well as the tool stuff.
Of course, this might need some further software refinement for dynamically connecting to/disconnecting from the stepper/heater/fans etc

Are there maybe already other CAN connected and Duet compatible boards that would give me such an option?

@dc42 Finally working
https://www.dropbox.com/s/fyguad75k8g2ffe/VID_20230124_102416.mp4?dl=0

The if/elif conditional is exclusive, that means as soon as one condition evaluates to "true", it stops looking at the rest.
For example, as soon as your status is processing or busy, the leds will ALWAYS be white, everything after that won't even be checked.

The same applies to the temp checks, you are checking if the temperature is above 170°C and after that, you check for the temperature being > 230°C, but 230°C is also > 170°C, so it will never actually end up executing this code.

It appears (from the way you wrote this), you'd want to use a bunch of non exclusive conditionals or switch around the order to make more sense.

; LED control
if {state.status} == "paused"
  M150 R255 B255 P255 S20  ; purple
  M300 S4000 P50 G4 P300 M300 S4000 P50 ; double beep
if {state.status} == "processing" || {state.status} == "busy"
  M150 R255 U255 B255 P255 S20  ; white
if {heat.heaters[1].current} <= 70
  M150 R255 U255 B0 P255 S20 F1 ; yellow
if {heat.heaters[1].current} > 170
  M150 R255 U80 B0 P255 S20 F1  ; orange
if {heat.heaters[1].current} >= 230
  M150 R255 U0 B0 P255 S20 F1  ; red
if {state.status} == "idle"
  M150 R0 U255 B0 P255 S20  ; green

For the purple, you'll have to come up with some other condition depending on when exactly you actually want that to show up.

@sputnikoc3d said in Filament Material Changes without Load - Unload ???:

@fcwilt said in Filament Material Changes without Load - Unload ???:

@sputnikoc3d said in Filament Material Changes without Load - Unload ???:

my goal isnt to improve my load and unload routines ... which I can do at a later time.

I just change the filament "by hand" and then select the newly loaded filament from the DWC.

Frederick

Wait ... wuuuutt ?

Why do I have to load and unload ... obviously Im doing something wrong. I want the ability to do just what youre doing - lol wth ..

Frederick probably just means that he has no code in the load/unload macros, that way, DWC doesn't do anything when "loading" or "unloading filaments, other than showing a different string in the interface.

Just in case someone finds this in the future. I went the recommended route and manually extend the allowed area in bed.g like this:

bed.g

[...]
M208 Y{global.minY}:{global.maxYMesh} ; extend allowed space for probing near the edge of the bed
G29 S0
G1 X400 Y{global.maxY} F20000		          ; Park
M208 Y{global.minY}:{global.maxY}     ;reset safe moving space to normal

In config.g I create the referenced globals from above:

[...]
; Axis Limits
global minY = -149
global maxY = 72
M208 X-146:159 Y{global.minY}:{global.maxY} C0:250 Z0:290 ; set axis minima & maxima
[...]
global minYMesh = global.minY
global maxYMesh = 115
M557 X-146:150 Y{global.minYMesh}:{global.maxYMesh} P10  ; define mesh grid
[...]

This works fine and is maintenance free in terms of having to maintain hardcoded coordinates in multiple places.

@T3P3Tony That is very kind of you, but I really don't think the overall time, effort and expenses are warranted here for a tiny SD card. I'd rather have the Duet Team put that saved money towards the team fund
Really just wanted to let you know about it in case a pattern appears.

Hey,

would it be possible to expose some more data of the Magnetic Filament Monitors in the obejct model?
I'm specifically thinking about this the new custom graph feature of the BtnCmd plugin to create a graph of the filament throughput measurements.

Not only does this look nice, it might also be helpful in debugging some things.

The currently loaded filament(s) are stored in sys/filaments.csv. You can edit this file by hand and restart the Duet to apply the changes.

On my custom toolchanger I have seen similar super slow moves while changing tools. I think they are related to the current position being out of the normal limits, if I set the tool macros to leave the active tool within the allowed area after tfree, it works as expected.

Do you move your tools outside the normal limits for parking by any chance?

Oh wow, I think i finally figured out what's going on. At least something that is going on.

My hotend holder is deforming under the pressure from the extruder... This tilts the whole hotend, moving the nozzle in Y and Z.

I just noticed this very extremely when going from first to second layer, the first layer is fairly slow (30m/s) and the second is twice as fast.
The higher speed deformed the holder a lot more, giving an explanation for the perfect first layer and then the sudden issue with layer 2.

I'm not sure yet why it would cause issues during the first layer as it still sometimes does, but right now I'm printing beefier holders and then see if that helps.
T1 was also less affected since it's using a 0.4mm nozzle vs the 0.3mm on T0...

Fingers crossed that this is purely a hardware issue on my side and no obscure firmware thing

@dc42 Ok, please let me know if I can assist you in any way, I'd really like to see these monitors working completely for me for the first time

Hello,

my toolchanger has prime/brush macros as part of the actual toolchange code and I wonder if there is a way to check for "is extruder hot enough for extrusion" based on the temperatures set in M302? (without manually checking for hardcoded temps)

Basically I want to skip the entire prime/brush cycle if I select a given tool when it's cold. Right now it will still try to do it and spawn the expected "too cold for extrusion" errors.
While this is not doing any harm, I'd still like to avoid that

@mintytrebor Very nice release! Did not find anything else so far, all my reported issues are fixed.

Really looking forward to the input shaping work that is already happening!
I have a question though.
I'm currently building the wiring loom for my custom toolchanger and was wondering if there is any thoughts yet on whether or not the Duets will have the abilitiy to connect something like an ADXL345 sensor to them for auto calibrating the input-shaping parameters.
If so, is there any preferred connection method yet (I2C vs SPI), if there is, I'd directly include the necessary cables in my loom to the carriage head, which has a built-in mount for such a sensor and save me some headache of having to rebuilt the loom further down the line.

Thanks

Yea, I think this was indeed the problem. After installing much stronger parts for the hotend holder, the nozzle does not dive anymore. (Btw these weren't stupidly small parts or bad filament, they were printed in carbon fiber reinforced nylon, which is much stiffer than anything else I have around, so that really wasn't on my radar...)

Nice work!

Little bug report: I'm being displayed this message despite not having any toolboards. My printer IS a TC, however, it uses a Duet 2 + Duex5 and a standalone accelerometer.

@siam Finally managed to get the accelerometer connected... I'm currently using about 3m of USB 3 extension cable and that seems to work ok, was just a lot of pain to wire up...
It looks like shielding is way more effective here than just twisted wire pairs (which I tried before and didn't work on its own)