Pull request submitted: https://github.com/dc42/RepRapFirmware/pull/213

I hope you find it agreeable!

(I also added a bit for selecting between single and differential channels)

ajquick opened this pull request in dc42/RepRapFirmware closed CurrentLoopTemperature Multiple Channels on Chip #213

@dc42 having everything that goes to the console in the log (when configured to do so) + every debug output (when similarly configured) would be the best option. At all times as well not just when printing from SD. As long as there is sufficient bandwidth to write to the SD at the same time as reading. may need a RAM buffer.

Awesome, thank you!

Yeah, maybe you can replace the layer graph. for a toolpad preview .

The X40 and Y-40 move is basically to negate the nozzle offset of the BLTouch, so that I am probing the same spot that the nozzle actually touches.

The bed move by 10 was basically done to ensure enough clearance and dive height while I was still narrowing down the dive height. It also gives a longer dive height to allow for the probe to settle. That plus the lower speeds is an attempt to give the probe the best chance of getting a repeatable measurement.

I also have a macro for manual bed leveling and then another for mesh grid measurement. I don't run these very often, but they are nice to have when you need them.

1_1538593590722_0_Grid Compensation Assist.g
0_1538593590721_0_Auto Bed Level Assist.g

And there's also this bundle for tuning:
https://forum.duet3d.com/topic/6181/tuning-macros-menus-accel-jerk-retraction-pressure-advance

@dc42 Oh that's excellent! Thank you.

@phaedrux 👍Thanks - made me smile.

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.