New firmware 1.21RC1 available

dc42

I have just made this available at https://github.com/dc42/RepRapFirmware/tree/dev/EdgeRelease. This release adds several new features requested by users, and fixes a number of (mostly minor) bugs. See https://github.com/dc42/RepRapFirmware/blob/dev/WHATS_NEW.md for the release notes.

Captain_sq

Hi David,
Exerpt: [c]Ported DHCP changes from LWIP 2 to Duet 06/085 build[/c]

I guess this is the DHCP fix for my 0.6 board. I'll check it out a s a p.

Thanks a bunch!
/Thom

garyd9

I don't see it in the release notes, and the thread kind of scrolled away… is there anything I can do to help track down the issue of "M116 P#" commands being ignored under certain circumstances?

(To refresh, here's the thread: https://www.duet3d.com/forum/thread.php?id=4018))

resam

Thanks for the new RC!

I can confirm that the FTP bug (reported in https://www.duet3d.com/forum/thread.php?id=3864#p34353 ) is now fixed.
I can successfully download all files with this command: [c]wget -r -nH ftp://10.0.0.42/sys/[/c]

mrac1

Hi David, do you have an example for the M558 S parameter?

GrodanB

The M558 Ax is the result from the bed mesh leveling then averaged IF both results are withing the S parameters tolerance?

So

[[GCode]]
M558 P1 X0 Y0 Z1 H3 F200 T4000      		; Smart IR Z probe, used for homing Z axis, dive height 3mm, probe speed 200mm/min, travel speed 5000mm/min

```Updated to:

[[GCode]]
M558 P1 X0 Y0 Z1 H3 F200 T4000 A2 S0.005 ; Smart IR Z probe, used for homing Z axis, dive height 3mm, probe speed 200mm/min, travel speed 5000mm/min, 2 measure average, tolerance 5µm (assuming mm as the unit)

Correct?
I assume here that the tolerance is really the "biggest allowed difference between numbers"

(tolerance is based on my data from my bed level thread:

> M98 P0:/macros/ProbeRepeatability
> G32 bed probe heights: 0.054 0.055 0.054 0.054 0.053 0.053 0.054 0.054 0.054 0.054 0.050 0.053 0.053 0.054 0.052 0.051 0.053 0.053 0.052 0.052 0.053 0.052 0.052 0.054 0.051 0.051 0.052 0.052 0.053 0.053 0.053 0.054, mean 0.053, deviation from mean 0.001

This shows that 0.005 is 5 times deviation and four seems the biggest differance
)
If G32 would give a probe minimum tolerance it would be nice.

If so, what happens if we are not within the tolerance?

dc42

You need to use either A1 (default) or A > 2 because A2 doesn't allow any retries. So use something like A5 S0.01.

GrodanB

Understood.

So it dumps the data that is outside the tolerance.

So a badly set tolerance or a bad sensor just add time.

Will it use the first value if all other is outside tolerances?

~~So a user really should test the probe repeat-ability.~~

Ahh testing is king… Ok. A5 is not measuring points to average, it is retries... Two valid measurements is what is used.

okercho

Not sure if I understood hoy the multi-touch works, I think it does two, and if the tolerance is less than the configured, then it moves to the next one, if the tolerance is bigger, it repeats until A is reached (or the tolerance is lower than the configured).

One improvement that should be easy, can you add to the Error message ("Error: Z probe readings not consistent") the tolerance? in that way you can check how far you are…

I've done a couple of printings so far, and looks good, the only thing is the wifi error I've reported in the other post.

Regards

dc42

@okercho:

Not sure if I understood hoy the multi-touch works, I think it does two, and if the tolerance is less than the configured, then it moves to the next one, if the tolerance is bigger, it repeats until A is reached (or the tolerance is lower than the configured).

That's correct.

@okercho:

One improvement that should be easy, can you add to the Error message ("Error: Z probe readings not consistent") the tolerance? in that way you can check how far you are…

Which value(s) should it print? Perhaps the difference between the minimum and the maximum heights read?

Captain_sq

I hate to be bearer of bad news but DHCP still don't work on my 0.6 board. However, the status printout varies a bit. I have two different causes of watchdog triggers. First status message blames the platform module as the culprit. See below

[[language]]
(16:48:43.802) M122
(16:48:43.938) === Diagnostics ===
(16:48:43.938) Used output buffers: 1 of 32 (1 max)
(16:48:43.938) === Platform ===
(16:48:43.938) RepRapFirmware for Duet version 1.21RC1 running on Duet 0.6
(16:48:43.938) Static ram used: 44836
(16:48:43.938) Dynamic ram used: 40772
(16:48:43.938) Recycled dynamic ram: 408
(16:48:43.938) Stack ram used: 3520 current, 4316 maximum
(16:48:43.938) Never used ram: 7972
(16:48:43.938) Last reset 00:00:38 ago, cause: software
(16:48:43.938) Last software reset time unknown, reason: Stuck in spin loop, spinning module Platform, available RAM 8032 bytes (slot 2)
(16:48:43.938) Software reset code 0x2040 HFSR 0x00000000, CFSR 0x00000000, ICSR 0x0440f00f, BFAR 0xe000ed38, SP 0x20087e04
(16:48:43.938) Stack: 000c0f57 00000001 fffffff1 00000001 20087e5c 20070fe8 00000001 20087e5c 000a7583 000a7e54 2100003a 00000000 0000012c 00000123 00000000 2007376c 200737a8 2007a938 00000127 2007aea8 000000f0 2007a938 01c8a8c0 2007376c
(16:48:43.938) Error status: 0
(16:48:43.938) Free file entries: 10
(16:48:43.938) SD card 0 detected, interface speed: 21.0MBytes/sec
(16:48:43.938) SD card longest block write time: 0.0ms
(16:48:43.938) MCU temperature: min 23.7, current 25.3, max 25.5
(16:48:43.938) Date/time: 1970-01-01 00:00:00
(16:48:43.938) Slowest main loop (seconds): 0.000399; fastest: 0.000100
(16:48:43.938) === Move ===
(16:48:43.938) MaxReps: 0, StepErrors: 0, LaErrors: 0, FreeDm: 100, MinFreeDm 100, MaxWait: 0ms, Underruns: 0, 0
(16:48:43.938) Scheduled moves: 0, completed moves: 0
(16:48:43.938) Bed compensation in use: mesh
(16:48:43.938) Bed probe heights: 0.000 0.000 0.000 0.000 0.000
(16:48:43.938) === Heat ===
(16:48:43.938) Bed heaters = 0, chamberHeaters = -1 -1
(16:48:43.938) Heater 1 is on, I-accum = 0.0
(16:48:43.938) === GCodes ===
(16:48:43.938) Segments left: 0
(16:48:43.938) Stack records: 2 allocated, 0 in use
(16:48:43.938) Movement lock held by null
(16:48:43.938) http is idle in state(s) 0
(16:48:43.938) telnet is idle in state(s) 0
(16:48:43.938) file is idle in state(s) 0
(16:48:43.938) serial is ready with "M122" in state(s) 0
(16:48:43.938) aux is idle in state(s) 0
(16:48:43.938) daemon is idle in state(s) 0
(16:48:43.938) queue is idle in state(s) 0
(16:48:43.938) autopause is idle in state(s) 0
(16:48:43.938) Code queue is empty.
(16:48:43.938) === Network ===
(16:48:43.938) Free connections: 16 of 16
(16:48:43.938) Free transactions: 24 of 24
(16:48:43.938) Locked: 0, state: 2, listening: 0x0, 0x0, 0x0
(16:48:43.938)

And the usual cause…

[[language]]
(16:51:17.869) === Diagnostics ===
(16:51:17.869) Used output buffers: 1 of 32 (1 max)
(16:51:17.869) === Platform ===
(16:51:17.869) RepRapFirmware for Duet version 1.21RC1 running on Duet 0.6
(16:51:17.869) Static ram used: 44836
(16:51:17.869) Dynamic ram used: 40772
(16:51:17.869) Recycled dynamic ram: 408
(16:51:17.869) Stack ram used: 3520 current, 4316 maximum
(16:51:17.869) Never used ram: 7972
(16:51:17.869) Last reset 00:00:02 ago, cause: software
(16:51:17.869) Last software reset time unknown, reason: Stuck in spin loop, spinning module Network, available RAM 8032 bytes (slot 3)
(16:51:17.869) Software reset code 0x2041 HFSR 0x00000000, CFSR 0x00000000, ICSR 0x0440f80f, BFAR 0xe000ed38, SP 0x20087e64
(16:51:17.869) Stack: 000c0f57 200711f8 fffffff9 00000000 20087ebc 20070fe8 200711f8 20087ebc 000a756d 000a7e62 21000000 2007a9ac 0000012c 00000123 00000000 2007376c 200737a8 2007a938 00000127 2007aea8 000000f0 75207369 01c8a8c0 2007376c
(16:51:17.869) Error status: 0
(16:51:17.869) Free file entries: 10
(16:51:17.869) SD card 0 detected, interface speed: 21.0MBytes/sec
(16:51:17.869) SD card longest block write time: 0.0ms
(16:51:17.869) MCU temperature: min 25.3, current 25.5, max 25.6
(16:51:17.869) Date/time: 1970-01-01 00:00:00
(16:51:17.869) Slowest main loop (seconds): 0.000378; fastest: 0.000100
(16:51:17.869) === Move ===
(16:51:17.869) MaxReps: 0, StepErrors: 0, LaErrors: 0, FreeDm: 100, MinFreeDm 100, MaxWait: 0ms, Underruns: 0, 0
(16:51:17.869) Scheduled moves: 0, completed moves: 0
(16:51:17.869) Bed compensation in use: mesh
(16:51:17.869) Bed probe heights: 0.000 0.000 0.000 0.000 0.000
(16:51:17.869) === Heat ===
(16:51:17.869) Bed heaters = 0, chamberHeaters = -1 -1
(16:51:17.869) Heater 1 is on, I-accum = 0.0
(16:51:17.869) === GCodes ===
(16:51:17.869) Segments left: 0
(16:51:17.869) Stack records: 2 allocated, 0 in use
(16:51:17.869) Movement lock held by null
(16:51:17.869) http is idle in state(s) 0
(16:51:17.869) telnet is idle in state(s) 0
(16:51:17.869) file is idle in state(s) 0
(16:51:17.869) serial is ready with "M122" in state(s) 0
(16:51:17.869) aux is idle in state(s) 0
(16:51:17.869) daemon is idle in state(s) 0
(16:51:17.869) queue is idle in state(s) 0
(16:51:17.869) autopause is idle in state(s) 0
(16:51:17.869) Code queue is empty.
(16:51:17.869) === Network ===
(16:51:17.869) Free connections: 16 of 16
(16:51:17.869) Free transactions: 24 of 24
(16:51:17.869) Locked: 0, state: 2, listening: 0x0, 0x0, 0x0
(16:51:17.869)

okercho

@dc42:

Which value(s) should it print? Perhaps the difference between the minimum and the maximum heights read?

LOL, that's a good question, I was thinking about the value that you use to decide whether to continue or to reject (not sure if it's the mean or the deviation) , but maybe the min and max are interesting values too.

dc42

The firmware looks for 2 consecutive readings to differ by no more than the tolerance. So perhaps the best figure to show is the lowest difference seen between consecutive readings.

Jackal

I have just updated from 1.20 to 1.21RC1 and not sure why the mesh bed compensation shows a rectangular bed instead of a circular bed for my delta. I didn't change my config.g, maybe I missed something that I should change?

I have M558 P1 R0.4 X0 Y0 Z0 H1.5 F100 T3000 I0 in my config.g and M557 R100 S15 in my bed.g

okercho

@dc42:

The firmware looks for 2 consecutive readings to differ by no more than the tolerance. So perhaps the best figure to show is the lowest difference seen between consecutive readings.

Sounds good

GrodanB

Maybe should add: All working fine here as far as I can see on my Dual E3D BigBox. 1.21RC1 with DuetWifi 1.0 and duex5.

dc42

@GrodanB:

Maybe should add: All working fine here as far as I can see on my Dual E3D BigBox. 1.21RC1

Thanks for the feedback.

resam

Would it make sense to use the new multi-tap feature and modify it to do e.g. 3 taps and average them?
My BLtouch has quite large variance in its probe distance. So I think taking the average of multiple points could be used to counteract this - or am I missing some important math/statistics here?

DjDemonD

Installed on corexy running duetwifi printing now no issues. Printed fine, also installed on delta no issues.

okercho

Not sure if this is a bug or that is intended, but it's something that worked differently to what I was expecting

I've noticed that G31 Z is not adjusted "live" even if I change it, I mean, I setup a Z offset (while printer is idle), then I do a mesh level (G29 S0), and I make a test print… if I stop because I want to change Z offset, that Z offset is not applied until I do a new mesh level or I restart the printer, even though the machine properties reflect the new offset.

This is not new to this RC, I noticed it during some testing I was doing several days ago, but I wasn't sure until today, when I performed a test (configure Z at -0.14, print, check, stop print, configure Z at -1.14, print, check<<same result="">>, refresh mesh, print<<1mm higher than before>>).

Regards</same>