Firmware 2.03RC5/1.24RC5 released

ArnoldVR

I don't know if it was also intended to address this in this release, but to have a second print start correctly, I still have to resume the printer, otherwise I have an offset of both Y and Z. Maybe it's better to start a new post for this.

mloidl

@dc42: In the release notes you've mentioned that this release is compatible with DuetWebControl: 1.22.6 or 2.0RC6.

Latest DWC Release currently is 2.0RC7. => https://github.com/chrishamm/DuetWebControl/releases/tag/2.0.0-RC7

It's hard to find on the release page https://github.com/chrishamm/DuetWebControl/releases because it's below 2.0.0-RC1

Adrian52

My first try on a delta gave error G1/G0: target position not reachable from current position. Model printing on reverting to rc4.

Exerqtor

@mloidl said in Firmware 2.03RC5/1.24RC5 released:

@dc42: In the release notes you've mentioned that this release is compatible with DuetWebControl: 1.22.6 or 2.0RC6.

Latest DWC Release currently is 2.0RC7. => https://github.com/chrishamm/DuetWebControl/releases/tag/2.0.0-RC7

It's hard to find on the release page https://github.com/chrishamm/DuetWebControl/releases because it's below 2.0.0-RC1

Both FW 2.03-RC4 & RC5 works fine with DWC 2.0RC7, though i think it's strange that it's listed way down bellow in his github.

dc42

@adrian52 said in Firmware 2.03RC5/1.24RC5 released:

My first try on a delta gave error G1/G0: target position not reachable from current position. Model printing on reverting to rc4.

You will need to give more information if you want me to do anything about that.

Adrian52

@dc42 sorry - error occurs when starting a print from the homed position. Have got the same behaviour even when trying to print a 40x40x10mm cube. I updated dwc 2 at the same time, but reverting this to rc6 did not change the error. What further information do you need?

Adrian52

Im using a 1.01 duet 2 wifi

dc42

@adrian52 said in Firmware 2.03RC5/1.24RC5 released:

@dc42 sorry - error occurs when starting a print from the homed position. Have got the same behaviour even when trying to print a 40x40x10mm cube. I updated dwc 2 at the same time, but reverting this to rc6 did not change the error. What further information do you need?

What is the first movement command after homing in the GCode file you are trying to print? My guess is that it is a pure XY move.

Phaedrux

Upgrade from 2.02 went well. Ran a few multi hour prints without issue.

I did get a warning that I'm loading the heightmap before the Z datum is set. I load it in config.g. I haven't had any issues, but I think I'll move the loading of the heightmap into the start gcode after homing, just to get rid of the warning.

minim

@adrian52 said in Firmware 2.03RC5/1.24RC5 released:

@dc42 sorry - error occurs when starting a print from the homed position. Have got the same behaviour even when trying to print a 40x40x10mm cube. I updated dwc 2 at the same time, but reverting this to rc6 did not change the error. What further information do you need?

I home my delta with G28 before a print and don't have this issue. Maybe upload the start of the file you are printing would reveal something if I compared it to mine.

Adrian52

@dc42 indeed. Prefixed a z move, and now it works fine. Definite change in behaviour from rc4 for me though.

Adrian52

Still getting disconnect error during long print. Yat connection OK. Disabled and re-enabled the WiFi (led went off, and came back on steady after flashing as expected) but dwc only reconnects for a few seconds (request failed status code 503). M122 from yat gives a truncated response, but shows buffers 22/24 (24max).

avaradus

@dc42 Trying that version. But bug with release free output buffers is not fixed.
After start printer i see Used output buffers: 2 of 24 (5 max)
Now after 21 hours have passed i see Used output buffers: 16 of 24 (24 max)
And in YAT i see not full and truncated result of command M122
I think tomorrow the number of buffers will reach a maximum 24 and the printer will finally hang freeze.

dc42

@adrian52 said in Firmware 2.03RC5/1.24RC5 released:

@dc42 indeed. Prefixed a z move, and now it works fine. Definite change in behaviour from rc4 for me though.

It's an intentional change in behaviour. In previous releases, if you attempted an XY move that wasn't possible at the current Z height, RRF would truncate the move or reduce the ending height. That's unsafe if you are nearing the end of a tall print, so now the firmware treats it as an error.

Surgikill

I'm currently running a corexy printer on 2.01. I noticed in the release notes that the core kinematics has been changed around and you recommend setting the current lower and testing with small steps. That was on one of the betas. Is that still required or has that been fixed?

dc42

@surgikill said in Firmware 2.03RC5/1.24RC5 released:

I'm currently running a corexy printer on 2.01. I noticed in the release notes that the core kinematics has been changed around and you recommend setting the current lower and testing with small steps. That was on one of the betas. Is that still required or has that been fixed?

Other users with CoreXY printers report success with the later 2.03RCs. But when using any new firmware, IMO it's wise to reduce motor current when testing the printer with the new firmware, to reduce the possibility of damage.

deckingman

@surgikill said in Firmware 2.03RC5/1.24RC5 released:

I'm currently running a corexy printer on 2.01. I noticed in the release notes that the core kinematics has been changed around and you recommend setting the current lower and testing with small steps. That was on one of the betas. Is that still required or has that been fixed?

If it helps, I've been running RC3 on my CoreXY(UV) for some time without any issues and from the release notes, the changes between RC3 and RC5 are minimal. But @dc42's words of caution are always a wise precaution to take.

Surgikill

@deckingman I tried it last night. Moved the gantry to the middle and tried homing it with my finger on the endstop and other finger on the killswitch. Everything worked fine, tried printing but still having issues with petg.

A Former User

hi, tested a week ago rc4 (sorry had to move across the country to start a new job, so sorry for writing now) and since rc4-thread is closed because of rc5 I post here:

THANKS for fixing the strange movement when re-homing in additional csys (in my case G55) -> only thing still observed: when re-homing in an additional/the machine beeing in that additional csys (e.g. in my case the G55) it seems to ignore the endstop (in my case simple switches)

In G54 (main/general/standard csys) all seems to be fine/work fine !

I could be wrong on that but maybe something to look into if there is time...

dc42

@lb said in Firmware 2.03RC5/1.24RC5 released:

THANKS for fixing the strange movement when re-homing in additional csys (in my case G55) -> only thing still observed: when re-homing in an additional/the machine beeing in that additional csys (e.g. in my case the G55) it seems to ignore the endstop (in my case simple switches)
In G54 (main/general/standard csys) all seems to be fine/work fine !

Can you try that again? There should be no different in homing behaviour whichever workplace coordinate system you are using. You can reduce the motor current using M913 to avoid damage in case the endstops are not recognised.