New experimental firmware 1.19beta9
-
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… -
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
-
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
-
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 idleAccording 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.
-
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.
-
I went to beta9, Wifi works better but now bedleveling causes AJAX error at the end.
Going to try beta8 -
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
-
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..
-
Beta7 was bad for wiifi..
going back to beta9, hoping something in bed.g is incorrect or new version.
? -
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.
-
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
-
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.
-
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
-
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..
-
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?
-
same as cubexupgrade cant get the X and Y working
on a corexy
they are swaped -
Yeah I just noticed this on my corexy, had to swap the y motor direction in the end. Working now.
-
same as cubexupgrade cant get the X and Y working
on a corexy
they are swapedSee the Big Bold letters in DC's original post
-
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.118Found 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…
-
same as cubexupgrade cant get the X and Y working
on a corexy
they are swapedSee 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.
