Topics created by shirnschall

@shirnschall After trying to get this to work for weeks, I found the error right after posting.

I used the old RRF 2

M106 F25000

to set the pwm frequency when it has changed to

M950 Q25000

in RRF 3.
The fans now work down to around 40% as expected.

@Th0mpy @Phaedrux Thank you!

@dc42 Thank you for the clarification 😊
I have already updated to the new version.

@oliof I think I was using .6 or .7 with a long Bowden tube (as recommended on the duet PA website). I have since switched to a direct drive extruder (lgx ace), so this is really no longer an issue for me.

@dc42 Sounds great. Thank you 🙂

@dc42 Thank you 🙂

@dc42 That is interesting, I guess I will give Cura a try.

I really thought about your previous comment and how the duet2 has not enough ram for such a feature.
I am not very familiar with the hardware limitations of the duet boards but this is how I would do it:

When simulating the print add a comment to the end of each line with the time at which this command is executed during simulation Measure the time it takes for each tool to warm up during the initial heat-up (when the print starts) Parse the gcode file line by line until we find a Tn command Parse the gcode file backwards, line by line (starting from the last character in each line until we find the ';') starting in the current line (where we found the Tn) If we find a timestamp at the end of a line such that the distance from this timestamp to the one at the tool change command is greater than the tool heat-up time, insert the gcode command to start heating up the tool in this line

I am not sure if this is a viable method.

Are you getting the Ethernet or the WiFi module? As far as i know, its one or the other. And prints are loaded onto and ran from the SD card regardless. You could unmount the SD card, put your prints on it and remount it.But you'd still need a way to get to the Web Control to run your paths, the WiFi or the Ethernet. Unless you have a panaldue which also has its own SD card.

Update:
after measuring the movement of each individual part of the z-axis gantry it looks like the leadscrew nuts are worn out. @1ri if the auto tram still does not converge after I replace the nuts I will try different fadge factors 🙂

Just take the home out of your slicer start gcode.

If the printer is homed, everything works just like today.

If the printer is NOT homed, it won't move, and the job will complete in a few moments. You can then home and "print again".