New experimental firmware 1.19beta9

DjDemonD

Yeah I just noticed this on my corexy, had to swap the y motor direction in the end. Working now.

deckingman

same as cubexupgrade cant get the X and Y working
on a corexy
they are swaped

See the Big Bold letters in DC's original post

lars

Lars, thanks for running that. If you want to try fixing it yourself, I believe the issue is with CoreBaseKinematics.cpp line 47. It should call ZLeadscrewKinematics::Configure not Kinematics::Configure.

Did the change you suggested and got it working:

M671
Z leadscrew coordinates (250.0,560.0) (560.0,-10.0) (-60.0,-10.0), maximum correction 0.50mm
G32
Simulated calibrating 3 leadscrews using 3 points, deviation before 0.098 after 0.000, corrections: -0.189 -0.065 0.118

Found one small bug in ZLeadscrewKinematics::Configure:

bool seenS;
gb.TryGetFValue('S', maxCorrection, seenS);

Need to initialize seenS to false or you will not get reporting of current settings…

MrBlom

@deckingman:

@MrBlom:

same as cubexupgrade cant get the X and Y working
on a corexy
they are swaped

See the Big Bold letters in DC's original post

this dident work for me
Important! On a CoreXY machine, you need to either swap the X and Y motor connections, or set the Y axis factor to -1 in the M667 command. Similarly for CoreXZ and CoreXYU machines.

Eddiie

@dc42:

Eddie, what happens if you command bed levelling from PanelDue and then look at the Console page? When you say 'bed levelling' do you mean G31 auto calibration, or G29 mesh bed compensation?

The console says nothing more after successfully connected to the network and showing the ip address.
strange.

I am not sure what the bed leveling button issues as a leveling command; I meant to ask that -

WebUI says "Auto Delta Calibration" (button) clicking the drop-down there are options, of course, Run mesh, Show Mesh, etc… Selecting these says there is no valid grid defined for G29.

Here is the contents of my bed.g, - OH, I guess this is G31, Auto. Tthe Paneldue and WebUI appear to execute the same function when pressing the button.
Can try other betas if you want me to. This is the same bed.g that has been in use since I owned the board.

; Auto calibration routine for delta printers
; Before running this, you should have set up your zprobe Z offset to suit your build, in the G31 command in config.g.

M561						; clear any bed transform, otherwise homing may be at the wrong height
G31 X0 Y0					; don't want any probe offset for this
G28						; home the printer
;G1 X0 Y0 Z350 F8000

;*** Remove the following line if your Z probe does not need to be deployed
;M98 Pdeployprobe.g			; deploy the mechanical Z probe

; The first time the mechanical probe is used after deployment, it gives slightly different results.
; So do an extra dummy probe here. The value stored gets overwritten later. You can remove this if you use an IR probe.
;G30 P0 X0 Y0 Z-99999

; Probe the bed and do 6- or 7-factor auto calibration

; bed.g file for RepRapFirmware, generated by Escher3D calculator
; 16 points, 7 factors, probing radius: 75, probe offset (12, 0)
G30 P0 X0.00 Y74.06 Z-99999 H0
G30 P1 X38.45 Y46 Z-99999 H0
G30 P2 X63.79 Y11.25 Z-99999 H0
G30 P3 X56.91 Y-32.86 Z-99999 H0
G30 P4 X14.08 Y-66.15 Z-99999 H0
G30 P5 X-25.65 Y-70.48 Z-99999 H0
G30 P6 X-64.95 Y-37.50 Z-99999 H0
G30 P7 X-53.86 Y13.02 Z-99999 H0
G30 P8 X-48.21 Y57.45 Z-99999 H0
G30 P9 X0.00 Y35.72 Z-99999 H0
G30 P10 X25.23 Y14.57 Z-99999 H0
G30 P11 X25.23 Y-14.57 Z-99999 H0
G30 P12 X0.00 Y-35.72 Z-99999 H0
G30 P13 X-32.48 Y-18.75 Z-99999 H0
G30 P14 X-32.48 Y18.75 Z-99999 H0
G30 P15 X0 Y0 Z-99999 S7

