New firmware 1.21RC4

dc42

I have just released this firmware here https://github.com/dc42/RepRapFirmware/releases/tag/1.21RC4. The code for 1.21 is now frozen, save for any important bug fixes. As always, read the upgrade notes at https://github.com/dc42/RepRapFirmware/blob/dev/WHATS_NEW.md.

Captain_sq

This is relevant to RC3 but I didn't got to report this before the thread were closed. However, no mention of this quirk in the bug fix list. After upgrade to RC3 on my Core XY the bed compensation macro misbehaves. After the probing it just stops and does the homing procedure, not the fast move back to 0,0.
When I checked, it seemed the system went into relative coordinate mode (G91) after the two bed probes. These probes serve to compensate for dual Z leadscrews (each has independent motor). I inserted G90 after the probe commands and all is fine again. Maybe this issue already has been covered as I have not read the entire RC3 thread.

Bed.g

[[language]]
; bed.g
; called to perform automatic bed compensation via G32
;
; Clear any bed transform
M561

; Home all axes
G28
G1 Z15 F6500		; Move platform down to ensure probe rod don't strike anything
G1 X0 Y162		; Move to the approximate middle

; Probe the bed at 2 points
G30 P0 X0 Y162 H0 Z-99999
G30 P1 X305 Y162 H0 Z-99999 S

G90			; Go back to absolute coordinates (bug ?)

; MOve back home fast 
G1 X0 Y0 Z5 F6500
G28 			; Do homing 
G29 S1			; Read in the bed compensation table again

As Bed.g calls the homeall.g macro, I've included it too.

[[language]]
; homeall.g
; called to home all axes
;
G91                     ; relative positioning
G1 S2 Z5 F3000             ; lift Z relative to current position
G1 S1 X-340 Y-340 F1800 ; move quickly to X or Y endstop and stop there (first pass)
G1 S1 X-340             ; home X axis
G1 S1 Y-340             ; home Y axis
G1 S2 X5 Y0 F3000       ; go back a few mm X5 Y5 
G1 S1 X-340 F360        ; move slowly to X axis endstop once more (second pass)
G1 S1 Y-340             ; then move slowly to Y axis endstop
G1 S2 X9 Y9 F3000		; Move inside bed - X only moves to X=9
G1 S2 X7 Y-7 F3000		; Move inside bed - Y only moves to Y=7
G1 S1 Z-400 F1800       ; move Z down stopping at the endstop
G1 S2 Z1 F3000          ; go back a mm
G1 S1 Z-400 F100        ; move slowly to Z axis endstop once more (second pass)
G90                     ; absolute positioning
G92 X0 Y0 Z0            ; set new X, Y and Z position
;G1 Z1 F400              ; uncomment this line to lift the nozzle after homing

xnaron

Continuing on from RC3 thread regarding my Duet Ethernet thinking it is a wifi. I flashed it to RC4 and again lost ethernet. I ran M115 and the last part of the line says "…ELECTRONICS: Duet W" so I am assuming it thinks it is a wifi. You said I should check the 2 pins closest to the edge. I'll need to remove it from its case to do this a bit of a job. I'll do this and check the connections and see if I need to repair. I believe this issue is only rearing it's head now because of the combination of both firmwares into one correct? I am hoping it is an easy fix as if not I'll need to send it back overseas. I will post an update in a bit.
thanks

UPDATE:
Removed the duet ethernet and looked at the 2 pins under the board. There were connection issue with both. I resoldered and tested and it now thinks it is a "Duet E"

okercho

Installed.

Firmware Electronics: Duet WiFi 1.02 or later
Firmware Version: 1.21RC4 (2018-03-11 build 1)
WiFi Server Version: 1.21RC4(08b3)
Web Interface Version: 1.21-RC4

