RepRapFirmware 3.0beta12 now available

littlehobbyshop

Conditional GCode sounds amazing and incredibly powerful, look forward to that one. Thanks for the update.

steevebecker

@dc42 Thanks for this rough roadmap.
could you tell us what is the plan for 3HC expansion board ?
Because Can-FD is promissing if all features are working on 3HC (Z probe / servo / Thermocouple ...)

Conditionnal Gcode sounds great too, even I prefer to have features working first

dc42

The following items connected to expansion boards work in beta 12:

Stepper motors, temperature sensors (inc. thermocouple and PT100 but not DHT), heaters (but not heater protections, and not heaters controlled by sensors on a different board), fans (including tacho readings, but excluding fans thermostatically controlled by sensors on a different board).

In the current committed source code, endstop switches are also working; but I need to add a safety feature before I release that.

The following are either not implemented on expansion boards or implementation is in progress, and therefore not working yet:

GPIO output (M42), servo output (M280), trigger inputs, stall detection endstops, Z probes, reporting of stepper driver errors and warnings, additional diagnostics inc. crash reports.

Assuming no component shortages, I estimate that first deliveries to the 3HC to customers will be 5 to 6 weeks from next Monday. So we may just miss delivery before Christmas, in which case deliveries won't start until after New Year. We'll have a better idea next week and we may open a pre-order.

steevebecker

@dc42 thanks for this detailed answer, End of the year sounds Great ! I will that closed to a Christmas Beer

dc42

Endstops are now working on expansion boards, using the main+expansion firmware builds at https://www.dropbox.com/sh/3azy1njy3ayjsbp/AACquxr2m00eV568RZg5QG5wa?dl=0.

smoki3

I still miss a fix for the tool changer scripts, that the Z axis is not moving while tool changing. Also happens on 2.xx

dc42

@smoki3 said in RepRapFirmware 3.0beta12 now available:

I still miss a fix for the tool changer scripts, that the Z axis is not moving while tool changing. Also happens on 2.xx

Please provide a link to the post where you described this. Or, if it is in a thread with lost of other stuff, start a new thread.

smoki3

@dc42 said in RepRapFirmware 3.0beta12 now available:

@smoki3 said in RepRapFirmware 3.0beta12 now available:

I still miss a fix for the tool changer scripts, that the Z axis is not moving while tool changing. Also happens on 2.xx

Please provide a link to the post where you described this. Or, if it is in a thread with lost of other stuff, start a new thread.

Bug in 2.03, 2.04RC1 and latest 3.0 beta: https://forum.duet3d.com/topic/11343/new-reprapfirmware-3-0-early-beta/30

Its already on the bug list. but its a bit hidden. You may have fogotten

I copied the conversation in this thread:

https://forum.duet3d.com/topic/12920/tool-change-moving-in-axis-without-calling-them

dc42

Thanks, I'll put further responses i that thread.

hanshogeland

@dc42 yes :)! I hope I don’t miss the pre-order

keyz182

M308 S1 Y"rtdmax31865" P"spi.cs1" A"RTD1"
M950 H1 C"e0heat" T1                                    ; create nozzle heater output on e0heat and map it to sensor 1
M143 H1 S360                                            ; set temperature limit for heater 1 to 360C
M307 H1 B0 S1.00                                        ; disable bang-bang mode for the nozzle heater and set PWM limit

M308 S2 Y"rtdmax31865" P"spi.cs2" A"RTD2"
M950 H2 C"e1heat" T2                                    ; create nozzle heater output on e1heat and map it to sensor 2
M143 H2 S360                                            ; set temperature limit for heater 2 to 360C
M307 H2 B0 S1.00                                        ; disable bang-bang mode for the nozzle heater and set PWM limit

Does the above look right for a pair of PT100 sensors plugged into the PT100 Daughter board on a Duet 2 Wifi?

