Firmware 2.03RC5/1.24RC5 released

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.

Catalin_RO

While working on upgrading a Chinese 6040 CNC we found a strange behavior on Y axis with FW 2.02 and still visible in 2.03RC5. I will put here only significant values that triggered the strange behavior and the ones that allow it run as expected. Apart from that, the config.g file is copied from my WorkBee with some cleaning because the 6040 has only a single Y axis.

So, initially the Y axis was set to 3000mm/min maximum feed rate and acceleration of 100mm/s^2, with a range from 0 to 600mm. When doing a G0 Y600 everything was OK and then, when doing a G0 Y0 the noise when reaching Y0 was tremendous. In the end we realized that there was no deceleration phase when returning to Y0. By reducing the maximum feed rate to 2500mm/min all works as expected.

The 6040 has 640 steps/mm with 16x micro stepping.

The X axis, with the similar maximum feed rate but with smaller range (0..390mm) doesn't exhibit the problem.

Is there any potential out of range computation with this very specific combination of parameters?

dc42

@Catalin_RO, that's very odd! Please connect a PC running YAT (with line ending set to LF only) or Pronterface via USB, home the printer, and get ready to do the G0 Y0 move. Then send M111 S1 P4 and M111 S1 P6. Then send the G0 move. Post the output from the PC here.

Also post your config.g file.

rzi

With rc4 and rc5 homing Z does not work as expected for me. Z moves down (away from the endstop, never trigger it) a bit and consider it self homed.

I have my end stops to active high.

Z endstop configuration:
M574 Z2 S1 C4

With rc3 it works fine. With rc4 and rc5 it seems to ignore this and uses "the default?" endstop.

//Rickard

dc42

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

With rc4 and rc5 homing Z does not work as expected for me. Z moves down (away from the endstop, never trigger it) a bit and consider it self homed.

I have my end stops to active high.

Z endstop configuration:
M574 Z2 S1 C4

With rc3 it works fine. With rc4 and rc5 it seems to ignore this and uses "the default?" endstop.

//Rickard

The C parameter in M574 was withdrawn because of side-effects it has for CNC users. It's re-introduced (in a different form) in RRF 3.

What is your reason for using the E1 endstop connector instead of the Z endstop connector?

rzi

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

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

With rc4 and rc5 homing Z does not work as expected for me. Z moves down (away from the endstop, never trigger it) a bit and consider it self homed.

I have my end stops to active high.

Z endstop configuration:
M574 Z2 S1 C4

With rc3 it works fine. With rc4 and rc5 it seems to ignore this and uses "the default?" endstop.

//Rickard

The C parameter in M574 was withdrawn because of side-effects it has for CNC users. It's re-introduced (in a different form) in RRF 3.

What is your reason for using the E1 endstop connector instead of the Z endstop connector?

I have my touch plate on default Z endstop and the "normal" Z endstop on C4. So, when I run my z probe I temporarily reassign my Z endstop to work with the touch plate.

Does this mean I have to join my touch probe wires with the "normal" endstop wires as I can't reassign the endstops?

//Rickard

dc42

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

Does this mean I have to join my touch probe wires with the "normal" endstop wires as I can't reassign the endstops?

Yes, or configure your touch plate as a Z probe instead of an endstop switch, or switch to the unofficial RRF 3 beta.