I can confirm that uploading "Duet2CombinedFirmware.bin" file on top of a RC3 works perfect (I didn't rename the file and the update was successful), the X/Y homing are cancelled if I try to move Z before homing it ("Error: G0/G1: insufficient axes homed" message) unless S2 is used in G1, and the G30 executed a double tap for Z homing.

I will keep using this RC and report back any issue.

Regards

Captain_sq

Upgraded to RC4 on my Mini Kossel Duet 0.6
Nothing new I'm afraid, still the same reboot loop when the ethernet cable is inserted and DHCP is active. I can live with this. It's nothing that hampers the use of this board in a serious way. Once back to fixed IP, all is working fine.

[[language]]
(18:06:21.093) M122
(18:06:21.234) === Diagnostics ===
(18:06:21.234) Used output buffers: 1 of 32 (1 max)
(18:06:21.234) === Platform ===
(18:06:21.234) RepRapFirmware for Duet version 1.21RC4 running on Duet 0.6
(18:06:21.234) Static ram used: 44836
(18:06:21.234) Dynamic ram used: 40884
(18:06:21.234) Recycled dynamic ram: 296
(18:06:21.234) Stack ram used: 3520 current, 4332 maximum
(18:06:21.234) Never used ram: 7956
(18:06:21.234) Last reset 00:00:42 ago, cause: software
(18:06:21.234) Last software reset time unknown, reason: Stuck in spin loop, spinning module Network, available RAM 7852 bytes (slot 3)
(18:06:21.234) Software reset code 0x2041 HFSR 0x00000000, CFSR 0x00000000, ICSR 0x0440f80f, BFAR 0xe000ed38, SP 0x20087e64
(18:06:21.234) Stack: 000c1b3f 00000001 fffffff9 01c8a8c0 20087ebc 20070fe8 00000001 20087ebc 000a7f99 000a7f9e 21000000 2007a9ac 0000012c 00000123 00000000 2007376c 200737a8 2007a938 00000127 2007aea8 000000f0 4420726f 01c8a8c0 2007376c
(18:06:21.234) Error status: 0
(18:06:21.234) Free file entries: 10
(18:06:21.234) SD card 0 detected, interface speed: 21.0MBytes/sec
(18:06:21.234) SD card longest block write time: 0.0ms
(18:06:21.234) MCU temperature: min 24.9, current 26.3, max 26.7
(18:06:21.234) Date/time: 1970-01-01 00:00:00
(18:06:21.234) Slowest main loop (seconds): 0.000390; fastest: 0.000098
(18:06:21.234) === Move ===
(18:06:21.234) MaxReps: 0, StepErrors: 0, LaErrors: 0, FreeDm: 100, MinFreeDm 100, MaxWait: 0ms, Underruns: 0, 0
(18:06:21.234) Scheduled moves: 0, completed moves: 0
(18:06:21.234) Bed compensation in use: mesh
(18:06:21.234) Bed probe heights: 0.000 0.000 0.000 0.000 0.000
(18:06:21.234) === Heat ===
(18:06:21.234) Bed heaters = 0, chamberHeaters = -1 -1
(18:06:21.234) Heater 1 is on, I-accum = 0.0
(18:06:21.234) === GCodes ===
(18:06:21.234) Segments left: 0
(18:06:21.234) Stack records: 2 allocated, 0 in use
(18:06:21.234) Movement lock held by null
(18:06:21.234) http is idle in state(s) 0
(18:06:21.234) telnet is idle in state(s) 0
(18:06:21.234) file is idle in state(s) 0
(18:06:21.234) serial is ready with "M122" in state(s) 0
(18:06:21.234) aux is idle in state(s) 0
(18:06:21.234) daemon is idle in state(s) 0
(18:06:21.234) queue is idle in state(s) 0
(18:06:21.234) autopause is idle in state(s) 0
(18:06:21.234) Code queue is empty.
(18:06:21.234) === Network ===
(18:06:21.234) Free connections: 16 of 16
(18:06:21.234) Free transactions: 24 of 24
(18:06:21.234) Locked: 0, state: 2, listening: 0x0, 0x0, 0x0
(18:06:21.234)

peirof

hi,

i have a Duet Wifi, and i am trying to update to 1.21RC4. from 1.21RC2, but i cant….

I have uploaded with Duet Web interface, and after i have send [c]M997 S0[/c], i loose the conection with Duet, but when i reload DWI, the same Firmware Version….

Maybe, i have to rename [c]Duet2CombinedFirmware.bin[/c]?

JohnOCFII

@peirof:

Maybe, i have to rename [c]Duet2CombinedFirmware.bin[/c]?

Yes, you have to rename the firmware for the first upgrade from RC2 or earlier.

From the README:

The binary filename for the Duet WiFi and Duet Ethernet is now called Duet2CombinedFirmware.bin. When installing it on a Duet WiFi running a previous firmware revision or a Duet Ethernet running 1.21RC2, you will need to rename it to DuetWiFiFirmware.bin.

whosrdaddy

Lost my Duet connection after the RC4 upgrade (coming from RC3). I had to power cycle the printer to get it back online.
M564 H0 is working as expected, jog buttons are finally working again in a non homed state

Yonkiman

Just upgraded from 1.21 RC3 to RC4 with the latest Web Control as well, and when I press "Home X" (or Y or Z or all) in DWC, I get a [c]G0/G1: insufficient axes homed[/c] error.

I downgrade back to RC3 and it worked - am I missing something?

Captain_sq

@Yonkiman:

Just upgraded from 1.21 RC3 to RC4 with the latest Web Control as well, and when I press "Home X" (or Y or Z or all) in DWC, I get a [c]G0/G1: insufficient axes homed[/c] error.

I downgrade back to RC3 and it worked - am I missing something?

From the RC3 upgrade notes:

[[language]]
On Cartesian and CoreXY printers, normal G0 and G1 moves are no longer allowed before the corresponding axes have been homed. In particular, if your homex.g, homey.g and homeall.g files raise Z a little at the start and lower it at the end, you will need to add the S2 parameter to those G1 Z moves. Otherwise the G1 Z move will be refused unless Z has already been homed and the homing macro will be terminated.

deckingman

As above but also from the Whats New we have

"Added M564 H0 command to allow axis movement before homing on Cartesian/CoreXY printers"

So either add the S2 parameter to home all, or use M564 H0

garyd9

I'm still able to repeat the m116 being skipped or ignored with RC4. In answer to your reply in the RC3 thread, my tool change macros (tfree*, tpost*, tpre*) are all empty (other than comments.) As well, everything works fine if the build plate is not fully pre-heated. This issue ONLY occurs when my build plate is already at temperature. Here's the (only) contents of the gcode file I used to verify this:

[[language]]
G90
M83
M106 S0
; S3D starting gcode for RIGHT extruder
;
M140 S60  ; start heating the bed (no wait) while homing
G28                       ; homeall 
T1 P0                       ; load right tool
G1 X150 Y70 Z30 F6000     ; move to wait position right hand side of table  
M291 P"Heating Build Plate" S1 T0
M190 S60  ; now wait for the bed to finish heating
M292                      ; clear the previous message
M300 S600 P600            ; make some noise
G10 P0 S0 ; set T0 temp
G10 P1 S195 ; set T1 temp
M291 P"Heating Tool" S1 T0
M116 P1                   ; wait for right tool to heat up
M292                      ; clear the previous message
M300 S600 P600            ; make some noise
M291 P"Purging and Wiping Right Nozzle" S1 T0
G1 Z0.4                   ; position nozzle
G1 X110 Y70 E25 F300      ; purge nozzle
G1 X120 Y70 Z0.15 F1200   ; slow wipe
G1 X110 Y70 Z0.5 F1200    ; lift
M400                      ; wait for the cache to clear
M292                      ; clear the previous message
M0

What happens:

If the build plate is several degrees below 60c when I run this gcode file, everything works exactly as you might expect from reading the gcode. It homes, moves to the rear/right of the HBP, and I get a popup on DWC/PanelDue stating that it's waiting for the build plate to heat up. When the plate gets to 60c, the popup changes to say that the tool is heating. When the tool gets hot enough, I see "purging and wiping right nozzle" and it does the movements/extrusions.

HOWEVER, if the build plate is already at 60c at the time the printer completes homing, I do NOT see the "Heating build plate" message, and I do NOT see the "Heating tool" message. It homes, moves to the rear/right, and immediately I see the "purging and wiping" message. The tool target temperature is set properly, but the "M116 P1" command is just skipped or ignored. (The purge/wipe doesn't work, as the duet board doesn't allow extrusion on the cold tool.)

For completeness, here is the content of my homeall.g file (I'm currently using a bltouch in mode 5, but the same issue occurs if I home Z against a mechanical endstop):

[[language]]
M280 P3 S160 I1 ; reset any bltouch alarm and pull up the pin
T1 P0                 ; X must be homed relative to the right nozzle.  P0 prevents any tool change macros
G91                   ; relative positioning
G1 S2 Z5 F6000        ; lower HBP relative to current position
G1 S1 X266 Y155 F6000 ; move quickly to X and Y axis endstops and stop there (first pass)
G1 S2 X-5 Y-5 F6000   ; go back a few mm on all axis
G1 S1 X266 Y155 F360  ; move slowly to X and Y axis endstops once more (second pass)
G90		; back to absolute
G92 X151 Y75	; set X and Y
G1 X74.3 Y-68.4 F6000  ; position the probe over the front/center screw adjustment point (offsetting from T1)
G91			; relative positioning
M401			; deploy the probe
G1 S1 Z-155 F6000	; quickly move Z down, stopping at the probe
G1 S2 Z5 F1200		; immediately move the nozzle 5mm away from the build plate
M401			; make sure the probe is deployed still
G30			; slowly probe at the current position and set Z to the trigger height
M402			; retract the probe

dc42

@Captain_sq:

This is relevant to RC3 but I didn't got to report this before the thread were closed. However, no mention of this quirk in the bug fix list. After upgrade to RC3 on my Core XY the bed compensation macro misbehaves. After the probing it just stops and does the homing procedure, not the fast move back to 0,0.
When I checked, it seemed the system went into relative coordinate mode (G91) after the two bed probes. These probes serve to compensate for dual Z leadscrews (each has independent motor). I inserted G90 after the probe commands and all is fine again. Maybe this issue already has been covered as I have not read the entire RC3 thread.

Please can you try RC4 without the extra G90 and see if the problem persists.

dc42

@xnaron:

Continuing on from RC3 thread regarding my Duet Ethernet thinking it is a wifi. I flashed it to RC4 and again lost ethernet. I ran M115 and the last part of the line says "…ELECTRONICS: Duet W" so I am assuming it thinks it is a wifi. You said I should check the 2 pins closest to the edge. I'll need to remove it from its case to do this a bit of a job. I'll do this and check the connections and see if I need to repair. I believe this issue is only rearing it's head now because of the combination of both firmwares into one correct? I am hoping it is an easy fix as if not I'll need to send it back overseas. I will post an update in a bit.
thanks

UPDATE:
Removed the duet ethernet and looked at the 2 pins under the board. There were connection issue with both. I resoldered and tested and it now thinks it is a "Duet E"

I am glad you resolved it. Was it the soldering on the Duet or the soldering on the Ethernet daughter board that was bad? I don't suppose you took a photo of it before you repaired it?

One of those 2 pins (I can't remember which) is grounded on the daughter board but not on the WiFi module, so the firmware looks to see whether that pin is grounded to determine which network interface is fitted.

DjDemonD

I can confirm working on delta and the issue with corexy that was present in rc3 is now solved. Prints completed on both machines.

One suggestion - for those of us using PS ON and OFF via relays/ssr's might it be possible for any attempt to send a command that would require power to be on when it is off, i.e. movement command or heating commands, should throw a warning rather than attempt to complete the action. Example:

I sent a home all G28 to a machine which had its power relay off, this effectively locks the device. I don't know if there is a timeout after which it will respond.

daveidmx

I'm seeing an issue with the new pre-homed movement restrictions in corexy config. I'm performing double-tap homing, and I've added [c]S2[/c] to the moves for 1.21:

G91
G1 X260 F6000 S1
G1 X-5 F6000 S2
G1 X10 F600 S1
G1 X-1 F6000 S2

The problem I'm seeing is that after the halt from the first [c]S1[/c] move, if I use [c]S2[/c] to retreat from the endstop, that appears to trigger the "drive only one motor" behavior that's documented for deltas, i.e. it moves the head at a diagonal on corexy, rather than back along the axis. I can back away from the endstop by using [c]G1 X-5 Y-5 F6000 S2[/c] and manually driving both motors. Is that what's expected now for this scenario on corexy?

dc42

@Captain_sq:

Upgraded to RC4 on my Mini Kossel Duet 0.6
Nothing new I'm afraid, still the same reboot loop when the ethernet cable is inserted and DHCP is active. I can live with this. It's nothing that hampers the use of this board in a serious way. Once back to fixed IP, all is working fine.

Thanks for your report; I'm sorry it is still not fixed. I think there must be a timing difference between DHCP on your system and mine, or else the DHCP response from your router is different from mine.

Your trace shows that it is in dhcp_recv again. I'm starting to wonder whether this cause is a compiler bug, because I switched compiler versions around the release that the problems were first reported. The dhcp_recv function is full of goto statement (ugh!), and goto statements are (a ) difficult for compiler writers to translate correctly because the stack and register states at the point of the goto have to be matched to the states expected at the label, and (b) probably not very well tested, because very few developers use goto statements. For the release or next RC I may try rewriting that function without using goto.

dc42

@daveidmx:

I'm seeing an issue with the new pre-homed movement restrictions in corexy config. I'm performing double-tap homing, and I've added [c]S2[/c] to the moves for 1.21:
G91
G1 X260 F6000 S1
G1 X-5 F6000 S2
G1 X10 F600 S1
G1 X-1 F6000 S2
The problem I'm seeing is that after the halt from the first [c]S1[/c] move, if I use [c]S2[/c] to retreat from the endstop, that appears to trigger the "drive only one motor" behavior that's documented for deltas, i.e. it moves the head at a diagonal on corexy, rather than back along the axis. I can back away from the endstop by using [c]G1 X-5 Y-5 F6000 S2[/c] and manually driving both motors. Is that what's expected now for this scenario on corexy?

You don't need to add S2 to those moves, because the X axis is already homed when they are executed. The typical case for needing to add S2 is when you want to raise Z a little at the start of X or Y homing.

dc42

@DjDemonD:

I can confirm working on delta and the issue with corexy that was present in rc3 is now solved. Prints completed on both machines.

Thanks!

@DjDemonD:

I sent a home all G28 to a machine which had its power relay off, this effectively locks the device. I don't know if there is a timeout after which it will respond.

The timeout will be the time it would take to execute the G1 S1 move it if had to travel the full X, Y or Z distance specified.

Why not put a M80 command at the start of homeall.g?

DjDemonD

Thanks David, I will. If there is a timeout then that's not a problem, at least I know it will respond when I forget to power it up before testing something.

The other possible issue is if the machine has to be reset for some reason, the power does not restore so hotend cooling does not resume. Might it be worthy of consideration having a routine that checks the hotend temperature, and if it is above x deg C, initiates an M80 so the fan/water cooler can begin working again as soon as possible? I appreciate there are implication with thermal safety here. I'd propose 50 deg C for x, since that covers the glass transition temperature of PLA, the lowest of commonly printed materials.