@bearer It does indeed wait for cooling

Please send this guy a review sample. I look forward to watching more tutorials, learning from others insights, and you guys selling.... I mean getting the duet 2 wifi into more hands in the community. I think it would lead to more designs on thingiverse, mods, public sharing of macos, and tutorials in general. The only reason I bought the duet 2 wifi was because of youtube channels "Design Prototype Test" and "Chris Riley". I really do wish there was more video content on this board explaining things for example pressure advance ( right now most youtube searches lead to Klipper )

I do understand not being able to hand out review samples, so if the answer is no just say so and I will buy him one on my own dime.

Thank you for your consideration,
Steven Smith

Could this be implemented into the duet's firmware? I would like to use the spaghetti detective on octoprint but still maintain the features of the duet that would other wise be disabled like my filament sensor. If they could play nice together I would love for octoprint plugins to be that much more compatible with duet and its feature set. I'm making a similar post on the octoprint feature request as well. I'm not sure which side needs to help make changes if not both.

https://www.youtube.com/watch?v=YDvFN51siMU
https://community.octoprint.org/t/host-action-commands-for-duet/40963

Where it says about a pg down
https://duet3d.dozuki.com/Wiki/Gcode#Section_Replies_from_the_RepRap_machine_to_the_host_computer

"On the latest version of Pronterface and Octoprint (1.2.0+) a special comment of the form:
// action:command
is allowed to be sent from the firmware, the command can currently be pause, resume or disconnect which will execute those commands on the host."

Is this referring to a release candidate or beta version?
I'm on the latest stable version and either I don't know how to trigger one or it is not in this version.

It seems like this is being implemented but when connected through usb the filament sensor is ignored and not reported as "action:pause" or "action:filment_out" or some other comunication that I can flag to setup the correct gcode.

Could this be implemented into the duet's firmware? I would like to use the spaghetti detective on octoprint but still maintain the features of the duet that would other wise be disabled like my filament sensor. If they could play nice together I would love for octoprint plugins to be that much more compatible with duet and its feature set. I'm making a similar post on the octoprint feature request as well. I'm not sure which side needs to help make changes if not both.

https://www.youtube.com/watch?v=YDvFN51siMU
https://community.octoprint.org/t/host-action-commands-for-duet/40963

@bearer It does indeed wait for cooling

Yeah I'm trying to write it now reading that. Is there a good way to say wait fro bed to cool to x degrees C instead of wait for heat?

I have an idea for upping my output of printing face shields for my local hospitals by using a macro to say
Print shield.gcode
execute move to eject parts from bed
repeat

If there is not repeat can I nest the macro or just copy paste the command say 10 times so I can sleep 10hrs or so.

Example
Mxxx Shield.gcode
Mxx t 5mins ;cool bed
Mxxx Shield_eject.Macro
Mxxx ;repeat or nest this macro

I found that editing this line in my config.g file improved my bltouch repeatability

M558 P9 H5 F210 T6000 A50 S0.005 ; Set Z probe type to bltouch and the dive height + speeds

Annn Maximum number of times to probe each point, default 1. Maximum, as of 2.03, is 31. Setting M558 A parameter to anything >31 set it to 0 instead of to 31
Snnn Tolerance when probing multiple times, default 0.03mm

I just set Ann really high but it only probes 2-4 times until it gets it right.

Hope that helps you

Edit:I guess after updateing I need to go down to Ann <31 after reading that copy and paste

I think there could be a few easy to implement features that would improve remaining time estimates. The first thing I would change is the way the estimate by layer works. I would think it wouldn't be so hard to change the estimate from the final z height to the last z height of actual extrusion. Many default ending G code sequences will lift the nozzle to avoid dragging and oozing across the top of the finished print. This makes (as it is now) the estimate by layer time mostly useless.

The other thing that could be awesome would be to use the built in simulation to either create a meta data file for that gcode or insert something like the m73 command through out the gcode to give very accurate time estimates. Maybe an override check box under the settings to enable this or to pre-process in the background while not printing. Or a PC/web app much like the setup process you have where you input your config.g and the gcode file to be processed and the output would have better estimates than say prusaslicer. A plugin for prusaslicer would be nice, but i would think that might be to exclusive.

Thank you for your great products
Steven

@mrehorstdmd Very useful! You've shown me 2 things today. You sir are a gentleman and a scholar. Thanks.

@mrehorstdmd Thanks! Glancing over the sheet it looks right. As for correcting the mechanical error the only precision tool I have is my pair of calipers. None of the squares at the local hardware store agree with one another so I can't know which one to trust. I don't want or have an entire machine shop at my disposal, just an ender 3 to slowly build upon as I learn the hobby. I've gotten it as close as I can by using best assembly practices from multiple youtube and reddit posts. I'm ok with letting software correcting the last little bit to get the utmost out of this cheap frame. I'm happy this feature exists and feel like it exists for newbs like me