New experimental firmware 1.19beta10

dc42

I've just released this in the usual Edge folders. Highlights of this release are completion of the facility t perform bed levelling using multiple independent Z motors, automatic deployment and retraction of Z probes, and support for volumetric extrusion. See https://github.com/dc42/RepRapFirmware/blob/dev/WHATS_NEW.md for the full change list and important upgrade notes.

The heater tuning algorithm has been changed a little in this version and I am hopeful that it will provide better responsiveness. If you try this release, it would be helpful if you can re-tune your heaters, and let me know what changes it made to the model parameters (it should be just the dead time) and how well they work for you.

If you have multiple independently-driven Z leadscrews and a Z probe, please try the new bed levelling feature, described at https://duet3d.com/wiki/Bed_levelling_using_multiple_independent_Z_motors, and let me kno how well it works.

Yonkiman

Just tried the new tuning algorithm with my E3D Lite6 with 25-30W heater.

1.18:
gain 425.8, time constant 223.1, dead time 6.0, max PWM 1.00, mode: PID

1.19beta10:
gain 465.7, time constant 217.8, dead time 4.3, max PWM 1.00, mode: PID
gain 469.1, time constant 220.6, dead time 4.2, max PWM 1.00, mode: PID

Not sure why the gains changed - it's possible I didn't have the sock on when I did it with 1.18 (or maybe I used a different target temp).

dc42

Thanks for the figures. It's not unusual for the gains to change a little with repeated runs, the measurement isn't perfect - and if you use a different target temperature, the gain will change a little too. I would expect with/without a sock to make more difference to the gain.

The dead time is what I am most interested in. I'm using a completely different mechanism to calculate the dead time, which I hope will be more accurate.

lars

Looks like "Bed levelling using multiple independent Z motors” did misalign my bed.
Have I missed something in my configuration?

result:

23:37:18 G32 Error: some computed corrections exceed configured limit of 0.50mm: 0.077 -0.267 0.785
23:36:40 G32 Error: some computed corrections exceed configured limit of 0.50mm: 0.035 -0.275 0.772
23:35:49 G32 Leadscrew adjustments made: -0.189 -0.146 0.377, points used 3, deviation before 0.202 after 0.000
23:34:28 G32 Leadscrew adjustments made: -0.304 -0.191 0.299, points used 3, deviation before 0.203 after 0.000

Front left lead screw (-60,-10) is connected to Z (drive 2)
Front right lead screw (560,-10) is connected to Y (drive 1)
Back centre lead screw (250,560) is connected to X (Drive 0)

config.g:

M584 Y5 X7 U8 V6 E3:4 Z0:1:2         ; Set up steppers for x, y, u, v, z and e, use P4 once it works to hide V
M671 X250:560:-60 Y560:-10:-10 S0.5  ; Set up lead screw positions for bed leveling

bed.cfg

T0
M401
G30 P0 X40 Y40 Z-99999      ; probe near a leadscrew
G30 P1 X250 Y460 Z-99999    ; probe near a leadscrew
G30 P2 X460 Y40 Z-99999 S3  ; probe near a leadscrew and calibrate 3 motors
M402
G90
G1 X250 Y250
T-1

Is the order or P parameter of G30 commands important?

Eddiie

Auto Delta Calibration just went all wonky in beta 10.
Head moves all over the place, eventually makes it to the probe point, then moves to the next one, sort of.
Here is a YouTube video showing what I mean -

…........................

Fixed by reading release notes.

Jackal

@Eddiie:

Auto Delta Calibration just went all wonky in beta 10.
Head moves all over the place, eventually makes it to the probe point, then moves to the next one, sort of.
Here is a YouTube video showing what I mean -

I think this has to do with

Probe deployment and retraction for G30 and G29 commands is now handled automatically. You should still include a M401 command before the first G30 command in bed.g and a M402 command after the last one, so that the probe deploys and retracts once for the entire sequence instead of once per G30 command.

I would try emptying deployprobe.g and retractprobe.g if it's not needed
Will give beta 10 a try when I get home tonight.