The second tool appears correct, but the first is stuck at ~210°C (even though it's cool to the touch).

I'm also struggling to work out how to have a fan be thermostatically controlled by mcutemp, which I'm pretty sure I had in V2 (though, I may be mistaken).

T3P3Tony

@hanshogeland
https://forum.duet3d.com/topic/12949/duet-3-expansion-3hc-now-available-for-pre-order

dc42

@keyz182 said in RepRapFirmware 3.0beta12 now available:

M308 S1 Y"rtdmax31865" P"spi.cs1" A"RTD1"
M950 H1 C"e0heat" T1                                    ; create nozzle heater output on e0heat and map it to sensor 1
M143 H1 S360                                            ; set temperature limit for heater 1 to 360C
M307 H1 B0 S1.00                                        ; disable bang-bang mode for the nozzle heater and set PWM limit

M308 S2 Y"rtdmax31865" P"spi.cs2" A"RTD2"
M950 H2 C"e1heat" T2                                    ; create nozzle heater output on e1heat and map it to sensor 2
M143 H2 S360                                            ; set temperature limit for heater 2 to 360C
M307 H2 B0 S1.00                                        ; disable bang-bang mode for the nozzle heater and set PWM limit

Does the above look right for a pair of PT100 sensors plugged into the PT100 Daughter board on a Duet 2 Wifi?

The second tool appears correct, but the first is stuck at ~210°C (even though it's cool to the touch).

Yes, that looks correct. What reading do you get if you connect the 100R resistor to the second input instead of the PT100?

I'm also struggling to work out how to have a fan be thermostatically controlled by mcutemp, which I'm pretty sure I had in V2 (though, I may be mistaken).

Create a sensor for mcutemp, then use that sensor number ni the H parameter of your M106 command. In RRF3 the M106 H parameter refers to a sensor number, not a heater number.

keyz182

@dc42 said in RepRapFirmware 3.0beta12 now available:

@keyz182 said in RepRapFirmware 3.0beta12 now available:
M308 S1 Y"rtdmax31865" P"spi.cs1" A"RTD1"
M950 H1 C"e0heat" T1                                    ; create nozzle heater output on e0heat and map it to sensor 1
M143 H1 S360                                            ; set temperature limit for heater 1 to 360C
M307 H1 B0 S1.00                                        ; disable bang-bang mode for the nozzle heater and set PWM limit

M308 S2 Y"rtdmax31865" P"spi.cs2" A"RTD2"
M950 H2 C"e1heat" T2                                    ; create nozzle heater output on e1heat and map it to sensor 2
M143 H2 S360                                            ; set temperature limit for heater 2 to 360C
M307 H2 B0 S1.00                                        ; disable bang-bang mode for the nozzle heater and set PWM limit
Does the above look right for a pair of PT100 sensors plugged into the PT100 Daughter board on a Duet 2 Wifi?

The second tool appears correct, but the first is stuck at ~210°C (even though it's cool to the touch).
Yes, that looks correct. What reading do you get if you connect the 100R resistor to the second input instead of the PT100?

Just been fiddling around - it appears it may be a connection issue (reading varies a lot, even going up to 2000C based on touching the wire), so going to check/rewire that first. Will check the 100R if I have one.

I'm also struggling to work out how to have a fan be thermostatically controlled by mcutemp, which I'm pretty sure I had in V2 (though, I may be mistaken).

Create a sensor for mcutemp, then use that sensor number ni the H parameter of your M106 command. In RRF3 the M106 H parameter refers to a sensor number, not a heater number.

Ahh, gotcha. Thanks.

keyz182

@dc42
Yup, it was a bad connection Added a dab of solder to the crimped connections to firm them up a bit and all is good.

MCU temp is working perfectly now too. Had missed the bit about M106 H now being sensor rather than heater. I see it's in the notes on the wiki for M106 now. I added this (this refers to sensor number in RRF_3) to the end of the Hnn:nn:nn description on there just to highlight it a little more if that's OK?

keyz182

New issue - porting over my sensorless homing settings.

config.g

M915 X Y S4 F0 H200 R1

homeall.g

G91                     ; relative positioning

M913 X45 Y45		; drop motor currents to 45%
M915 X Y S4 R0 F0     	; set X and Y to sensitivity 2, do nothing when stall, unfiltered

G1 H2 X20 Y20 Z5 F6000  ; lift Z relative to current position
G1 H1 X-281 Y-325 F6000 ; move quickly to X or Y endstop and stop there (first pass)
G4 P150
G1 X20 Y20            	; move away from home
G4 P150
G1 H1 X-281 F3600       ; home X axis
G4 P150
G1 H1 Y-325 F3600       ; home Y axis
G4 P150
G1 X20 Y20 F6000        ; go back a few mm

M400                  	; make sure everything has stopped before we reset the motor currents
M913 X100 Y100		; reset motor currents

G90                     ; absolute positioning
G1 X125 Y150 F3600      ; Move to bed centre
G4 P500                 ; pause
G91                     ; relative positioning

; BLTouch Z
G30 			; Do a single probe to home our Z axis
G90 			; Make sure we are in absolute mode
G1 Z10 F360 		; Rapidly move the Z axis to Z=10.

It gets up to the second G1, but as soon as it hits an axes (aka the "endstop") it stops homing and ignores the rest of the script.

dc42

There is a known issue with stall detect homing in the RRF3 beta releases up to and including beta 12. The more recent build on Dropbox includes a change that may fix it.

keyz182

Gotcha. The dropbox build also fails in the same way unfortunately.

dc42

Thanks, on my list to look at after FormNext.

dc42

@keyz182, is this a Cartesian or a CoreXY machine?

Please post your complete config.g file.