When you adjust the speed (or even the flow) you have no idea where to click to get a specific percentage. It will show you after you clicked, but sometimes you have to click a bunch of times until getting where you want. It would be nice to be able to see the value before clicking or to (also) have discrete buttons for values.
Thank you!

As I understand, the set of lcd connectors on the Duet2 Wifi/Ethernet were thought for connecting a 2004 LCD, which will never get support so they are of no use (except for using the pins for I/O and maybe for motors 9 and 10).

On the Duet Maestro, there are also RAMPS-like connectors but they are designed to plug a ReprapDiscount-like graphics LCD with rottary encoder and buzzer. And the last firmware have gone forward with supporting it, as is described here:

https://duet3d.dozuki.com/Wiki/Duet_2_Maestro_12864_display_menu_system

Now, I have a DuetWifi and I would like to fit a 12864+encoder on it. Now that the worst part is done (firmware support), I guess I can manage to make a daughter board that adapts the display to the right pins on the duet.

Questions:

• will the firmware just work, once the hardware is fitted, or will it know that it's not a maestro and disable support for it?
• can anyone (@dc42?) give some advice about it?

I'm comfortable with the electronics, just new to the duet itself.

Thank you!

Coming from marlin, I did not like some of the duet characteristics at first. I do not mind using GCODE to do all the configs, it seems daunting at first but you quickly get used to it. But the fact that the config is scattered all over the place bothered me. Also, the fact that I could not use the same values in many places and change them easily.

So I made a templating system for it, maybe you could give a try:

https://github.com/token47/duetcfgen

Hope it helps to easy part of the config work for you.

Hello!

I wonder why G0 and G1 are not affected differently by the feedrate. AFAIK G0 and G1 both exists exactly to tell the firmware the type of move, so it knows when a move is just a travel and when it is for real (effectively using the tool).

That way, I would expect the feedrate to affect only the move, not the rapid move. Makes sense? If I'm printing at 70mm/s and the travel is 150mm/s (because that is the faster the printer can move without troubles), and I decide to up the print speed to 100mm/s using the feedrate (142% in this case), I would expect the travel to STAY THE SAME, not being increased to 213mm/s along with the print speed.

But, Marlin did not do that and the RRF also does not do that. From the Duet G-Codes documentation:

RepRapFirmware treats G0 and G1 as the same command, since it's just as efficient as not doing so. [3]

Efficient, maybe.... but does not seem right, and yet most firmwares do. Why is that, when it seems so easy to make this distinction?

Thank you very much for the insights. I will try to put together the hardware part and maybe come back for a little more help

Is it possible to lock the top bar when scrolling? Like scroll the rest of the page but keep it on top always. Sometimes you need to scroll back to reach the EMERGENCY STOP button and it takes time if you are in an emergency...
Thank you!

Hello

I just made a config generator to make my life easier and though someone else might like it too, so I'm posting here.

https://github.com/token47/duetcfgen

Comments are apreciated. Thanks.

There is already stop.g that will be run at the end of the print if the sliced gcode sends an M0. I prefer to just put "M0" at the end script so I will keep the gcode at only one place, since stop.g will also be called in other circunstancies.

You can use start.g and stop.g to turn on/off specific pins on the board (configuring the pin as a GPIO using M950 and turning it on/off using M42) and wire a led or even an SSR to that pin to control something external. You can use any of the unused pins like endstops or unused pins in the expansion header.

Well, it indeed does that. I went to the console and run "M119" and "M122", and when I typed "M" again at that box it showed:

It seems that the "Default G-Codes" on the Configs "List Items" will always appear first and then the remembered ones from the console.

I miss the possibility to open the history drop down list by clicking instead of by typing.

@phaedrux It's a probe I designed myself. A crashprobe. It sits behind the HEVO carriage and is deployed by pushing it down from above (releasing a magnet). It can be easily deployed by hand (the printer will beep and wait for it) or go to the corner and press against another part. Still testing, but already much better than the older one which was driving me nuts. It has about 10mm of Z offset to the nozzle and another 6-7mm above the nozzle when retracted (I wanted a very long travel on both ways to avoid problems I was having before).

@phaedrux Thank you for the procedural steps. I'm reading about the upgrade and finding courage to do the upgrade, this will help. The reason for the delay is that my setup is complex, I have a ton of macros and some advanced configs, so I keep delaying it.

@fcwilt and @dc42 Thank you for the response. I thought fw 2.x did not have mesh.g support (I checked documentation and code, even tried it, but I could be wrong).

As I commented on OP I intend to upgrade soon, but anyway, it seems this problem would occour even on 3.x if issuing a G29 S0 directly, which is still something to consider.

@rjenkinsgb ok, maybe I was not too specific. Here is more details:

• G30 works ok, and is not related to this problem.
• Yes, the printer needs to be homed when running G29 (this means running G28 if needed). I am doing this.

The problem is still there. If the printer is homed, is near Z=0 (for whatever reason) and G29 is run, it will not lift before deploying the probe. It should (proof is that it will do it, just the order is reversed).

