Firmware 2.03RC5/1.24RC5 released

[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

[denke]

@dc42 It did in my case, I use 24V sunon 40x40x20 fans, which are very noisy (electricly speaking)
My solution was connecting the main fan to a PWM output and stopping the fan for the duration of the delta calibration.

[dc42]

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

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

Does the speed of convergence change depending on whether you do or don't home the printer between auto calibration runs?

[boldnuts]

I don't re home between calibrations, but I will re check this for you

[dc42]

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

I don't re home between calibrations, but I will re check this for you

I don't normally home between re-calibrations either, but it is conceivable that there could be a firmware bug that causes it to make a difference. There were small changes in RRF 2.03 to how the corrections made by auto calibration are applied. That said, I've checked that code several times and I believe it should have exactly the same effect as the 2.02 code.

[dc42]

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

@dc42 It did in my case, I use 24V sunon 40x40x20 fans, which are very noisy (electricly speaking)
My solution was connecting the main fan to a PWM output and stopping the fan for the duration of the delta calibration.

It's actually the magnetic field from the fan(s) that causes the problem. In revision 2 of the Smart Effector we moved the heatsink fan away from the sensitive electronicas to mitigate this issue. The E3D heatsink fan doesn't cause any issues, but some other fans do.

[boldnuts]

First image is 2.03RC5, homing between calibration which does seem better than before and 2nd image 2.02 with the same settings

[dc42]

Thanks. Please can you try 2.03 without homing between calibration runs a few times, to see whether it is consistently worse.

[boldnuts]

2.03 it's not quite as consistent as 2.02, but very little in, nit picking at best, ran both 6 times with no homing, bottom image is 2.02

[dc42]

Thanks. On that basis, I think there is no significant difference between 2.02 and 2.03.

[dragonn]

I see 2.03 final on github, question - what is the "jerk policy" for?
I can not find any information about that.

[wilriker]

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

I see 2.03 final on github, question - what is the "jerk policy" for?
I can not find any information about that.

It made me curious, too. I found it in the GCode documentation:

The default jerk policy is 0, which replicates the behaviour of earlier versions of RRF (jerk is only applied between two printing moves, or between two travel moves, and only if they both involve XY movement or neither does). Changing the jerk policy to 1 allows jerk to be applied between any pair of moves.

[dragonn]

@wilriker It must be recently add when I search it it wasn't there

[dc42]

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

2.03 it's not quite as consistent as 2.02, but very little in, nit picking at best, ran both 6 times with no homing, bottom image is 2.02

@boldnuts , you were right! There is a bug in the 2.03 autocalibration function. Please try the 2.03+1 binary at https://www.dropbox.com/s/zfv4p7dr2ycmjzd/Duet2CombinedFirmware.bin?dl=0 and see whether it gives you better results, as good as 2.02 did.

[boldnuts]

Calibration all sorted out now dc42, Thank you