RepRapFirmware 3.0beta12 now available
-
about to place an order for a duet 3 mainboard for a cnc build and just would like to clarify that the configuration may have a tab for cnc? i feel this is a very worthy tool for the machine and it would unlock many more options for expand ability in the future for maybe tool changing or laser /plasma cutting.... or even 5-6 axis machining
-
@denke said in RepRapFirmware 3.0beta12 now available:
So my question is, does beta 12 support M143?
There has been no change regarding
M143
in the source code since beta 11. -
@dc42 Is there a roadmap anywhere? I'm just curious as to what the development plan is, what's being worked on and what might possibly be coming down the line. Not expecting any timescales obviously, I'm just intrigued by the whole process.
-
M143 is implemented but not tested yet - and in my book, untested code is broken code.
The priorities for RRF3 development are:
- Complete the support for expansion boards on Duet 3
- Conditional GCode and object model
- Add a few missing features
-
Conditional GCode sounds amazing and incredibly powerful, look forward to that one. Thanks for the update.
-
@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
-
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.
-
@dc42 thanks for this detailed answer, End of the year sounds Great ! I will that closed to a Christmas Beer
-
Endstops are now working on expansion boards, using the main+expansion firmware builds at https://www.dropbox.com/sh/3azy1njy3ayjsbp/AACquxr2m00eV568RZg5QG5wa?dl=0.
-
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
-
@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.
-
@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
-
Thanks, I'll put further responses i that thread.
-
@dc42 yes :)! I hope I donβt miss the pre-order
-
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). -
-
@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.
-
@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.
-
@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 theHnn:nn:nn
description on there just to highlight it a little more if that's OK? -
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.