DjDemonD

Hi mine is doing this also, and I don't have a deployable probe or a deployprobe.g ot retractprobe.g file at all.

Back to beta9 for now I think.

dc42

To those of you with delta calibration issues: read the upgrade notes.

dc42

Lars, thanks for trying the leadscrew adjustment. To help me diagnose this, please do the following:

1. Create a copy of bed.g as a macro. In that macro, replace S3 on the last G30 command by S-1.

2. First run the macro, then G31. Repeat until the corrections are out of range. Post the output.

DjDemonD

Fixed thank you. I did have deployprobe and retractprobe macros.

However since we all know few if anyone reads the release notes, maybe that one could be in the original post above since it will affect almost everyone. Just saying realpolitik and all that.

fcwilt

So if I understand this the probe (if implemented) will deploy/retract with each G30 command?

If that is correct what is the purpose.

Thanks.

Frederick

dc42

@fcwilt:

So if I understand this the probe (if implemented) will deploy/retract with each G30 command?

If that is correct what is the purpose.

Thanks.

Frederick

It will only deploy and retract if it is not already deployed. So the behaviour is unchanged if you have M401 near the start of bed.g and M402 near the end.

minim

@DjDemonD:

Fixed thank you. I did have deployprobe and retractprobe macros.

However since we all know few if anyone reads the release notes, maybe that one could be in the original post above since it will affect almost everyone. Just saying realpolitik and all that.

I'd agreed for a stable release but I think most people beta testing actually reads the release notes. I do.

fcwilt

@dc42:

It will only deploy and retract if it is not already deployed. So the behaviour is unchanged if you have M401 near the start of bed.g and M402 near the end.

OK understood.

Under what circumstances would you want the probe to be deployed/retracted with each G30/G29 command?

Thanks for the reply.

Frederick

Jackal

@fcwilt:

@dc42:

It will only deploy and retract if it is not already deployed. So the behaviour is unchanged if you have M401 near the start of bed.g and M402 near the end.

OK understood.

Under what circumstances would you want the probe to be deployed/retracted with each G30/G29 command?

Thanks for the reply.

Frederick

I believe it is to avoid the probe not being deployed when executing G30/G29 as a single command
If you are doing bed compensation with multiple G30, you should use M401 M402

Jackal

Just installed beta 10, seems to be having a problem when showing the heightmap.
After calibration, the heightmap overlay appears, but it's empty
If I choose Show Mesh Grid Heightmap under Auto Delta Calibration the browser won't response and needs to restart.
Now sure if it's the problem with RRF or DWC 1.17+1.

edit: it seems to print normally, will look into it later and provide the config and bed files for investigation

dc42

@Jackal:

Just installed beta 10, seems to be having a problem when showing the heightmap.
After calibration, the heightmap overlay appears, but it's empty
If I choose Show Mesh Grid Heightmap under Auto Delta Calibration the browser won't response and needs to restart.
Now sure if it's the problem with RRF or DWC 1.17+1.

edit: it seems to print normally, will look into it later and provide the config and bed files for investigation

No need to look into it. I forgot to warn chrishamm about the change to the height map file to support different X and Y spacings. We'll have to wait for him to do a DWC 1.17+2 release.

dc42

@Jackal:

@fcwilt:

Under what circumstances would you want the probe to be deployed/retracted with each G30/G29 command?

Thanks for the reply.

Frederick

I believe it is to avoid the probe not being deployed when executing G30/G29 as a single command
If you are doing bed compensation with multiple G30, you should use M401 M402

That's right. Several people complained that G29 didn't deploy the probe automatically.

Jackal

Thanks David for the quick response

dc42

I have just released DuetEthernetFirmware1.19beta10+1. The primary reason for this release is that on some Duet Ethernet boards, it was not possible to flash new firmware using the web interface or M997 when a recent 1.19beta firmware version was installed. AFAIK this only affected the Duet Ethernet, so I have not released new binaries for the other Duets.