@alankilian Already did that. thanks though.

G1 H1 X800 F5000 ; move quickly to X axis endstop and stop there (first pass)
G91
G1 H0 X-5 F500 ; go back a few mm

G1 H1 X500 F400 ; move slowly to X axis endstop once more (second pass)
G90

; homey.g
; called to home the Y axis
;
; generated by RepRapFirmware Configuration Tool v2 on Wed Apr 03 2019 13:46:49 GMT-0600 (Central Standard Time)

G1 H1 Y-1400 F1600 ; move quickly to Y axis endstop and stop there (first pass)
G91 ; relative mode
G1 Y5 F6000 ; go back a few mm

M584 Y1
M574 Y1 S1 P"io1.in"
G1 H1 Y-10 F360 ; move slowly to Y axis endstop once more (second pass)
M584 Y2
M574 Y1 S1 P"io2.in"
G1 H1 Y-10 F360

M584 Y1:2
M574 Y1 S1 P"io1.in+io2.in"
G90 ; exact mode

Starting to configure my Duet3 board for use with a 60w CO2 laser which I'm building.. I've got the M7/M8/M9 figured out and a E-Stop. One thing that concerns me is that my homing scripts use G1 for moving the axis's. I've modified them to use G0, but that causes the axis to move at full rate as in rapid. you can not use a F statement in order to control the speed. Leaving me to use G1 which my understanding is that it is used for laser movement with power (S). This could be an issue as the S statement is sticky I thought so any movement of the axis ie homing, will cause the laser to fire due to the use of G1.

I believe that G0 needs to respect a feedrate sent with the command instead of just ignoring it. I'm using the last release of RRF3 along with DWC-CNC

is there a limit to the number of objects which are counted by the plugin? I have a print bed where I added 28 or so objects and needed to cancel 3 of them. I could only cancel 1 as the other 2 and several others were not in the object list. The plugin also only reported 20 objects instead of the 28 that were being printed. Having the number user-configurable would be a nice thing if so

tried it for the first time yesterday on a couple of co2 laser tube mounts. Something that could use the arc welder function since the tube is being supported by a half round support. I found the gcode file actually increased in size as well as not working as advertised. The tube support is still segmented.

This has been requested many times. I even went so far as to provide a patch. while not perfect, it did work. Filament has to be counted "per filament type". While useful, this is not as useful as counting per filament roll.

perfect. that fixed it. I believe the duet2 uses 4700 as the default. I believe this should be documented somewhere, but I was unable to find it.

I upgraded to a Duet3 from a Duet2 running RRF3. Everything was working as it should with the Duet2. Since the replacement of the board however, I'm having a odd issue with my thermisistor's. They are reading 15 degrees too low. Right now they should be reading 20 degree's which is the temp in my shop. They are instead reading 5.4 degree's.

M308 S0 P"temp0" Y"thermistor" T100000 B4138 R4700  A"Bed"; bed thermistor V3
M308 S1 P"temp1" Y"thermistor" T100000 B4138 R4700   A"Hotend"; e0 temp sensor V3
M308 S2 P"mcu-temp" Y"mcu-temp" A"Duet"
M308 S3 P"drivers" Y"drivers" A"Drivers"
M950 H0 C"out0" T0 ; heater 0 uses the bed_heat pin, sensor 0
M950 H1 C"out1" T1 ; heater 1 uses the e0_heat pin and sensor 1

M140 H0																		  ; Enable bed heater
M143 H0 S120                                                                  ; Set temperature limit for heater 0 to 120C
M143 H1 S340                                                                  ; Set temperature limit for heater 1 to 300C

; RRF V3
M307 H0 A46.4 C211.7 D14.8 S1.00 V24.6 B0 ; bed V3
M307 H1 A230.7 C115.6 D4.9 S0.90 V23.9 B0  ;; V3 e3d 24v hotend

If I change the R value to about 2200 or so, I can get the temp in range. Same with playing with the H value. This is not ideal however.

turn off the network, set your parameters for the wifi session. and then turn back on the network. also don't leave the m587 enabled in your config.g. once the esp8266 is programmed, it will remember the ssid/password and goto that network upon bootup

seems to be some issues compiling what is in the git repo under windows. some define's and some missing font functions. I don't know enough about idf.py to begin fixing the issue however.

it's wired to the fan2 terminals on the board. I tried without the buck converter and reducing the available speed but of course that just blew up the fan.