A clue is that if PanelDue or DWC can't tell you the amount of filament required by the print, the file may be incomplete.

This used to be a particular problem with slic3r, because when writing the file it doesn't keep it open in exclusive mode, making it possible for you to upload it to the Duet before slic3r has finished writing it. I don't know if that has changed since I last used slic3r about 2 or 3 years ago.

@dc42 said in Add Drive/Extruder Parameter to M207:

It sounds like per-tool is the way to go, but this feature still needs to be specified. Assuming that I add an additional parameter to specify the tool number:

Should a M207 command that doesn't specify a tool number affect only the current tool? Or all tools? Or something else?

If no parameter is given it should be the global default but not overwrite any tools that were explicitly configured. This way M207 can be in config.g without a tool parameter to give a good starting point for all tools or just to set them for single extrusion setups or users who do not have independent settings for materials. Then, the beginning of a gcode file would include the more specific configuration depending on what is set in the slicer custom gcode. This would also allow for the current behavior to be mimicked if no tool numbers are ever specified.

If a second print is run without resetting the firmware, then the second file would contain the specific M207 tool configs for that print and update them as needed.

When a new tool is created, what M207 parameters (if any) should it inherit?

I think it should inherit the global default since this is how the current implementation would behave.

I don't want to break the current behavior as it is working well for me now and I know for other people. I just want to add the possibility of having it be configured per tool to allow me to expand into other slicers while still reducing the amount of manual configuration I have to do for each print/material.

You should also be able to set different extrusion multipliers using the sliders in Duet Web Control or the extrusion multipliers in PanelDue, because the underlying M221 GCode command allows the extrusion multiplier to be set per extruder drive.

M917 is only supported on the Duet Maestro. I have corrected the documentation to say that. The time before reduction to standstill current is a little under half a second. The reduction is done gradually over a period of about 50ms.

@dc42 I think averaging is the way it is handled in Marlin and Repetier (just guessing though). As I get bad repeatability as well - partly due to https://github.com/dc42/RepRapFirmware/issues/210

As a reminder, I opened an issue on github

Googliola created this issue in dc42/RepRapFirmware closed M558 F parameter only applied during approaching of probe #210

@genghisnico13 said in Force M703 execution:

@wilriker Thanks, last night I configure it that way, but i'm not so sure about this:
"If you have T0 also in your config.g this should then execute tpost0.g", as far as I understand it all the t macros are only executed if a different tool is selected, and since I only have one, T0 doesn't execute any macro.
I tried putting T0 in config and no, tpost0 is not executed.

Actually, I never bothered to check because my tpost0.g is more or less empty (I also have just this one tool)

It would be nice to execute it before each print because I usually tweak it between prints until I find the perfect settings.

In this case it would make most sense to have it in the start codes, I think. This does what you need plus it does not require any changes in the firmware. 😉

Have you also updated the DWC version? It may only be the 2.02 versions that have fixed the too many files in a folder bug.

Easiest way to resolve without updating would be to move the SD card to a PC and manaully moving the gcode files into folders.

@phaedrux Thanks, thas perfect.... the answer has arrived before posting the question .... bufff, how fast.

Thank you

Are you trying to do this: manual bed leveling assistant?

@punamenon said in Wipe and prime motion at the end of resume.g:

...Basically, if you watch the nozzle during a resume.g you will see it move to where it is hovering over the last print location, then as it drops onto the part to begin printing again, it extrudes/oozes some filament into the air. This tail is then deposited onto the part (usually at some point on the skin) and the printing begins again.

That means you don't have your resume.g file set up correctly. Before the G1 E move to re-prime the nozzle, you need G1 R1 X0 Y0 Z0. If you have had your Duet for a long time, you may have G1 R1 with no other parameters there, but that won't work any more.

Regarding the dialog that disappears by itself, in the DWC under "Settings" > "User Interface" in the "Notifications" block you will find an option "Automatically close user-generated firmware messages" - just check if perhaps this is enabled; also there is a "Default Notification Timeout" setting as well.

@dc42 THANK YOU!!! This was the final piece of the puzzle that I needed to get the project working.

Octolapse style timelapse videos on a DSLR camera triggered wirelessly by the DUET Wi-Fi: https://youtu.be/CwHVQ81GfXw

@dc42 Great! will do!

Before it is implemented in the firmware, you could do that with an external device: a simple Arduino connected to the PanelDue port, sending a pause command, triggering you camera, then sending a resume command.

@punamenon M400 will force a clear of the movement buffer before continuing. Perhaps add that before the pause macro.

@fcwilt, that would be possible, however M665 is fairly standard for configuring delta printers.

@fcwilt said in Suggestion for behavior of G30 S-1:

I was only thinking of those cases where the Z-probe was being used to probe the bed and was moving towards the bed.

Sure; but in general the movement to the probe point is an XYZ move.

Yes, it will be in the next 2.02beta release.

@dc42 Thanks - that should help debug.