;*** Remove the following line if your Z probe does not need to be retracted
;M98 Pretractprobe.g				; retract the mechanical Z probe

G1 X0 Y0 Z150 F15000			; get the head out of the way of the bed

The G1 X0 Y0 Z150 F1500 no longer does anything or does not get executed.
Let me try commenting out that line real quick as a test..
– Commenting out the G1 line had no affect.

Let me try removing F30 P15 line.
Ok, commenting G30 P15 X0 Y0 Z-99999 S7 out, the script completed.
However, it never reports the before and after settings. So that line is probably where the problem is.

One last note:
Hitting the button from the paneldue does not cause an AJAX error on the WebUI. Whereas, clicking the button in the webUI to level the bed, will generate an AJAX error, on the Paneldue console it will say "connected to wifi network" and show the ip address it obtained, again. So something restarts when issuing the command from the WebUI that does not restart when doing it from the Paneldue. I gunna say the S7 parameter is what causes something bad to happen. The head moves to that location.. the very next thing is S7.

Let me know if there is more I can do.

tape

hello after firmware update for 1.19beta the wifi module stoped responding,
Upload successful
WiFi module started
Error: Failed to initialise WiFi module, code -10
[ERROR] Error: Failed to initialise WiFi module, code -10

what can i do to fix this?
thanks in advance

A Former User

@tape: Do you mean "update from 1.19 beta"? Please check if all the firmware versions are correct or just try flashing Firmware/Server again.

My question:
In standalone access point mode (M589 S"DuetWifi" P"Silverspoon" I192.168.1.1 –> M552 S2) I can connect to the DuetWifi.
DHCP works as I get an IP adress but "ping 192.168.1.1" leads to "Destination Host Unreachable".
So I don't have access to the web interface. However the Web Control was accessible before when connecting to a known network (mode M552 S1).

lars

@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?

dc42

@lars:

@dc42:

Lars, thanks for running that. If you want to try fixing it yourself, I believe the issue is with CoreBaseKinematics.cpp line 47. It should call ZLeadscrewKinematics::Configure not Kinematics::Configure.

Did the change you suggested and got it working:
M671
Z leadscrew coordinates (250.0,560.0) (560.0,-10.0) (-60.0,-10.0), maximum correction 0.50mm
G32
Simulated calibrating 3 leadscrews using 3 points, deviation before 0.098 after 0.000, corrections: -0.189 -0.065 0.118
Found one small bug in ZLeadscrewKinematics::Configure:
bool seenS;
gb.TryGetFValue('S', maxCorrection, seenS);
Need to initialize seenS to false or you will not get reporting of current settings…

Thanks, I've just put that fix in my source code.

dc42

@tape:

hello after firmware update for 1.19beta the wifi module stoped responding,
Upload successful
WiFi module started
Error: Failed to initialise WiFi module, code -10
[ERROR] Error: Failed to initialise WiFi module, code -10

what can i do to fix this?
thanks in advance

Were you upgrading from version 1.18.2 or earlier? If so, did you follow the instructions at https://duet3d.com/wiki/DuetWiFiFirmware_1.19beta as specified in the first post in this thread?

dc42

@Eddiie:

@dc42:

Eddie, what happens if you command bed levelling from PanelDue and then look at the Console page? When you say 'bed levelling' do you mean G31 auto calibration, or G29 mesh bed compensation?

The console says nothing more after successfully connected to the network and showing the ip address.
strange.

I am not sure what the bed leveling button issues as a leveling command; I meant to ask that -

WebUI says "Auto Delta Calibration" (button) clicking the drop-down there are options, of course, Run mesh, Show Mesh, etc… Selecting these says there is no valid grid defined for G29.

