Hi Everyone,

I'm part of the team at Modix3D, where we make big printers (up to 1x1x1m, or 60x60x180cm)

We've been using Duet 2 and Duex5 control boards in our printers for the past 2 years, and we're a big fan of the ease of development that RepRapFirmware brings.

I've been working with the team over the past few months to bring some large updates to the configuration and macro files, trying to start to use some of the features that RepRapFirmware 3 bring, in particular G-code meta commands are a game-changer.

One area that we use G-code meta commands heavily is in the homing files. The (move.axes[0].max or min) is something that has made it possible to use the same homing commands across all printers, as it references things from the config.g files.

Things like that have made development a lot easier.

We also use it in the Duex5 enabled printers to do do fully automated tilt calibration, until the tilt of the corners is within a certain range ( less than 0.02mm of adjustment)

While our files aren't the most advanced or fancy ones, hopefully some of our uses can inspire or help you in your own development. We've definitely learned a lot by reading these forums and are hoping to at least give back a little

you can see our latest configuration and macro files on our GitHub: https://github.com/Modix3D/Modix-V3-configuration-and-Macro-files

@mikeabuilder
I've gone through this list and added all the gcode meta commands, including var and param: https://docs.duet3d.com/en/User_manual/Reference/Gcode_meta_commands

In notepadd++, to change the stylers you can go to language -> user defined languages -> define your language -> pick the language from the dropdown and then you can change the stylers

For the var and param for example. they are in the 3rd group. You can change the styler, or put it in a different styler.

I've used a VERY basic grouping, so absolutely do use and adapt it to your own liking! If you send me a message or a Github pull request I'll very gladly add it to the UDL!

If for whatever reason you want to store the Z-offset outside of the config.g file (in this example in a file named config_probe.g), here is the method I've found out to work quite well.

This method works for RepRapFirmware 3.4 and up, as we need to use the ability to write to a file using the echo command. It has been tested on 3.4.1

For more info, see https://docs.duet3d.com/User_manual/Reference/Gcode_meta_commands#echo-command

The macro also allows you to automatically compensate for using of a known thickness shim, using the var probing_tool setting at the start of the macro.

Z-offset macro:

var probing_tool = 0.000
; This allows you to compensate for whatever tool you use to measure the nozzle distance.
; It is set to 0.000 by default, you can set this to the thickness of the tool or paper you use for the Z-offset calibration
; A sheet of paper is on average 0.05 to 0.10mm thick.

M291 S3 R"Heating up nozzle" P"Wait for the nozzle to reach printing temperatures"
M568 P0 S215		; set tool 0 (primary hotend) temperature to 215c
T0			; select tool 0 (primary hotend)
M116 P0 H5		; wait for temperature to reach within 5c of set temperature

M300 S666 P666               ; beep
M291 S3 R"Setting the Z-offset Height" P"Press OK to continue, or CANCEL to abort"
G28                          ; home all
G29 S2                       ; cancel mesh bed compensation
M290 R0 S0                   ; cancel baby stepping
G90                          ; absolute movements

G1 Z10
G1 X100 Y100 F1800
G4 P0

M300 S1111 P666              ; beep
M564 H1 S0                   ; ignore axis limits
M291 S2 R"Test Z Probe Trigger Height - Step 1" P"Place a paper sheet under the nozzle and raise the bed until slight friction can be noticed" Z1 ;

G92 Z0                       ; the nozzle should now be just touching the bed so set the logical Z position to match the physical Z position
M300 S666 P666               ; beep
G1 Z8 F300                   ; insure Z position will allow for probing
G4 P0						 ; wait for the movement to stop

M291 S2 R"Test Z Probe Trigger Height - Step 2" P"Please remove the paper sheet and wait for the bed-probing to begin" ;
G30 S-1                      ; probe the bed and report the Z probe trigger height
M564 S1 H1                   ; respect axis limits

;M291 S2 R"Test Z Probe Trigger Height - Step 3" P"Copy the reported height value on the G-Code console and paste it into the config_probe.g file"

var Z_auto_offset = {sensors.probes[0].lastStopHeight+var.probing_tool} ; math to calculate the BLTouch offset
echo >"0:/sys/config_probe.g" "G31 Z"^{var.Z_auto_offset}				; write the Z-offset to the config_probe.g file

echo "the Z-offset has been stored in the config_probe.g file. The Z-offset is", var.Z_auto_offset, "mm"

G4 P0						 ; wait for the movement to stop
G1 Z10 F300                  ; Lift up the nozzle again so it's not pressed against the bed surface

config_probe.g :

G31 Z1.5 

It's a fairly simple macro, but if there are any questions let me know

I have updated the UDL I made with better colors based on the latest RRF version, with both a dark mode and light mode skin

I was however not able to figure out how to match the styling of certain parts. RepRapFirmware for example does X200 with the X being either white/black, and then the 200 part having color.

For the life of me, I could not figure out how to implement that behavior, so I just grouped them as one

https://github.com/ComedianTF2/RepRapFirmware-UDL-For-Notepad

When uploading a filament configs zip with the wrong files, the error message states "fiels" instead of "files"

Version: Duet Web Control 3.4.5

@droftarts thanks, have added a feature request:

https://github.com/Duet3D/RepRapFirmware/issues/1103

ComedianTF2 created this issue in Duet3D/RepRapFirmware

open [FeatureRequest]: Assigning multiple heaters heaters for a single bed using M140 P0 H0:1 #1103

I've created a super simple UDL, I use the night mode in notepad++, not tested it with white background

https://github.com/ComedianTF2/RepRapFirmware-UDL-For-Notepad

