New experimental firmware 1.19beta9

dc42

I've just released this in the appropriate Edge subfolders within https://github.com/dc42/RepRapFirmware/tree/dev/Release.

This release includes a number of bug fixes to the previous 1.19betas, along with an initial implementation of two major new features:

Bed levelling using multiple independent Z motors (incomplete), see https://duet3d.com/wiki/Bed_levelling_using_multiple_independent_Z_motors
Resume print after power fail, see https://duet3d.com/wiki/Setting_up_to_resume_a_print_after_a_power_failure

For the full change list and upgrade notes (CoreXY users please note), see https://github.com/dc42/RepRapFirmware/blob/dev/WHATS_NEW.md.

Only users who need the new features or bug fixes, or who are already running an older 1.19 beta version, should upgrade to this one. Anybody upgrading a Duet WiFi from 1.18.2 or earlier should read https://duet3d.com/wiki/DuetWiFiFirmware_1.19beta first.

I have also released DuetWiFiServer 1.19beta9 to go with this release. You don't need to do a simultaneous upgrade of both firmwares if you are already using 1.19beta firmware, but the network section of the M122 report may be a little strange if you mix firmware versions.

As with all betas, his version is likely to contain bugs. Use it with caution, for example reduce your motor currents until you are happy that it is behaving correctly.

Hugues

Hi David,

For corexy user, do you advice to upgrade with this edge ? Is this kinematic change will also correct difficulties to setup a pressure advance setting ?

Thanks,
Hugues

dc42

I haven't made any changes to pressure advance in this beta release, but I did in the previous one.

Hugues

I just update my core xy and i'm unable to get the good order for X and Y, I tried to swap motor connector and i'm still getting my X moving when asking the Y (invert also available..)

I've tried M667 S1 Y-1 but i'm getting same result, what was wrong ?

lars

Three runs of bed levelling, working as expected as far as I can tell (just reporting).
Bed equation fits points [40.0, 40.0, 0.037] [250.0, 460.0, 0.174] [460.0, 40.0, 0.049]
Bed equation fits points [40.0, 40.0, 0.037] [250.0, 460.0, 0.171] [460.0, 40.0, 0.045]
Bed equation fits points [40.0, 40.0, 0.027] [250.0, 460.0, 0.179] [460.0, 40.0, 0.048]

Still have same problem as described for beta8 (https://www.duet3d.com/forum/thread.php?id=1936#p17856) when switching to second tool (remaping x).

dc42

@lars:

Three runs of bed levelling, working as expected as far as I can tell (just reporting).
Bed equation fits points [40.0, 40.0, 0.037] [250.0, 460.0, 0.174] [460.0, 40.0, 0.049]
Bed equation fits points [40.0, 40.0, 0.037] [250.0, 460.0, 0.171] [460.0, 40.0, 0.045]
Bed equation fits points [40.0, 40.0, 0.027] [250.0, 460.0, 0.179] [460.0, 40.0, 0.048]

Still have same problem as described for beta8 (https://www.duet3d.com/forum/thread.php?id=1936#p17856) when switching to second tool (remaping x).

That's not the bed levelling report, it's the standard bed compensation report. It's not running the bed levelling code. This could mean that you haven't set it up using M671, or you are not actually running firmware beta9 because the firmware update failed.

lars

It is reporting 1.19beta9:

Firmware Name:	RepRapFirmware for Duet WiFi
Firmware Electronics:	Duet WiFi 1.0 + DueX5
Firmware Version:	1.19beta9 (2017-07-10)
WiFi Server Version:	1.19beta9
Web Interface Version:	1.16

config.g:

M584 Y5 X7 U8 V6 E3:4 Z0:1:2         ; Set up steppers for x, y, u, v, z and e, use P4 once it works to hide V
M671 X250:560:-60 Y560:-10:-10 S0.5  ; Set up lead screw positions for bed leveling

And I had to change direction for for Y and V.

bed.g:

T0
M401
G30 P0 X40 Y40 Z-99999      ; probe near a leadscrew
G30 P1 X250 Y460 Z-99999    ; probe near a leadscrew
G30 P2 X460 Y40 Z-99999 S3  ; probe near a leadscrew and calibrate 3 motors
M402
G90
G1 X250 Y250
T-1

dc42

If you run M671 with no parameters, does it report the leadscrew positions that you configured?

I'm sorry you still have the tool change problem, I thought I had fixed that.

DjDemonD

So I have beta 8 on my corexy which has a v1.02 board, no issues there.

Decided to install beta9 on my kossel XL which has one of the x/500 1st production 1.0 boards. Interestingly the 1.02 board wifi is 3.5 times faster transferring a file than the 1.0 board.

Followed the procedure, no problems, installed everything, got my wifi up and running.

Then I'm getting AJAX disconnects all over the place, barely keeps connected for 5 seconds. Especially bad if I was on the "G-code files" page on DWC literally disconnects after a few seconds, but its much more stable if I'm on any other page. I had quite a lot of gcode files, so I deleted them from the memory card and that seemed to improve it a bit.

Before this upgrade, wifi was solid. I have a dedicated router for my printer room, only 3 printers connected to it and its 12 inches from this machine. I changed the router to 802.11G from B,G,N mode, but no real improvement.

Then I downgraded wifiserver to beta 8 and its a bit better but still not quite right.

Hopefully this report helps, if you want any more data from me let me know.

EDIT - so I just saw the post with Chrishamm's 1.17 rc6 and installed it, no real change in disconnects, so I went back to wifiserver beta9 and its fine as long as I am not on the g-code files page, then it disconnects almost immediately.

EDIT 2 - so been using beta9 and dwc 1.17rc6 for a while now and it totally stable as long as I stay away from the g-code file tab. Which I generally do anyway, but odd that it falls over here and not anywhere else.

lars

@dc42:

If you run M671 with no parameters, does it report the leadscrew positions that you configured?

I'm sorry you still have the tool change problem, I thought I had fixed that.

M671
Error: M671 parameters do not apply to CoreXYU kinematics

```Ahh…

adri84dj

Hello david,

I come from version 1.19beta8 and when I try to update to this new beta I always receive the error "Could not establish a connection to the Duet firmware! Please check your settings and try again." And I have to remove the power to be able to connect with the Duet Ethernet. When checking the firmware version I still have 1.19beta8

I have a Duet Ethernet.

I have tried it from Proterface but it remains indicating "firmware update" and never ends, until I remove the power.

What am I doing wrong?

a greeting

deckingman

@adri84dj:

Hello david,

I come from version 1.19beta8 and when I try to update to this new beta I always receive the error "Could not establish a connection to the Duet firmware! Please check your settings and try again." And I have to remove the power to be able to connect with the Duet Ethernet. When checking the firmware version I still have 1.19beta8

I have a Duet Ethernet.

I have tried it from Proterface but it remains indicating "firmware update" and never ends, until I remove the power.

What am I doing wrong?

a greeting

Have exactly the same problem trying to revert to 1.18.1

Eddiie

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.

M552 S1,

Error on Paneldue console says:
0m30 Wifi reported error: failed to connect to access point Wifi module is idle

According to release notes, the ESP should go to AP mode. I don't see it.

M552 S0, M552 S1 over and over, eventually is connects.

lars

@Eddiie:

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