New experimental firmware 1.19beta9

Eddiie

I notice at the end of "auto delta calibration" that the serial port disconnects.
I am a network guy, my terminal of choice is currently Putty.

Here is the output:

Debugging enabled for modules: Move(4)
                                                 Debugging disabled for modules: Platform(0) Network(1) Webserver(2) GCodes(3) Heat(5) DDA(6) Roland(7) Scanner(8) PrintMonitor(9) Storage(10) PortControl(11)
                                              ok
                                                Z probe offsets: 3.972 2.639 2.760 2.408 2.649 3.463 3.923 2.348 3.903 1.253 0.840 0.557 0.731 0.944 1.210 0.114, mean 2.107, deviation from mean 1.269
                                       Stops X0.000 Y0.000 Z0.000 height 349.900 diagonal 215.000 radius 88.000 xcorr 0.00 ycorr 0.00 zcorr 0.00 xtilt 0.000% ytilt 0.000%

          Derivative matrix

Your radius is 180, mine is 88, radius is the middle to edge of print plate, right?

dc42

It sounds like your Duet is resetting after running auto calibration. So please run it again, then reconnect (via the web is fine) without resetting the Duet again and run M122. Post the data listed under "Least Reset Reason" and "Last software reset code".

Eddiie

I am using M997 to move between firmware versions. (bottom of this page: https://duet3d.com/wiki/DuetWiFiFirmware_1.19beta ). I notice after the upgrade that the DuetWiFiFirmware.bin file has been deleted but the DuetWiFiServer.bin file remains.

Thank you for your time looking in to this.

=== Diagnostics ===
Used output buffers: 1 of 32 (10 max)
=== Platform ===
RepRapFirmware for Duet WiFi version 1.19beta9 running on Duet WiFi 1.0 + DueX2
Board ID: *****-*****-*****-*****-*****-*****  (removed)
Static ram used: 20904
Dynamic ram used: 99352
Recycled dynamic ram: 2624
Stack ram used: 4000 current, 5212 maximum
Never used ram: 2980
Last reset 00:01:44 ago, cause: software
Last software reset reason: Hard fault, spinning module GCodes, available RAM 0 bytes (slot 1)
Software reset code 0x0033, HFSR 0x40000000, CFSR 0x00008200, ICSR 0x00400803, BFAR 0x29955924, SP 0x2001d3f4
Stack: 00440bb9 0044077a 81000000 200037f4 00000000 000003f9 00000007 e0000000 3fe12609 2001d578 3fe12609 00000000 ffffffe9 5555554c 00155555 97bcbd77 ffe5fe63 ee000000
Error status: 0
Free file entries: 10

```snip…

dc42

Thanks again. From that I can see that is it crashing in a part of the C library that converts floating point numbers to/from character strings using heap-allocated RAM. The never-used RAM in your M122 report is 4.5Kb less than mine is straight after a restart, and given how much extra stack is needed during auto calibration. it's clear that you have been running out of memory during the auto calibration calculation.

I'll increase the free memory headroom in the next beta. Are you using multiple tool definitions? That might explain why you have less free memory available than I do.

Eddiie

Ah that is it! I have 12 tools defined also a bunch of macros. Diamond hotend.
Most examples show 16 tools. I actually thought of having 32 tools or so. One set for cmy and another for rgb.
Maybe even more for other colors.
Virtual tools are awesome!

I can remove some until the next release. I only use about 8 at one time mostly. Thank you again.

Removed 2 tools, results were shown at then end of calibration, however AJAX error soon followed.
Removed 3 tools and everything seems to be working now.
Curious, how much RAM do you have to play with?
Note, the number of tools has not changed in my configuration for quite some time. Still, something in beta 8 changed to use more RAM.

dc42

Yes, beta 8 and 9 use more RAM than earlier versions, and I hadn't noticed how low the headroom had become. I'm reducing the maximum number of random probe points from 64 to 32 in beta 10, which will reduce the static memory requirement by 384 bytes and the auto calibration memory requirement by 3.6Kb (the calibration routine allocates matrices for the maximum allowed number of points). Now that we have mesh bed levelling too, using a large number of auto calibration points seems rather pointless to me.

On my delta running beta9 with just 1 tool configured, never used RAM is reported as 7284 if I send M122 immediately after startup, and 780 after running auto calibration.

I suggest you check that you still have some "never used RAM" left after you run auto calibration with whatever number of tools you want to define. Defining macros doesn't use additional RAM, but running nested macros or running multiple macros concurrently uses a little.

lars

Is there a change to how speed is set after tool change? In beta 9 I get a very slow (first?) move after tool change compared to beta6 (or was it beta 5)…
The gcode looks ok, setting a decent speed for first layer.Feels like the F6000 is ignored in [c]G0 F6000 X224.353 Y241.088 Z0.3[/c]

G1 X224.04 Y242.012 E10.5916
G1 X224.159 Y241.537 E10.60082
G1 X224.353 Y241.088 E10.61002
G1 F1200 E-5.38998
G92 E0
G91
G1 Z1 F1800 ; move bed down
G90
T1
G92 E0

M203 Z5
M109 S210
M104 T0 S180
G0 F6000 X224.353 Y241.088 Z0.3
G1 F1800 E-2
G0 F6000 X224.353 Y251.088
G0 X219.409 Y243.144
;TYPE:SKIRT
G1 F1800 E0
G1 F3000 X219.416 Y242.676 E0.00946

```I only have tfreeX.g tool change scrips.
tfree0.g:

G90
G1 X-33 F18000

G90
G1 X525 F18000

deckingman

@Eddiie:

Ah that is it! I have 12 tools defined also a bunch of macros. Diamond hotend.
Most examples show 16 tools. I actually thought of having 32 tools or so. One set for cmy and another for rgb.
Maybe even more for other colors.
Virtual tools are awesome!

I can remove some until the next release. I only use about 8 at one time mostly. Thank you again.
…....................................................

Eddie. Another way to manage tools with a Diamond is to keep a simple set of tools defined in config.g then define more tools or change mixing ratios in your slicer start gcode. It has the advantage that whenever you print the object, the right mixing ratios will be set (you just need to load the correct filament into each extruder).

dc42

@lars:

Is there a change to how speed is set after tool change? In beta 9 I get a very slow (first?) move after tool change compared to beta6 (or was it beta 5)…

That may be a side-effect of the bug reported and fixed by lars. The fix will be included in beta 10.

tomasf

Yay, beta 9 actually successfully connects to my regular WiFi network, unlike earlier (beta 7) versions of 1.19. The connection seems stable and fast so far. Good job!

dc42

Thanks for your feedback!

Eddiie

Yeah, beta9 fixed wifi issues for me too. Sorry for not saying that.

Bring on Beta 10!!

lars

@dc42:

@lars:

Is there a change to how speed is set after tool change? In beta 9 I get a very slow (first?) move after tool change compared to beta6 (or was it beta 5)…

That may be a side-effect of the bug reported and fixed by lars. The fix will be included in beta 10.

Hmm… could you hint at what could be done to fix the speed problem? It's very frustrating trying to print atm so if I could fix the speed problem in my branch it would be a huge help...

dc42

Hi lars, is the speed problem still present in beta10? Please respond in the thread on beta10 if is is.