Posts made by GoremanX

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.

@Phaedrux @droftarts Just to clarify, the default in RRF-config is to generate a tpost0.g that contains M106 P0 ("Wait for Temperatures to be Reached on Tool Change"). I didn't do that manually. Selecting the first tool is not the default, but it's a checkbox directly beneath that option ("Select the First Tool on Start-Up"). With those two options selected, setting the selected tool's default standby or active temperature to anything other than 0 causes the heater to require reaching that temperature before startup completes. That means the network port won't be turned on until that temperature is reached, which could be never, as in this case. Meanwhile, it's very difficult to know what's going on with the board since it can't be connected to via ethernet, despite the fact that the board is in fact initialized and functional.

Perhaps this could be prevented by changing the firmware so that the network comes up as soon as M540/M550/M551/M552/M586/[other network-related gcodes] have been read, rather than waiting until processing of config.g has been completed. The current behavior makes diagnosis a nightmare. I get that there might be network-related gcodes at any point in the file, but there has to be a better way to handle this than potentially locking up the ethernet port for minutes or even forever on startup.

@droftarts You're correct. With my single-extruder printers, config.g contains

G10 P0 X0 Y0 Z0 R0 S0                             ; set tool P axis offsets and set active and standby temperatures to S

So active and standby temps are set to 0 by default. but for this dual-extruder setup, RRF-Config gave me:

G10 P0 X-10 Y0 Z0                                        ; set tool P axis offsets
G10 P0 R0 S170                                           ; set initial tool P active (R) and standby (S) temperatures

(and its equivalent for P1)

So when I set a tool as active, its standby temperature becomes its active temperature. Again, there's no good reason for that to prevent the network from coming up. But M106 P0 in tpost0.g is basically just a "wait" command, so I guess the board sits there and waits for the temperature to be reached rather than finish booting.

Everything from the print head is already disconnected. This particular printer is a WIP.

Sending T0 after the printer has started up causes an immediate heater fault, presumably because there's no heater connected. Same with T1. There's a M116 P0 in tpost0.g that gets triggered when T0 is run. Commenting it out prevents the heater fault from happening, and also allows the board to start up completely with the network port active, even with T0 present in config.g. So it looks like the heater fault caused by M116 P0 on startup might be breaking something.

The odd thing is that I started my diagnosis by temporarily using a known good config.g (the one from my delta printer) just to see if the network port would come on. That config.g file DOES have T0 at the end of it, and tpost0.g was always present with M116 P0 in it. Yet the network port worked fine. So the issue here might be a combination of my defined heaters/sensors and the M116 P0 that T0 triggers. Either way, I would never expect that to prevent the network port from coming on...

@Phaedrux In retrospect, I don't think there was anything wrong with my board at all. I haven't received the warranty replacement yet, but I bought a new board from a different reseller in the meantime to get my printer back up and running right away, with the intention of using the eventual warranty replacement in a new project.

Surprise! It didn't work in the exact same way, either... (using the SD card from the old board that I deemed "defective")

Spent hours diagnosing the issue, and the problem is a really bizarre thing. Having:

T0

at the bottom of config.g causes the network port to not turn on. Commenting out that line fixes the issue. I don't get it, I have T0 at the end of ALL my config.g files for every printer I own (I currently have 4 Duet-based printers), and this is the only time it's ever caused an issue. I wouldn't even consciously add T0 myself, but it's one of the RRF Configurator options, so it ended up in there at some point and got carried over into all my configurations. In this case, it's appropriate because it's a dual extruder setup. But why the presence of T0 is causing the network to fail is beyond me, and only with this specific config.g layout. Meanwhile, everything else on the board works fine. The fans come on at the right temps, and they respond to temperature changes as they should. The presence of T0 in this case only kills the network port.

If someone would like to try out the config.g file from my OP this time and confirm that I'm not on crack, please do.

@stuartofmt Ah, I get it. So you've got a move to get the print head out of the way before the end of the gcode file. I'll just add something similar, then, thank you!

@stuartofmt I found that the layer detection starts capture too late sometimes. I prefer to use "dontwait" and start the process manually, even if it results in capturing initial Calibration and bed probing for nothing. I'd rather have too many photos at the beginning than not enough.

As for terminating manually, that's mostly to be 100% sure all processes got terminated. I send pid=all because in my case, a specific pi only ever monitors a single printer at a time. But having said that, I've also found that capturing ends a tad too soon. I never get a capture with the print head out of frame once the print is complete, which would be nice to have as the final frame of the video. Rather than end at the end of the last layer, it would be nice if it ended once the job is actually complete and took at least one last photo at that point before terminating

Finally got a chance to try this yesterday. It works perfect. I'm using reprap_notify to monitor the state of the printer. It polls the Duet 3 board every 30 seconds. When it detects that a print job has started, it starts an instance of DuetLapse3. When the job ends, it sends a terminate command via curl. I get an email notification of each event, and also if/when the printer pauses. All the files end up exactly where they need to. I have a second browser tab for monitoring the status of DuetLapse3. Everything appears to run reliably.

@stuartofmt Looks like I need to update the master image for my Pis! Out of curiosity, how much memory is on the boards you've been testing with? I'm a cheap bastard, I tend to stick to the base boards, so all mine have 1GB (older) or 2GB (current). I've been considering getting some fancy-schmancy 8GB boards for the next ones, but it's hard to justify that $40 premium just for memory I might never make use of

@stuartofmt Very cool, great job! You just covered all of the complexities of my crazy use-case, and that's no small feat I look forward to trying it out as soon as my warranty replacement Duet 3 board arrives... which should be any month now...

@BorisVivienne said in Network Port Not Working:

Maybe some software that checks and controls ports (for example VPN, employee monitoring software, proxy) closed this port for its needs?

It wasn't working in both direct-connect and network-connect situations. This was not a firewall thing. I'm sure I could've gotten around it by running it in SBC mode, but I run my boards in standalone mode.