New beta firmware release 1.20beta10

whosrdaddy

WiFi stopped working for me with DuetWiFiServer-1.20beta10
M552 S1 says:
Failed to initialise WiFi module, code -10

Reverting to DuetWiFiServer-1.20beta9 fixes the problem

I did the M997 S1 twice, and I tried installing Beta10 again after reverting to Beta9 with the same result.
Debug mode says:
Debugging enabled for modules: WiFi(14)
Debugging disabled for modules: Platform(0) Network(1) Webserver(2) GCodes(3) Move(4) Heat(5) DDA(6) Roland(7) Scanner(8) PrintMonitor(9) Storage(10) PortControl(11) DuetExpansion(12) FilamentSensors(13)
WiFi: 
WiFi:  ets Jan  8 2013,rst cause:2, boot mode:(3,6)
WiFi: 
WiFi: load 0x4010f000, len 1384, room 16 
WiFi: tail 8
WiFi: chksum 0x2d
WiFi: csum 0x2d
WiFi: v60000100
WiFi: ~ld
WiFi module started
Error: Failed to initialise WiFi module, code -10
The last line appears after ~30 seconds delay

Same problem here!

DjDemonD

Same for me as zlowered failed to intialise wifi module -code 10 did it via the sd card m997 method. twice.

Restored to wifiserver 1.20beta9 but it had to do so at 230xxx baud rate after failing at 4xxxxx baud rate.

str8up

Same here as well. Back to wifiserver 1.20beta9.

DjDemonD

On the upside, FW 1.20beta10 is working, printing stuff right now.

dc42

I'm sorry, somehow the wrong file got copied to DuetWiFiServer-1.20beta10.bin on github. I have corrected it now.

peirof

reflot

[[language]]
Hi,

Added Z probe types 7 (switch connected to Z endstop) and 8 (as type 5 without any filtering, for faster response)
Bltouch or Míni Differential Ir Sensor, are affected?

whosrdaddy

Wifi beta 10 is working now!

dc42

@peirof:

reflot

[[language]]
Hi,

Added Z probe types 7 (switch connected to Z endstop) and 8 (as type 5 without any filtering, for faster response)
Bltouch or Míni Differential Ir Sensor, are affected?

IR sensor: not affected if you use it in analogue mode as recommended for the Duet. But you could use it in digital mode with the probe type set to 8 if you wish.

BLTouch: if you currently have the probe type set to 5, you could try 8. It might give you slightly more reproducible results.

Here is what the new mode is about. The ADC on the Duets reads every enabled input channel once every millisecond and feeds the values into averaging filters. When you use a digital output Z probe, the ADC is not used but the Z probe is still sampled every millisecond and fed into an averaging filter. This can be useful for debouncing and rejecting glitches. However, it means that there is a variable delay of up to 1ms before the Z probe signal is recognised. If you are probing at 1000mm/minute (as we suggest with the Smart Effector), then the head will move 16.7um in 1ms. So the 1ms sampling introduces an uncertainty in the trigger point of +/- 8.3um. This uncertainty is avoided when you use mode 8. At lower probing speeds, the uncertainty is lower.

DjDemonD

What debounce value would you suggest in G31 for smart effector? Or does this not apply when using p8?

dc42

Debounce doesn't apply when using P8. Any value between 1 and 1000 should give the same result.

frafa

Hi David

On Scara I have a strange problem with
DuetWiFiFirmware-1.20beta10.bin
I have shifts of layers in x / y it does not get well
unusable ….downgrade
DuetWiFiFirmware-1.20beta8+1.bin
DuetWiFiServer-1.20b8.bin
result ok ...
sorry brooken English ...
photo before/after (same file)

Forgvn77

I also have experienced layer "skewing" with 1.20beta10. Printed a gear bearing from Thingiverse and it came out slanted, but more on one side. Strange effect.

frafa

yes it's strange about simple shapes square/circles it works
while on complex shapes it does not work anymore …

DjDemonD

Hmm it seems something odd is going on. Last night I set a tray of parts printing and this morning there was a completed tray but with a nasty layer shift (never seen this happen on this printer before). Assuming it was because I was messing about with probing and might have lowered my motor currents and did not put them back, I started the print again today, same issue despite running all motors at 1.2A/1.68A.

I will try again but on a different firmware version, I need to get these parts printed.
M122 if it helps: https://1drv.ms/t/s!Apv79JfGbPIwg4QskvIqENNjz_mSWA

Jason K

I had the same issue with the skew.

=== Move ===
MaxReps: 130, StepErrors: 123, FreeDm: 240, MinFreeDm 120, MaxWait: 2228747316ms, Underruns: 0, 0
Scheduled moves: 2721, completed moves: 2721
Bed compensation in use: mesh
Bed probe heights: 0.000 0.000 0.000 0.000 0.000

seems like there are a lot of step errors for 3 layers

franzelka

Something is definitely odd with this firmware release.
First image 1.20beta10, totally messed up. Second one 1.20beta8, all going well until now!

DjDemonD

Mine wasn't as dramatic just a nasty layer shift towards -y (on a delta)

But those were 2 of 16 parts on the build plate, and then I reproduced the same error on the next 16, but cancelled the print as soon as it happened.

Interestingly I'm running the same FW on my corexy no issues so far, is this a delta problem?

dc42

Please can those of you who have experienced a layer shift using the latest release do the following:

1. State what machine architecture you are using (Cartesian, Delta etc.)

2. If you have a model that reproduces the issue easily, post a link to it

3. If possible, with 1.20beta10 loaded, connect a PC via USB, and send M111 S1 P4. Then print the model. Each time a step error is recorded, debugging info will be reported via USB. Post 50 or so lines of that debug info in this thread.

franzelka

1. Delta (Kossel Mini T3DP3D)
2. https://www.thingiverse.com/thing:2323213/#files -> Apple-Watch-Phone-Stand_V7.0.stl
3. there are no lost steps. No debugging output from USB logging and M122 didn't show any problems

It seems that after finishing the two solid layers every new layer gets skewed. With 1.20beta8 I could finish the print without any problems.

dc42

Thanks, I'll try printing that on my delta. Please share your config.g file.