Firmware 2.03RC5/1.24RC5 released

[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.

[TypQxQ]

CoreXYUV working fine.

[Gone2Far]

Still having the calibration issues I saw on RC4. This is on my delta with smart effector. The calibration seems to oscillate between a few different heights, never converges on one particular height. Also still had the issue with the effector triggering early, had to leave it with sensitivity set to 128 instead of default. After doing that, and saving (with M500) a G32 result that seemed kind of correct and a following G29, was attempting to recalibrate the offset from 0 for the Z probe in config.g using baby stepping to get a feel for how far off it currently was. Baby stepping appears to be very broken. Was using the Due to set the baby step for a 0.2mm patch print, and then measure the actual thickness of the patch with a micrometer. Setting the baby step while the bed is heating does not seem to actually change the thickness--though it does change the baby step setting readout. Pushing the baby step up/down buttons while the extruder is heating (following the bed heat) do not immediately change the reading, but once the extruder is up to temp, the readout does change appropriately. Again, though, the actual print does not seem to change. Once the print has actually started extruding, the baby step does seem to change when the up/down buttons are pushed, but they may or may not match the reading.

Went back to 2.02, G32 converged in about 5-6 iterations. Haven't backed off the effector sensitivity yet to try that.

[boldnuts]

I rolled back to 2.02 and it does seem to converge a bit better (quicker), see screen shots from my TLM with smart effector

[dc42]

@boldnuts, did you mean that the first of the 2 images in your post is with firmware 2.02 and the second is with 2.03RC5?

@Gone2Far, if you are seeing a change in trigger sensitivity, I don't think that's anything to do with the firmware change. Delta calibration should converge after no more than 3 iterations, so if it is taking more than that then I suspect you may be getting false triggering. If you need to set sensitivity to 128 then I suspect that a fan or something else is interfering with the Smart Effector electronics.

[boldnuts]

Yes that's correct, first image is 2.02 and second is 2.03RC5