@whosrdaddy The chamber doesn't get to 500c, just the heaters do. They're ceramic IR emitters with built in thermocouples. They heat whatever they're pointed at without doing much to heat the ambient air. Plus the enclosure is enormous and has a filter that recirculates the air from top to bottom, so things don't get THAT toasty in there. Basically, as long as the emitters are on and hot enough, then the object being printed can't dissipate its heat through the air, it can only do so through the build surface. So its internal temperature tends to stay the same as the bed's temperature. Meanwhile the electronics inside the enclosure aren't getting fried. It's been working great for nylon, ABS, PETG, etc with zero warpage, even with very large prints (the bed is 24" diameter).

I think I nailed it:

(note: the bottom is wavy because it's only 0.5mm thick and I just peeled it off the hot bed)

Ultimately, the solution was to minimize the amount of time that the nozzle stays in one place, and reduce the possibility of it moving across gaps immediately from the edge of a wall. I upped the speed (3600mm/s), acceleration (1500mm/s2) and jerk (1200mm/min) settings for the extruder, shortened the extrusion distance (1mm), fixed the "combing" setting in Cura (changed to "not in skin"), randomized the Z seam, and upped the outer wall wipe distance from 0.2mm to 0.4mm. Now all the stringing is gone. I still get some scarring on top skin from drooping filament, but it's minimal and literally the only minor blemish. Everything else prints so well, you'd think it was molded. Even tiny details that I used to struggle with now come out crisp and sharp.

Thanks all for the advice!

@whosrdaddy No, no air blown directly over the print area. The air from the BOFA filter gets blown in through a 90 degree elbow so it gets circulated around the periphery of the enclosure below the heated bed, starting directly under one of the IR emitters.

And no cold air to the heatsink. Ambient air temp rarely gets much higher than about 70c anyways when printing ABS, typically it's more like 40c. This is plenty adequate for cooling the heatsink of the Mosquito Magnum using the stock 25mm fan. I've considered switching to a water cooled Mosquito, but haven't seen a need to yet.

I do however have an external air pump for part cooling, for when I need to do bridging and such. It blows through a tube into a Berd air ring

.

@Phaedrux said in DuetLapse3:

@GoremanX That was a pretty weird timelapse.

I got bored while waiting for another print to finish, and that acrylic door looked like a great screen to project silly things onto

For fun, my first timelapse using this script:
https://youtu.be/XjBwTqbEZD8

It's also super comforting to know that I'M NOT DOING ANYTHING WRONG and there's nothing wrong with my setup that'll bite me later. That was my main concern.

I have chamber heaters that can go up to 500c. I have them mapped as chamber heaters using the M141 command. According to the documentation, M141 must come before M143 (which is used to set the max temperature for a heater). However the default max temperature for a chamber heater is something significantly less than 500c. I assume it's 125c, same as for bed heaters.

In any case, when my heaters are above that default (either because they're still cooling down from a print or the print is paused) and I restart the board, I get an instant heater fault on reboot because M141 sets the heater as a chamber heater before M143 sets its max temperature in config.g. This is becoming very frustrating.

Has this order dependency been eliminated in a forthcoming version of RRF?

@oliof Yes. If you're feeding 5v to the board from an external source (either from a Pi or through the ext_5v pin), then you no longer need to use the onboard 5v converter. Removing that jumper disables the onboard converter

@stuartofmt One observation: isn't it possible to pull the file name of the current print job through the object model? If so, instead of just processid, could the directory be named "jobfilename-processid"? That way, the directory is easily identifiable as the result of a specific job, but there's still a unique number appended to it for when the same job is run more than once

@Phaedrux Cool! Would be nice if it defaulted to that when we click the </> button. I couldn't easily find any way to set it to different languages (not that I tried very hard), but now that I know, I'll do so

Ok so everyone realizes that this thread was solved months ago, right ?

@gorillamotors it's probably per minute since I can't imagine my extruder spitting out 10+ feet of filament per second

@phaedrux So that worked perfectly. I added:

G10
G10
G30

right before it starts printing every skirt. Now ever first layer is absolutely perfect and I've had zero failures from a very full build plate

@phaedrux Bahaha! Yes, duh. That's often my failure, over-thinking

Having said that, what's a max safe probing temperature on a PEI build surface? I usually probe with the nozzle at 170c for auto-calibration and bed mesh probing. But I don't want to have to wait too long before probing otherwise the nozzle might ooze and the resulting probe will be inaccurate.

I was thinking of adding a couple of filament retractions before probing to help prevent oozing, but even with that, if I have to wait for dozens of seconds before I can probe, there might still be oozing.

A couple months ago, I suffered from an issue where, when printing multiple objects "one at a time", every subsequent object after the first would have its first layer slightly too high, thereby often ruining the job: https://forum.duet3d.com/topic/21701/multiple-objects-printed-one-at-a-time-fail-after-the-first

There's a whole lot of discussion and conjecture in that thread, but ultimately I thought I solved it by disabling certain slicer features.

Except I didn't. It kept happening randomly, and I gave up and didn't bother trying to fix it anymore. I just stopped using "One at a time" mode. But that mode is so darn useful! Especially now when I have an actual commercial product I want to produce and sell that involves like 20 items per batch. Doing this as 20 different jobs is unbelievably tedious and slow.

I think I finally, truly, for real figured out why this is happening. I don't think it's the expansion of the heated bed, but rather the expansion of the frame and linear rails as they warm up throughout the print job. My printer is a very large Kossel delta with 24" horizontals and 56" uprights in 2040 aluminum. The linear rails are 1200mm long stainless steel MGN12. All this is enclosed with an enclosure heater. The rods for the Smart Effector are 600mm long. So it wouldn't take much expansion in any of these components for the Z axis to be affected enough to cause the issue I'm having. We're talking 0.1 to 0.2mm of offset here, not really noticeable in the finished print but devastating to that crucial first layer. Ultimately, none of this really matters. Short of pre-heating my printer for hours on end before starting a job, there is no solution for preventing it, and even that's debatable. It's simply a design issue.

However I think I could compensate for it by probing the bed between items in a single print job. If I added a snippet of gcode between each object in the file that:

• probes the bed
• compares the actual result with the expected result
• subtracts or adds the difference to the current Z offset

then each subsequent object would start with a more accurate first layer. Note that I'm not referring to a full auto-calibration or mesh bed probing, just a single probe in a specific spot. Preferably this probing would be right where the next object is about to be printed. That would give me the proper Z height for that object, and I could more easily find where to add it within the gcode file, basically whenever the nozzle returns to Z0.

Does anyone have any advice on how I'd accomplish this? I'm having a hard time figuring out the gcode snippet I need to make it happen.

@stuartofmt Because DWC's "webcam" feature only supports a url pointing to a specific image over http. I used to generate that image with my pi camera, but now the camera is monopolized by the timelapse. Since the image I want to see has already been taken for the timelapse, it seems like a good way to kill two birds with one stone. That image could also be used to show the most recent frame on the timelapse status page.

Feature suggestion: add an option to create a symbolic link that always points to the second-most-recent photo for a currently-running timelapse. For example, the current directory for captured images on one of my printers is: /mnt/remote/KosselXT/duet/21439_CFFFP_Riser_191x25_links
An option to have a symbolic link at /mnt/remote/KosselXT/current.jpg that always points to the second-most-recent image would allow us to add it to the DWC interface as a webcam image by serving that file over http. The symbolic link would have to be updated every frame. The reason I'm specifically referring to the second-most-recent image is that sometimes the current image isn't complete yet when DWC tries to display it. Pointing the link to the second-most-recent image would always display a complete image, at the expense of being a few seconds behind.

@JohnOCFII said in DuetLapse3:

Really raising the bar with music... I'll have to see what I can find!

Hah! "Stock" previews from Adobe Premiere Pro. Not even the fully licensed track, just the so-called low quality preview version. If enough people view the video, YouTube will flag it, but it's fine to use for a limited expected audience

Still figuring stuff out for my setup, but this is getting fun

https://youtu.be/EscEw5L3rYU

@Phaedrux I don't know how the default standby temperature got added to my config.g, I don't think it's something that RRF-config did. It's too coincidental that that's the safe-probing temperature on my larger delta printer with Duet Smart Effector, even though this printer isn't a delta. May have gotten carried over somehow (although that delta printer doesn't actually use that setting in config.g). But there's reasons to set a default standby temperature without actually wanting the hotend to be set to its standby temperature on startup.

My point is mostly that there's a myriad things in config.g that might cause initialization to be delayed or never complete, and network port initialization should not be pre-empted as a result. The network port should be powered on as soon as it's possible to do so, whether it's ethernet or wifi.