Here is the contents of my bed.g, - OH, I guess this is G31, Auto. Tthe Paneldue and WebUI appear to execute the same function when pressing the button.
Can try other betas if you want me to. This is the same bed.g that has been in use since I owned the board.
; Auto calibration routine for delta printers
; Before running this, you should have set up your zprobe Z offset to suit your build, in the G31 command in config.g.

M561						; clear any bed transform, otherwise homing may be at the wrong height
G31 X0 Y0					; don't want any probe offset for this
G28						; home the printer
;G1 X0 Y0 Z350 F8000

;*** Remove the following line if your Z probe does not need to be deployed
;M98 Pdeployprobe.g			; deploy the mechanical Z probe

; The first time the mechanical probe is used after deployment, it gives slightly different results.
; So do an extra dummy probe here. The value stored gets overwritten later. You can remove this if you use an IR probe.
;G30 P0 X0 Y0 Z-99999

; Probe the bed and do 6- or 7-factor auto calibration

; bed.g file for RepRapFirmware, generated by Escher3D calculator
; 16 points, 7 factors, probing radius: 75, probe offset (12, 0)
G30 P0 X0.00 Y74.06 Z-99999 H0
G30 P1 X38.45 Y46 Z-99999 H0
G30 P2 X63.79 Y11.25 Z-99999 H0
G30 P3 X56.91 Y-32.86 Z-99999 H0
G30 P4 X14.08 Y-66.15 Z-99999 H0
G30 P5 X-25.65 Y-70.48 Z-99999 H0
G30 P6 X-64.95 Y-37.50 Z-99999 H0
G30 P7 X-53.86 Y13.02 Z-99999 H0
G30 P8 X-48.21 Y57.45 Z-99999 H0
G30 P9 X0.00 Y35.72 Z-99999 H0
G30 P10 X25.23 Y14.57 Z-99999 H0
G30 P11 X25.23 Y-14.57 Z-99999 H0
G30 P12 X0.00 Y-35.72 Z-99999 H0
G30 P13 X-32.48 Y-18.75 Z-99999 H0
G30 P14 X-32.48 Y18.75 Z-99999 H0
G30 P15 X0 Y0 Z-99999 S7

;*** Remove the following line if your Z probe does not need to be retracted
;M98 Pretractprobe.g				; retract the mechanical Z probe

G1 X0 Y0 Z150 F15000			; get the head out of the way of the bed
The G1 X0 Y0 Z150 F1500 no longer does anything or does not get executed.
Let me try commenting out that line real quick as a test..
– Commenting out the G1 line had no affect.

Let me try removing F30 P15 line.
Ok, commenting G30 P15 X0 Y0 Z-99999 S7 out, the script completed.
However, it never reports the before and after settings. So that line is probably where the problem is.

One last note:
Hitting the button from the paneldue does not cause an AJAX error on the WebUI. Whereas, clicking the button in the webUI to level the bed, will generate an AJAX error, on the Paneldue console it will say "connected to wifi network" and show the ip address it obtained, again. So something restarts when issuing the command from the WebUI that does not restart when doing it from the Paneldue. I gunna say the S7 parameter is what causes something bad to happen. The head moves to that location.. the very next thing is S7.

Let me know if there is more I can do.

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?

dc42

@nokian:

@tape: Do you mean "update from 1.19 beta"? Please check if all the firmware versions are correct or just try flashing Firmware/Server again.

My question:
In standalone access point mode (M589 S"DuetWifi" P"Silverspoon" I192.168.1.1 –> M552 S2) I can connect to the DuetWifi.
DHCP works as I get an IP adress but "ping 192.168.1.1" leads to "Destination Host Unreachable".
So I don't have access to the web interface. However the Web Control was accessible before when connecting to a known network (mode M552 S1).

There is a bug that is causing message packets to be lost when the WiFi module is put into access point mode. We haven't tracked it down yet. Some other projects are having the same problem, so it looks like the bug may be in SDK code that is closed source.

dc42

@lars:

@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…