@T3P3Tony @droftarts

The 'Driver Enable Polarity' (En_Pol) jumper was on the left position, set to GND

Flipping the M569 R value from R1 to R0 fixed the issue. I think that by re-sending the M569 values, it basically sent the drive enable command to 0, which then allowed things to work.

Thanks for the support, I read the post and thought I had tested the R value inversion, but for some reason I must have done that testing incorrectly before, which caused me to not look at it properly until now.

@dc42 Sadly this did not trigger the calibration prompt

Downgrading to 1.24 and then back to 3.4.1 did the trick, it erased the calibration data going back to 1.24 and triggered the prompt going both to 1.24 and then again when going to 3.4.1.

@grahamsoukup

Make sure to update the configuration and macro files to those compatible with RepRapFirmware 3.4.1

The instructions can be found on the modix support site, and you can download them here

https://github.com/Modix3D/Modix-V3-configuration-and-Macro-files/releases/tag/v3.4.1.a

@droftarts thanks, have added a feature request:

https://github.com/Duet3D/RepRapFirmware/issues/1103

ComedianTF2 created this issue in Duet3D/RepRapFirmware

open [FeatureRequest]: Assigning multiple heaters heaters for a single bed using M140 P0 H0:1 #1103

Tested it out using both 3.5.4 and 3.6.0 RC1

@droftarts

At the moment, using M140 P0 H0:1 doesn't seem to work very well. If I then send M140 P0 S60, it will only heat it up on heater 0, not on heater 0 and heater 1

I'm using the above code, but now with M140 P0 H0:1 instead of the two separate lines

With that, M140 P0 S60 only heats up H0, and M140 S60 does the same

Using the M140 documentation, if you have 2 or more bed heaters, you start to run into issues if you want to heat up both bed heaters

https://docs.duet3d.com/User_manual/Reference/Gcodes#m140-set-bed-temperature-fast-or-configure-bed-heater

Using M140 S60, only the first bed heater heats up
Using M140 H0 S60, followed by M140 H1 S60, it only heats up the second bed heater

You have to use M140 P0 S60, followed by M140 P1 S60 for it to work properly

Sadly M140 P0:1 S60 doesn't seem to work

Using the following bed related configuration

M308 S0 P"temp0" Y"thermistor" A"Bed0" T100000 B4725 C7.06e-8		; configure sensor #0
M950 H0 C"out1" T0													; create heater #0 
M143 H0 P0 T0 C0 S140 A0											; configure heater monitor #0 for heater #0
M98 P"0:/sys/PID/PID_tune_Bed0.g" R1								; PID settings
M140 P0 H0															; configure heated bed #0  
M308 S1 P"temp1" Y"thermistor" A"Bed1" T100000 B4725 C7.06e-8		; configure sensor #1 
M950 H1 C"out2" T1													; create heater #1
M143 H1 P0 T1 C0 S140 A0											; configure heater monitor #0 for heater #1
M98 P"0:/sys/PID/PID_tune_Bed1.g" R1								; PID settings bed #2
M140 P1 H1															; configure heated bed #1  O

Thanks, I've the macro workaround works for now, but a more integrated solution would be great. I've added a feature request on the github for the paneldue integration.

When using a belt printer, the slicer and thus the printer is setup using the Z axis as the belt axis, while the Y axis is the up/down movement.

Now, it's possible to babystep using M290 Y<value>, and when sending these commands everything works all fine and dandy

However the default paneldue (7i) or web interface babystepping buttons are set to always apply the babystepping to the Z (belt) axis.

Is it possible to adjust the default babystepping axis? I was thinking of maybe using the daemon.g to translate the Z babystepping into Y babystepping, but I'm not really happy with that idea as there would be significant delay between the babystepping is applied and it getting applied on the correct axis.

@T3P3Tony @droftarts

The 'Driver Enable Polarity' (En_Pol) jumper was on the left position, set to GND

Flipping the M569 R value from R1 to R0 fixed the issue. I think that by re-sending the M569 values, it basically sent the drive enable command to 0, which then allowed things to work.

Thanks for the support, I read the post and thought I had tested the R value inversion, but for some reason I must have done that testing incorrectly before, which caused me to not look at it properly until now.

@T3P3Tony

I will be able to check that in January, once I'm back from holidays

@droftarts

Same, will test it out in January once I'm back. The wiring I've done per the guide you've shown. I had missed the driver enable polarity jumper, so that's quite likely the issue there.

With re-sending the commands we were able to get the printer up and running, and the printer has completed a successful print, though hopefully we won't need to use the driver_enable.g file I used before with the fixes recommended.

Thanks both for the help, I'll enjoy the Christmas break for now and get back to it in Jan

@T3P3Tony it's on 3.5.4

After further testing, it seems that sending a small move command, after which sending the M569 command seems to enable them reliably.

At the bottom of the config.g I've added a M98 command calling for motor_enable.g, with the contents below

M98 P"motor_enable.g" ; enable motor at boot

M564 H0 S0					; allow unhomed moves + moves out of min/max area. Only for testing. Remove later on
G91 						; relative moves
G1 X0.1 					; move 0.1mmm
G1 Y0.1 					; move 0.1mmm
G1 Z0.1						; move 0.1mmm
M569 P0 S0 R1 T2:2:5:2.5	; X axis, Drive 0, active high enable, 2us minimum step pulse, 2 us minimum step interval, 5us DIR setup time and 5us hold time
M569 P1 S0 R1 T2:2:5:2.5	; Y axis
M569 P2 S0 R1 T2:2:5:2.5	; Z axis
M564 H1 S1 				; re-enable safety stuff