New experimental firmware 1.19beta9

lars

Hmm, my DuetWifi is having a hard time connecting to my wireless network since upgrading to one of the betas.
Sometimes it works, sometimes it doesn't.
Anyone else have this problem? It used to work fine.

Yes, although in beta9 connecting have worked better for me. Did ten or so restarts and it connected each time. Got one AJAX disconnect during the hour I was testing it and had to M552 S0 M552 S1 to get it to work again.

Eddiie

I went to beta9, Wifi works better but now bedleveling causes AJAX error at the end.
Going to try beta8

fcwilt

Hi,

OK I must be doing something stupid.

I am trying out your IR probe for as my Z-probe under 1.19beta9 firmware with 1.15a DWC (because I cannot get it to upgrade).

With a simple G30 command I can trigger the IR probe and movement stops.

With something like G30 X0 Y0 X-99999 H0 the IR probe seem to be ignored. I can see the red light come up but the movement continues until it impacts the bed.

This used to do what I expected with a micro-switch as a Z-probe. However the micro-switch had a active reading of 1000 but the IR probe is around 530 or so. In each case I used a threshold value of 500.

What am I doing wrong?

Thanks.

Frederick

Eddiie

Ack, beta8 is worse for wifi.

"WiFi reported error: Unexpected WiFi state 'idle' while trying to connect to Wifi module is idle"
(the third WiFi in the above quote is missing a capital F.. hehe)

trying beta7..

Eddiie

Beta7 was bad for wiifi..
going back to beta9, hoping something in bed.g is incorrect or new version.
?

dc42

Several issues to deal with here.

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.

Problems upgrading/downgrading firmware: this seems to affect a few users, and I have one board that exhibits this problem too. I will look into this shortly. Meanwhile, if this affects you then I suggest you use SAM-BA or Bossa/bossac 1.8 instead.

WiFi connectivity: DuetWebServer 1.19beta9 fixes a bug that caused the WiFi module to try to connect to the wrong access point in some configurations. If you were already connecting successfully using beta8, there should be no difference.

Access point mode: the 1.19beta series of DuetWebServer does not currently go into access point mode if it fails to connect to an access point, unlike earlier versions. We're currently grappling with an apparent bug in the ESP8266 SDK that causes incoming packets to be lost when it is in access point mode.

G30 command: there was a major rework of the G30 code in beta8, so it's not impossible that a bug has crept in. However, autocalibration and bed compensation work for me, and I've not seen any reports of problems with G30 before the one in this thread.

fcwilt

@dc42:

Several issues to deal with here.

G30 command: there was a major rework of the G30 code in beta8, so it's not impossible that a bug has crept in. However, autocalibration and bed compensation work for me, and I've not seen any reports of problems with G30 before the one in this thread.

I will revert to beta8 and see if I experience the same problem.

Will report back.

Thanks.

Frederick

DjDemonD

No issue with G30 from me, I have used it in a delta bed.g file and to reset Z at bed centre and then spot check with the S-1 switch, all worked perfectly.

adri84dj

@dc42:

Several issues to deal with here.

Problems upgrading/downgrading firmware: this seems to affect a few users, and I have one board that exhibits this problem too. I will look into this shortly. Meanwhile, if this affects you then I suggest you use SAM-BA or Bossa/bossac 1.8 instead.

Ok, we keep waiting and we are attentive to the solution to be able to update. Thank you

Eddiie

Did something change with bed.g from previous versions? My kossel completes the pattern, last step was to move the head out of the way by moving it up. In beta9 after the pattern is complete, the head stops, web page gets a connection error (AJAX error), panel due continues to work, no result is shown after bed leveling. It used to says before: 2.88 now 0.015.

Can't get wifi working without fussing on anything less than beta9. Maybe removing the wifi network from the configuration and adding it again would help..

dc42

The bed probing code was reworked in beta 8 but there was no intentional change in functionality apart from adding the option of manual "bed probing".

In beta 9 the only change is that on a Cartesian printer, if you have used M671 to define the bed leadscrew positions, then the final G30 command with the S parameter computes the leadscrew adjustment instead of doing 3, 4 or 5 point bed compensation.

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?

MrBlom

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

DjDemonD

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

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

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…

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?