Firmware 2.02 Release candidate 3 now available
-
I confirm that there is a problem with M600 in the 2.02RC firmware. I will fix it in 2.02RC4.
-
M116 now accepts an optional S parameter to specify the acceptable temperature difference
Thank you for the implementation!
Is working!
-
I just set up my new Maestro
Firmware Name: RepRapFirmware for Duet 2 Maestro
Firmware Electronics: Duet Maestro 1.0
Firmware Version: 2.02RC3(RTOS) (2018-10-17b2)
Web Interface Version: 1.22.4-b1Everything works nicely except the 12864 LCD.
I need to press reset on the Display for it to display something. On initial boot it shows nothing.
But the display text is garbled:This is my menu.
text R1 C1 F0 T"CoreXY"
text R15 C1 F0 T"Bed temp "
value N180 W30
text T" actual "
value N80 W30
text R30 C1 F0 T"E temp "
value N200 W30
text T" actual "
value N100 W30
-
also i just noticed the firmware configurator does not produce the M350 line for maestro.
-
Most 12864 displays reset automatically when they are powered up, but it looks like your display doesn't, or takes too long. You could try having just a single button on the mein menu, that loads the real menu you want, then press the encoder to get that menu.
For 2.02RC4 I will look at making the M918 command reset the display, if it doesn't already. That would give you the opportunity to use a G4 delay command in config.g before the M918 command, to give your display extra time to be ready.
-
Now that 12864 support is in the firmware does that mean it will work on a Duet WIFI/Ethernet?
-
@tjb1 said in Firmware 2.02 Release candidate 3 now available:
Now that 12864 support is in the firmware does that mean it will work on a Duet WIFI/Ethernet?
no. the duet wifi/ethernet does not have the communication ics required for the communication.
-
Hi David,
I test firmware 2.02RC3 on my Scara and DuetWifi
I do not have a Z end stop just your IR Probe
and G28 error on G30
G30 S-1
G30 P0 X0 Y0 Z-99999Return:
G28
Error: Z probe was not triggered during probing move
Error: G0/G1: insufficient axes homedMy homeall.g (ok on 1.21RC3):
M18 ; Disable all stepper motors (pour desactiver le second bras IMPORTANT !)
G91 ; relative movement
G1 S2 Z4 F250 ; ensure head is clear of the bed;Move by security to the case or already home !
G1 S2 X10
G1 S2 Y-10; Home proximal joint
G91
G1 S1 X-200 F2000 ; move proximal joint clockwise by up to 200 degrees until the endstop switch is triggered
G1 S2 X5 ; move proximal joint anticlockwise by 10 degrees
G1 S1 X-20 F300 ; move proximal joint slowly to the endstop switch again
G90 ; absolute movement; Home distal joint
G91 ; relative movement
G1 S1 Y200 F2000 ; move distal joint clockwise by up to 200 degrees until the endstop switch is triggered
G1 S2 Y-5 ; move distal joint anticlockwise by 10 degrees
G1 S1 Y20 F300 ; move distal joint slowly to the endstop switch again
G90 ; absolute movement;Home Z
G90 ; absolute movement
G30 ; Single Z-Probe
My ZProbe on config.g:
; Z probe
M558 P1 I0 X0 Y0 Z1
G31 Z2.2 P500
M557 X25:265 Y25:265 S80 -
@dc42 @claustro
M557 X15:325 Y-15:270 P3 (in config.g)
resulting in
Error: M557: Error: M557 P parameter is no longer supported. Use a bed.g file instead.Seems like a bug to me. Or what am I missing? (It worked just fine with S parameter, but defining the number of probing points is so much handier...)
-
I accidentally pressed the tool
over the PanelDue instead of the temperature. After that, my 4 hours printing was broken because in the middle of printing the tool T1 with offset and temperature was deselected.Error message in DWC:
Error: Attempting to extrude with no tool selected.Such inputs should not be executed in print!!
-
@zerspaner_gerd said in Firmware 2.02 Release candidate 3 now available:
I accidentally pressed the tool !(...) over the PanelDue instead of the temperature. After that, my 4 hours printing was broken because in the middle of printing the tool T1 with offset and temperature was deselected.
Ouch.
I completely agree with you that the attempt to change tools should be blocked. However, I think it'd be more appropriate for it to be blocked by DWC and the PanelDue (and not by the duet firmware itself.) Gcode that changes tools in mid-print is completely reasonable for multiple tool machines. For Paneldue, I think this would be a fairly simple change to just check the 'status' before reacting to the tool button.
Edit:
I just submitted pull request #42 for panelduefirmware to address this. I can't help with DWC (but I think it's not quite as easy to deactivate a tool with DWC.)
-
When an SD card print is in progress and not paused, I think it might make more sense to disable many GCode commands that come from other sources. Not just tool selection but also G32, G29, and all movement commands except baby stepping. This would be done in the main firmware so that it applies to all input streams except the SD card.
Comments?
Duet WiFi hardware designer and firmware engineer
Please do not ask me for Duet support via PM or email, use the forum
http://www.escher3d.com, https://miscsolutions.wordpress.com -
@dc42 I think that would be a good safe default. I've ruined a few prints myself by accidentally touching the PanelDue during a print.
I still think there is a place for a screen lockout function for the Panel due in addition.
-
@dc42 said in Firmware 2.02 Release candidate 3 now available:
When an SD card print is in progress and not paused, I think it might make more sense to disable many GCode commands that come from other sources. Not just tool selection but also G32, G29, and all movement commands except baby stepping. This would be done in the main firmware so that it applies to all input streams except the SD card.
Comments?
Seeing as you asked - I often change tools mid print so personally I'd be a bit miffed if I couldn't. The usual case is when I've sliced something and forgotten to select the correct tool (colour) for my mixing hot end so the slicer defaults to tool 0. The print starts and as it does the skirt, I realise that it's using the wrong tool so I just select the right one. As it's a mixing hot end, I set the operating and standby temperatures to be all the same in my slicer start code so switching tools doesn't give me any problem. If I couldn't switch tool, I'd have to abort the print, clean the bed and start again, which wouldn't be the end of the world but I prefer it the way it is.
-
@deckingman said in Firmware 2.02 Release candidate 3 now available:
@dc42 said in Firmware 2.02 Release candidate 3 now available:
When an SD card print is in progress and not paused, I think it might make more sense to disable many GCode commands that come from other sources. ...
Seeing as you asked - I often change tools mid print so personally I'd be a bit miffed if I couldn't...
You don't pause before changing tools? Would it be disruptive to pause before changing tools? (I've never worked with a mixing hot end, so I don't know if pausing causes a problem or not.)
I'd be fine disabling many commands (originating from PanelDue or the DWC gcode console) from the firmware if the status was printing and not paused - as long as those commands were available while paused.
Would that impact people who stream gcode from the USB port (such as octoprint)? Telnet? Do you implement something that monitors the current "source" of the gcode stream, and then block commands from all other sources?
"I'm not saying that you are wrong - I'm just trying to fit it into my real world simulated experience."
-
Please, don't disable commands in firmware ! Sooner or later, someone will need to change something while printing, to make specific stuff. And this is where RRF is great: it allows us to experiment, and make amazing things.
I vote to only disable some critical buttons from DWC/Panel Due, or, better, just add a confirm dialog, so we can still use them. And having the ability to define which buttons we want a confirmation for would be great (not too complicated to do with DWC, maybe more tricky with Panel Due).
-
Or implement a switch like enable / disable potential "dangerous" commands during print. (like a "child safety lock"
) -
I think for this specific issue faced above, if the firmware could prevent having no tool selected during a print (in stead of simply preventing a tool change), it might have solved it. Changing tools mid print is sometimes needed and very useful.
Also another vote for the switch to disable/enable these potential dangerous commands, or the confirm dialog. Someone should know what they are doing, when running them.
-
@garyd9 said in Firmware 2.02 Release candidate 3 now available:
You don't pause before changing tools? Would it be disruptive to pause before changing tools? (I've never worked with a mixing hot end, so I don't know if pausing causes a problem or not.)
Correct. That is to say, with a mixing hot end all filaments are loaded all the time. So there is no need to pause between tool changes. I just set the active and standby temperatures the same for all tools in the start gcode. Sometimes, it is necessary to purge between tool changes but not always. It depends on the model and often the purge can be accomplished during infill so that printing with multiple tools (colours) is a continuous process.
-
@dc42 Previously I suggested that while in the print process that gcode should be encapsulated in another command, sort of like linux 'sudo dosomethingmad'.
Enabling or disabling this behaviour could be set in config and the PanelDue firmware could have a log in and configurable time out to enable the use of dodgy commands mid build.
