New experimental firmware 1.19beta9

dc42

@lars:

I get some weird behaviour when using the web interface Machine Control with second tool.

Test Setup:
Disable all tool change scripts.
Run home all (Script will inactivate both tools with T-1)
Switch to T0 and move it to -33 as I don’t want T1 to crash into it

Switch to T1
X -1

T1 moves to min position (-5) and stops to respond to X interface commands.
I can however move T1 using the g-code console: G1 X10 will move t1 to X10 absolute.
Once I have issued G1 X10 in the g-code console I can use the interface Machine Control again to move X.
If I switch T0 and back to T1 the first x command in the Machine Control will move T1 to min position (-5) and stops to respond to X interface commands.

I have tracked down this bug to how currentUserPosition is used in GCodes::DoStraightMove. After tool switch to T1 and a G1 X-1 is issued it currentUserPosition[0] (x-axis) has the value of T0 X (-33 in the quoted example). It will take this value and substract 1 for relative move of X. Later in the code this value (-32) is mapped to U and limited to min value -5 (So T1 will in my case move from 525 to -5 when issuing a relative move G1 X-1).
Either the currentUserPosition must be updated on tool change so that the X reflects the mapped tools coord or the mapping need to be done in DoStraightMove… Whats do you think David?

Thanks for investigating this. I'll take a look at it tomorrow. I thought we were already updating currentUserPosition on a tool change.

lars

Need to increment numXAxes, numYAxes in GCodes::ToolOffsetInverseTransform! Added in code below.

void GCodes::ToolOffsetInverseTransform(const float coordsIn[MaxAxes], float coordsOut[MaxAxes])
{
	const Tool * const currentTool = reprap.GetCurrentTool();
	if (currentTool == nullptr)
	{
		for (size_t axis = 0; axis < numVisibleAxes; ++axis)
		{
			coordsOut[axis] = coordsIn[axis]/axisScaleFactors[axis];
		}
	}
	else
	{
		const uint32_t xAxes = reprap.GetCurrentXAxes();
		const uint32_t yAxes = reprap.GetCurrentYAxes();
		float xCoord = 0.0, yCoord = 0.0;
		size_t numXAxes = 0, numYAxes = 0;
		for (size_t axis = 0; axis < numVisibleAxes; ++axis)
		{
			coordsOut[axis] = coordsIn[axis] + currentTool->GetOffset()[axis];
			if ((xAxes & (1u << axis)) != 0)
			{
				xCoord += coordsIn[axis]/axisScaleFactors[axis] + currentTool->GetOffset()[axis];
				numXAxes += 1; <-----------------
			}
			if ((yAxes & (1u << axis)) != 0)
			{
				yCoord += coordsIn[axis]/axisScaleFactors[axis] + currentTool->GetOffset()[axis];
				numYAxes += 1; <-----------------
			}
		}
		if (numXAxes != 0)
		{
			coordsOut[X_AXIS] = xCoord/numXAxes;
		}
		if (numYAxes != 0)
		{
			coordsOut[Y_AXIS] = yCoord/numYAxes;
		}
	}
	coordsOut[Z_AXIS] -= (currentZHop + currentBabyStepZOffset)/axisScaleFactors[Z_AXIS];
}

Eddiie

@dc42:

Ok, so you meant auto delta calibration, not bed levelling. It's working for me. When you get the Ajax Error message, what is the Error Reason given at the bottom of the error message box?

It is working for you using the same settings I posted above?

Communication Error
An AJAX error has been reported, so the current session has been terminated.
Please check if your printer is still on and try to connect again.
Error reason: timeout

Before going to beta9 I was on beta6 which worked ok for "auto delta calibration" button on the WebUI and on the Paneldue but wifi did not work reliably.

Testing betas 6, 7, 8, 9, my problem with auto delta calibration began with beta8. Any suggestions?

Changing bed.g, allows the calibration to be reported, but don't think it gets stored..

;G30 P15 X0 Y0 Z-99999 S7
G30 P15 X0 Y0 Z-99999 S-1

However, if I reverse the commands so that S-1 is done before S7, I get new message

G30 P15 X0 Y0 Z-99999 S-1
G30 P15 X0 Y0 Z-99999 S7

"Bed calibration error: 7 factor calibration requested but only 0 positions provided."
– I guess S-1 prints the values then empties the memory.
-- S4 behaves the sames as S7.

dc42

Eddiie, thanks for testing those firmware versions, know I know is where to look for the problem.

Lars, thanks again.

dc42

@Eddiie:

…
Before going to beta9 I was on beta6 which worked ok for "auto delta calibration" button on the WebUI and on the Paneldue but wifi did not work reliably.

Testing betas 6, 7, 8, 9, my problem with auto delta calibration began with beta8. Any suggestions?

Changing bed.g, allows the calibration to be reported, but don't think it gets stored..

;G30 P15 X0 Y0 Z-99999 S7
G30 P15 X0 Y0 Z-99999 S-1

However, if I reverse the commands so that S-1 is done before S7, I get new message

G30 P15 X0 Y0 Z-99999 S-1
G30 P15 X0 Y0 Z-99999 S7

"Bed calibration error: 7 factor calibration requested but only 0 positions provided."
-- I guess S-1 prints the values then empties the memory.
-- S4 behaves the sames as S7.

Thanks. Please can you connect Pronterface or another USB host program, then send M111 S1 P4 to enable Move module debug output. Then run your normal auto calibration routine. You should get a pile of output, something like this:

>>> m111s1p4
SENDING:M111S1P4
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)
; G31 sent here
Z probe offsets: 1.057 1.064 0.320 0.357 0.348 0.340 0.261 0.328 0.296 0.271 0.299 0.324 0.371 0.415 0.379 0.336, mean 0.423, deviation from mean 0.244
Stops X1.008 Y-0.638 Z-0.370 height 470.183 diagonal 360.290 radius 180.338 xcorr -0.15 ycorr 0.10 zcorr 0.00 xtilt -0.110% ytilt 0.020%
Derivative matrix
 ...
Normal matrix
 ...
Solved matrix
 ...
Solution: -0.9157 -1.8949  1.3887  0.2035  1.1017 -0.1917 -0.5625  2.2428
Residuals:  0.2199  0.1975 -0.3050  0.0289  0.1166  0.0552 -0.1193 -0.0617  0.0439  0.1128 -0.0040 -0.2779 -0.0455  0.0023  0.0606 -0.0241
Expected probe error:  0.2029  0.1733 -0.3350 -0.0003  0.0934  0.0381 -0.1296 -0.0632  0.0474  0.1124 -0.0110 -0.2896 -0.0661 -0.0194  0.0533 -0.0411
Derivative matrix
 ...
Normal matrix
 ...
Solved matrix
...
Solution:  0.0742  0.1298 -0.1810  0.0102 -0.0396  0.0284  0.0135 -0.1845
Residuals:  1.0768  1.0913  0.3501  0.3830  0.3720  0.3548  0.2685  0.3317  0.2945  0.2681  0.3044  0.3385  0.3790  0.4441  0.3915  0.3532
Expected probe error:  0.2226  0.2006 -0.3055  0.0260  0.1171  0.0532 -0.1225 -0.0601  0.0457  0.1097 -0.0060 -0.2755 -0.0582  0.0091  0.0657 -0.0243
Stops X0.633 Y-1.937 Z1.304 height 469.840 diagonal 360.290 radius 180.552 xcorr 0.92 ycorr -0.06 zcorr 0.00 xtilt -0.476% ytilt 1.392%

where … represents several rows of numbers. Please post that output.

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.