Firmware 1.21 release candidate 2 now available

darookee

When beginning a print from SD card, macro /sys/start.g is run if it is present

Nice!
Would it be possible to add one for after printing as well?

peirof

It's now…. Stop.g, no?

MSquared

Installed! I will let you know how it goes!

dc42

@peirof:

Hi,

Now I am giving a try to Bltouch… I have read in changes, that there is a new type of probe...
[[language]]
A separate Z probe type (P9 in M558) is now used for BLTouch and compatible Z probes. When this is selected, the deployprobe.g macro is run just before each probing move, and retractprobe.g is run every time the probe triggers, or at the end of the probing move if it doesn't trigger
For use it… Only I have to change the type of probe in [c]config. G[/c]? I have to do more changes?

Just that; although you can also remove any M401/402 commands from bed.g. Some people seem to think that turning off heaters while probing (which is also supported by this RC) may improve the accuracy when using bltouch.

dc42

@peirof:

It's now…. Stop.g, no?

Yes, but only if the GCode files ends with command M0.

MSquared

Initial impression is that the web interface is WAY more responsive! still playing with it.

peirof

hi,

i have installed 1.21RC2….

and some issues, in this moment, i have instaled BlTouch, and i have change his setup in [c]config.g[/c]

[[language]]
...
558 P9 X0 Y0 Z1 H8 F120 T2000
...

Issues

FIRST

Turn on printer
Heat bed.
Deploy BlTouch
Press Calibrate in DWC…. and seems do calibration ok, but i have messages in DWC, that before i havent:

[[language]]
6:47:42Error: Compensation or calibration cancelled due to probing errors
6:47:12Error: Z probe was not triggered during probing move
6:46:48Error: Z probe was not triggered during probing move
6:46:36Error: Z probe was not triggered during probing move
6:46:24Error: Z probe was not triggered during probing move
6:45:48Error: Z probe was not triggered during probing move
6:44:57Error: Z probe was not triggered during probing move

This message is some points of calibration probes, not all

SECOND

Despite the error messages, I try to execute a compensation… with this

[[language]]
M557 R140 S30

And start ok, but in aprox. when have do 50% of compesation… Headcrash and this message:

[[language]]
6:56:46Error: Z probe was not triggered during probing move

peirof

Advances….

i have change this line

[[language]]
M558 P9 X0 Y0 Z1 H11 F120 T2000

and i dont have the error message..

H8 –> to --> H11

With this change, calibration and compensation WORKS...

This firmware, has solved my issues with BlTouch, and Compesation

and Heightmap…

cgcafer

Hi,
Duplicate of previous line and then no movement BUG RESOLVED with 1.21RC2.

Thank you.

dc42

@cgcafer:

Hi,
Duplicate of previous line and then no movement BUG RESOLVED with 1.21RC2.

Thank you.

Thank you for confirming this.

robm

Hi David,
M671 change does just what I wanted, now have a 'manual bed level' macro which generates the bed plane graphic as desired and then returns the default to autoleveling with the two Z screws. Thanks!

Not sure if there was any change on the rotating magnet filament sensor? Did not notice anything in the release notes. Still get measured min/max 3%-5% (-2% to 5% when I force it to skip). Not clear from the docs if the setting for minimum should be more or less than the 3%? Trying either way though I get 'extruder 0 reports too much movement' at start of print for R5:7, R1:7, R0:10. (Note I retract 15mm at end of print and then extrude 16mm away from bed at beginning of print – PETG filament trying to reduce ooze). If I try to put a negative value in for the R minimum (like the reported -2% when I am hammering it) the status report displays wrong: 'allowed movement 2147483647% to 10%' .

Also when it has paused with the 'too much movement' message M591 reports 'no calibration data' -- it would be nice if it reported the value(s) outside of the preset limits that caused it to fail?

Thanks!
Rob.

dc42

I didn't get time to hook up the rotating magnet filament monitor and test it before releasing this RC.

hurzhurz

Hi,
I think there might be a problem with the new BLTouch probe type together with multi-touch Z probing, where it does retract but not re-deploy between the multiple probings for one point.

I have also opened an issue on github about this while I was waiting for my forum account: https://github.com/dc42/RepRapFirmware/issues/160

hurzhurz created this issue in dc42/RepRapFirmware

closed 1.21RC2 / M558: new probe type P9/BLTouch, deploy/retract problem with multi-touch #160

MSquared

While I am not affected by most of the use cases that this release was designed to address, I can report that I ran two back to back 10+ hours print yesterday with no issues at all.

The web control interface and file uploads seem to be much faster and more responsive on this release, 1.21RC1 seemed quite slow.

Looking good!

JohnOCFII

@dc42:

I've just made this available at https://github.com/dc42/RepRapFirmware/tree/dev/EdgeRelease/1.21RC2. See https://github.com/dc42/RepRapFirmware/blob/dev/WHATS_NEW.md for the changes and what you need to know before upgrading.

Question on the G29 fix:

Fixed problems with G29 bed probing that were introduced in 1.21RC1

On a Delta, after completing G32 calibration followed by, what appears to be, a successful G29, I've added G29 S1 into my bed.g file. It seems to work fine, and helped with a first layer issue in one area of my bed.

After I install RC2 (or later) will I need to re-do the G29, or if i'm satisfied with my current results, can I continue to use it as is?

Thanks.

John

dc42

You should not need to rerun G29 when you upgrade, unless you are upgrading from a really old version - the height map format changed a while back, AFAIR between 1.18 and 1.19.

JohnOCFII

@dc42:

You should not need to rerun G29 when you upgrade, unless you are upgrading from a really old version - the height map format changed a while back, AFAIR between 1.18 and 1.19.

Thanks. Since I ran that G29 with 1.21RC1, I'll consider myself in good shape.

Edkirk

In a previous post I believe you mentioned ending updates because new hardware is in progress. Did I misread the post or can I expect something new from Duet?
Thanks, Ed

peirof

David…

Can you give details of new hardware?

dc42

The reason I intend to cease updating firmware for the Duet 06/085 (also RADDS and Alligator) after release 1.21 is that I am about to change RRF for the Duet WiFi/Ethernet to use a real time operating system (RTOS), and the SAM3X8E based boards don't have enough RAM to support RTOS.