Actually i could move Z in deployprobe.g using G91 + G1 H2 + G90 like I do in homeall.g macro, but that would probably another lift on top of the homing lift, it would be better to just do things in the right order.

I just switched my z probe for one that is much longer and now I noticed a problem that was not noticeable before.

I'm using Firmware: RepRapFirmware for Duet 2 WiFi/Ethernet 2.05.1 (2020-02-09b1)

When running G29 S0, it will both deploy the probe for me, and also take into consideration the height needed for the probe to trigger (i.e. it moves to the first probe point while adjusting Z to my z-probe-offset + nozzle-dive-height).

The problem is that it deploys the probe BEFORE moving Z to the right level, and when the nozzle is too close to the bed at the moment I run G29 S0, it will deploy the probe, the probe will touch the bed while deploying and then be dragged over while adjusting Z and moving to the first point.

This is not a problem if you have a probe with a very small deploy travel distance, or if you are already high enough before deploying, or if you have a non-deployable probe like a inductive one. But it will be a problem if you have a probe with a very long travel (my current one has 10mm travel + 3mm dive) and it is below that height when G29 is run.

I cannot try to lift Z in my probe deploy macro because it will also be ran when running G28 and Z is not homed yet so it will not work. And I don't have mesh.g yet in the version I'm running (I'm planning to upgrade soon).

I think the order of DEPLOY and MOVE-Z should be reversed. Thoughts?

Thank you

First, you have to configure the "virtual endstops" to use the stall instead of physical switches. You do that putting this in your config.g:

; Endstops
M574 X1 Y1 S3 ; Set endstops to use sensorless motor load detection
M915 X Y E S3 F1 H200 R0 ; set stall motor sensitivity and actions

This is enough for it just to work as if you had switches installed. Anytime the motors stall, the enstops will be triggered.

Now, when doing the homing, you must use the S1 paramenter (or the H1 parameter on FW 2.02 and later) in your G0/G1 commands so it respects endstops.

H1 terminate the move when the endstop switch is triggered and set the axis position to the axis limit defined by M208. On delta printers, H1 also selects individual motor mode as for H2. Normally used with relative motor coordinates (see G91).

For example, my homex.g is like this:

G91 ; relative positioning
G1 Z${Z_HOMING_LIFT} F$((Z_SPEEDS[MEDIUM]*60)) ; lift Z relative to current position
M98 P"0:/sys/m_set_homing_speeds.g" ; set lower speeds and accelerations
M913 X60 Y60 ; set X and Y motors to low current for homing
G1 S1 X-$((X_LIMITS[MAX]+100)) F$((XY_SPEEDS[HOMING]*60)) ; move quickly to X axis endstop and stop there (first pass)
G1 X5 F$((XY_SPEEDS[HOMING]*60)) ; go back a few mm
M913 X100 Y100 ; set X motor to 100% of the normal current
M98 P"0:/sys/m_set_normal_speeds.g" ; set normal speeds and accelerations
G90 ; absolute positioning

Don't mind the variables inside the script, I have a pre-processor that replaces them before uploading to the duet by ftp. Pay attention to the logic and replace your values.

There are certain requirements you have to take care when using sensorless homing. For example, it will only sense when the motor is above certain speed, if too low, it won't detect. So do not home in very low speeds. Also, if you lower motor current to about 60% it will help the process, at full current it may bump too hard on the limits. I also decrease accelerations, speeds and jerk in those macros and restore them afterwards, I have seen better results with that.

You can use start.g and stop.g to turn on/off specific pins on the board (configuring the pin as a GPIO using M950 and turning it on/off using M42) and wire a led or even an SSR to that pin to control something external. You can use any of the unused pins like endstops or unused pins in the expansion header.

I do it the opposite way. I always edit stuff on my pc and upload changes. I made a script to automate that. You can find it at https://github.com/token47/duetcfgen

It works on linux, cygwin and WSL.

This is what I use and have tuned over the years:

# speeds, accelerations, jerk and moves
JERK_NORMAL=([X]=12 [Y]=12 [Z]=5 [E]=10) # max instantaneous speed changes (mm/s)
JERK_HOMING=([X]=0 [Y]=0 [Z]=0 [E]=0 ) # max instantaneous speed changes (mm/s)
ACCEL_NORMAL=([X]=2500 [Y]=2500 [Z]=100 [E]=9000 [PRINT]=2500 [TRAVEL]=2500) # (mm/s^2)
ACCEL_HOMING=([X]=500 [Y]=500 [Z]=50 [E]=250 [PRINT]=500 [TRAVEL]=500) # (mm/s^2)
MAXSPEEDS=([X]=150 [Y]=150 [Z]=30 [E]=30) # max speeds (mm/s)
XY_SPEEDS=([SLOW]=20 [FAST]=150 [HOMING]=80) # speed for X or Y movements
Z_SPEEDS=([SLOW]=3 [MEDIUM]=8 [FAST]=20) # speed for Z movements
E_SPEEDS=([SLOW]=10 [FAST]=30) # speed for E movements

These are variables in the tool I wrote to parse and export a config for me, but you can see the values that matter there.

BTW the tool is here if you want to play (works in linux or windows/cygwin).
https://github.com/token47/duetcfgen