Posts made by sko

@jens55 said in Bl-touch and distance printing nozzle:

I am now officially lost ....
In your homez.g macro you are adjusting bed tilt but you only run the tilt routine once. Normally this is a successive approximation so it would make more sense to run this several times (the tilt compensation)

I wasn't aware of that. The reported adjustment is usually <0.2mm, but I will try to rewrite it to repeat until the deviation is even lower.

Then you run close to where the limit switch is located and set z=0. Never mind the fact that ideally z should be set to zero when it is in the middle of the bed .... you are now using the z limit switch and not the probe.

Z=0 is set at the position where the limit switch is triggered. I confirmed this several times by checking the nozzle height after this step.

You then run the probe and over-ride the previous z=0 setting which was set with the end limit switch rather than the probe.

G30 S-3 doesn't set the Z=0 value but only the trigger height:
G30 S-3 ; Probe the bed and set the Z probe trigger height to the height it stopped at

There is a good possibility that I do not completely understand what is happening here but it looks to me like the probe triggering point is different from the endstop trigger point and you are seeing weirdness because of that.

I am aware that the endstop trigger is different from the probe trigger height.
My problem was, that when using G30 to home Z using the probe, there was an offset of ~0.4mm added somewhere. This led to Z=0 being off by the same value when I tried to home Z by only using the probe and the trigger distance defined via G31 in config.g

While troubleshooting a weird glitch where I always got an height error of ~0.4mm when using the inductive sensor to set Z=0 with G30 and a fixed trigger offset (can be read here: https://forum.duet3d.com/topic/18239/bl-touch-and-distance-printing-nozzle ), I "accidentaly" found a way to completely automate Z-homing with Z-probe offset adjustment.

It basically boils down to only 2 simple steps:

• set Z=0 via the endswitch (G1 H1 + G92 Z0)
• calibrate the probe trigger distance with G30 S-3 at Z=0

I've mounted the Z-endswitch directly next to the printbed at the far right corner. The Z-probe is still above the bed, so i only have to move a few mm to clear the endswitch and calibrate the trigger distance.
The only caveat of this method: The bed height has to correspond exactly to the trigger height of the endswitch. This can be easily adjusted by setting Z=0 on the endswitch, then moving over the bed and manually move to Z=0 and adjusting the bed so the nozzle touches the surface at Z=0 height.

To use the Z-endstop the axis has to be configured to use a switch, not the probe, but the probe is still defined via M558 and a trigger value but no offset is set:

config.g
[...]
M574 Z1 S1 P"!zstop"
M558 P1 C"!zprobe.in" H20 A5 F600 T18000           ; set Z probe type to unmodulated and the dive height + speeds
G31 P500                        ; set Z probe trigger value. trigger distance is set during Z homing

The complete Z-homing procedure looks like follows:

; homez.g
M561					; cancel all bed mesh compensations
M558 P1 C"!zprobe.in" H15 F300		; increase dive height to prevent crashing into a tilted bed

; probe and adjust the bed tilt
G90	
G30 P0 X50 Y165 Z-99999 ; probe near a leadscrew
G30 P1 X350 Y165 Z-99999 S2 ; probe near a leadscrew

M558 P1 C"!zprobe.in" H5		; reduce dive height after adjusting the bed

; move over endswitch to set Z=0
G1 X341 Y310 F18000
G1 H1 Z-350 F600 ; move quickly to Z axis endstop and stop there (first pass)
G1 Z5 F1200       ; move up a few mm
G1 H1 Z-6 F300   ; move slowly to Z axis endstop once more (second pass)
G92 Z0 			; set Z=0

G1 Z15 F1200   ; lift printhead

; calibrate probe trigger distance
G1 X341 Y313 F18000	; move directly next to the switch to calibrate the probe
G30 S-3				; set probe trigger height

G1 Z15 F1200		; lift printhead
G1 X0 Y330 Z20 F18000				; move printhead to the back

For now this gives pretty consistent results and mesh compensation is working reliably. Even with deliberately introduced errors, the nozzle is just touching the bed when moving to Z=0 at any position.

As soon as I ran a bed mesh compensation, the error was introduced into the height map and the nozzle was ~0.4mm above the bed when moving to "Z=0"

I now reverted to using G30 S-3 directly next to the Z-endstop. This fixes the mysterious ~.4mm error that was consistently introduced when using G30 and a fixed offset in the config.g. So I removed all probe offsets from the config.g and now set the offset during Z-homing:

; homez.g
; called to home the Z axis
M561					; cancel all bed mesh compensations
M558 P1 C"!zprobe.in" H15 F300		; increase dive height to prevent crashing into a tilted bed

; probe and adjust the bed tilt
G90	
G30 P0 X50 Y165 Z-99999 ; probe near a leadscrew
G30 P1 X350 Y165 Z-99999 S2 ; probe near a leadscrew

M558 P1 C"!zprobe.in" H5		; reduce dive height after adjusting the bed

; move over endswitch to set Z=0
G1 X341 Y310 F18000
G1 H1 Z-350 F600 ; move quickly to Z axis endstop and stop there (first pass)
G1 Z5 F1200       ; move up a few mm
G1 H1 Z-6 F300   ; move slowly to Z axis endstop once more (second pass)
G92 Z0 			; set Z=0
G1 Z15 F1200   ; lift printhead

; calibrate probe trigger distance
G1 X341 Y313 F18000	; move directly next to the switch to calibrate the probe
G30 S-3				; set probe trigger height
G1 Z15 F1200		; lift printhead

G1 X0 Y330 Z20 F18000				; move printhead to the back

afterwards I can run bed mesh compensation and am getting plausible results (with an error of ~0.015-0.02mm over multiple mesh compensation runs) and the compensation is properly working. I.e. I can move to any point on the bed and when moving the Z-axis to 0 the nozzle actually touches the bed, even if I deliberately introduce an error somewhere.

(I couldn't edit my previous post b/c it was tagged as spam!?)

I compared the manually determined trigger height to the one reported by G30 S-1 and it is always off by ~.45
Actual trigger height at the point where Z is homed (and the probe is above the bed) as said is ~1.4mm If I run a G30 S-1 at the same position it reports ~1.8-1.9mm trigger height...

I just wired the Z-endstop switch and did some testing...

The Z-switch is mounted 10mm next to the bed (bedsize 330x330, probing position 341,310) and is adjusted to exactly match the bed height in that corner. Homing Z is 100% accurate now and after probing I can reliably lower the nozzle to 0 and it is exactly just touching the bed surface in that corner.

BUT: as soon as I run mesh compensation (G29) I get an error of ~0.5mm (higher) for that corner. I've checked the trigger height manually and it is at 1.44-1.46mm height, but no matter what I set in the config.g via G31, e.g. G31 P500 X0 Y0 Z1.45; the .5mm error is always present after running G29. I also tried absurd values like 5 or 10mm and even negative ones, the nozzle is now always ~.45-.5 over the bed after running G29.

The Tool doesn't have any offsets set (G10 P0 X0 Y0 Z0) and in config-override.g only the heater parameters are present (M307)

Here's my 'homez.g':

M558 P1 C"!zprobe.in" H15 A5 F600 T25000		; increase dive height

G90	
G30 P0 X50 Y165 Z-99999 ; probe near a leadscrew
G30 P1 X350 Y165 Z-99999 S2 ; probe near a leadscrew
M558 P1 C"!zprobe.in" H5 A5 F600 T25000			; reduce dive height after adjusting the bed
G90						; absolute positioning

G1 X340.8 Y310 F18000
G1 H1 Z-350 F600 ; move quickly to X axis endstop and stop there (first pass)
G1 Z5 F1200       ; go back a few mm
G1 H1 Z-6 F300   ; move slowly to X axis endstop once more (second pass)
G92 Z0 			; G1 H1 sometimes doesn't set Z=0???
G1 H2 Z15 F1200   ; lower Z again
G90                ; absolute positioning

G1 X0 Y330 F18000				; move printhead to the back

and config.g:

; General preferences
G90                                           ; send absolute coordinates...
M83                                           ; ...but relative extruder moves
M550 P"x5sapro"                               ; set printer name
M669 K1                                       ; select CoreXY mode

; PanelDue
M575 P1 S1 B57600 

; Network
M552 S1                                       ; enable network
M586 P0 S1                                    ; enable HTTP
M586 P1 S0                                    ; disable FTP
M586 P2 S0                                    ; disable Telnet

; Drives
M569 P0 S1 F12                                   ; XY 1 physical drive 0 goes forwards
M569 P1 S1 F12                                   ; XY 2 physical drive 1 goes forwards
M569 P2 S0 F12                                   ; invert Z1
M569 P3 S0 F12                                   ; invert E0
M569 P4 S0 F12					; invert Z2
M584 X0 Y1 Z4:2 E3                              ; set drive mapping
M671 X-90:410 Y165:165 S50							; set X and Y offsets of lead screws
M350 X16 Y16 Z16 E16 I1                       ; configure microstepping with interpolation
M92 X80.00 Y80.00 Z400.00 E393.88             ; set steps per mm
M566 X300.00 Y300.00 Z300.00 E600.00
M203 X48000.00 Y48000.00 Z3000.00 E3000.00    ; set maximum speeds (mm/min)
M201 X8000.00 Y8000.00 Z250.00 E1000.00       ; set accelerations (mm/s^2)
M906 X1050 Y1050 Z950 E650 I30                  ; set motor currents (mA) and motor idle factor in per cent
M84 S30                                       ; Set idle timeout

; Axis Limits
M208 X0 Y-8 Z0 S1                              ; set axis minima
M208 X350 Y329 Z400 S0                        ; set axis maxima

; Endstops
M574 X1 S1 P"!xstop"                           ; configure active-high endstop for low end on X via pin xstop
M574 Y1 S1 P"!ystop"                           ; configure active-high endstop for low end on Y via pin ystop
M574 Z1 S1 P"!zstop"

; Z-Probe
M558 P1 C"!zprobe.in" H20 A5 F600 T18000           ; set Z probe type to unmodulated and the dive height + speeds
G31 P500 X0 Y0 Z1.85
M557 X50:350 Y15:315 S75                      ; define mesh grid

; Heaters
M308 S0 P"bedtemp" Y"thermistor" T100000 B3950 ; configure sensor 0 as thermistor on pin bedtemp
M950 H0 C"bedheat" T0                         ; create bed heater output on bedheat and map it to sensor 0
M307 H0 B1 S1.00                              ; enable bang-bang mode for the bed heater and set PWM limit
M140 H0                                       ; map heated bed to heater 0
M143 H0 S120                                  ; set temperature limit for heater 0 to 120C
M308 S1 P"e0temp" Y"thermistor" T100000 B4100  ; configure sensor 1 as thermistor on pin e0temp
M950 H1 C"e0heat" T1                          ; create nozzle heater output on e0heat and map it to sensor 1
M307 H1 B0 S1.00                              ; disable bang-bang mode for heater  and set PWM limit

; Fans
M950 F0 C"fan0" Q500                          ; create fan 0 on pin fan0 and set its frequency
M106 P0 C"Part Cooling" S0 H-1                ; set fan 0 name and value. Thermostatic control is turned off
M950 F1 C"fan1" Q500                          ; create fan 1 on pin fan1 and set its frequency
M106 P1 C"Hotend" S0.5 H1 T45                 ; set fan 1 name and value. Thermostatic control is turned on
M950 F2 C"fan2" Q500                          ; create fan 2 on pin fan2 and set its frequency
M106 P2 C"Board" S0 H-1                       ; set fan 2 name and value. Thermostatic control is turned off

; Tools
M563 P0 S"CR-10 Hotend" D0 H1 F0              ; define tool 0
                              ; set tool 0 axis offsets
G10 P0 R0 S0                                  ; set initial tool 0 active and standby temperatures to 0C

; Miscellaneous
M575 P1 S1 B57600                             ; enable support for PanelDue

M501

I have the exact same problem with an inductive probe and wasted the better part of last evening with it (instead of trying this: https://forum.duet3d.com/topic/18223/auto-adjust-z-offset).
To successfully get a print going, I always had to re-adjust Z=0 after the homing and bed probing, or the nozzle will be .35mm too high. This value is pretty much consistent 90% of the time, so I didn't check the height after a while and just added

M564 S0
G1 Y-0.35
G92 Z0

To the homez.g file...

Varying the Z-offset (set with G31 in config.g) doesn't affect the outcome and the Z=0 error is always consistent. The offset only affects values in the bed compensation map and seems to be subtracted from those values for Z=0, so no matter what Z-offset I use (positive or negative and even absurd values like 10mm); the nozzle always is .35mm too high at Z=0.

Even when disabling bed compensation the Z-error is persistent and always is present immediately after homing Z with G30, so I suspect there's a bug with calculating/setting Z=0 via that command.
I've printed a bracket for a Z-endstop switch to set Z=0 by triggering that switch with the nozzle (as I was already planning to do), so I can completely avoid depending on some calculation for Z=0 and use the Z-probe only for bed leveling and compensation.

I have some spare microswitches lying around and thought about using them for adjusting the Z-Offset automagically using the switch and the inductive sensor in combination:

• install the microswitch right next to the printbed and make it adjustable so it can be dialed in to be triggered by the nozzle exactly at the actual height of the printbed (which will be Z=0). This would have to be re-adjusted for different printbeds, but maybe multiple switches can be used for different print surfaces and linked to different toolsets?

• mount the inductive sensor on each printhead in such a position, that it is above the printbed when the microswitch is probed, so the sensor also gets triggered by the bed when the nozzle triggers the microswitch.

The probing process could look like this:
after homing x+y, (and maybe after adjusting the bed level using multiple stepper motors), move the nozzle over the microswitch corresponding to the current build surface height and move the nozzle downwards/the bed upwards until the microswitch is triggered, then store the trigger height of the probe and continue with mesh compensation (using the probe).

This procedure would automagically compensate for different printheads/tools as well as different nozzle lengths or variations when the printhead has been taken apart (relative height difference of sensor and nozzle changed).

But can both, a probe and an endswitch be defined for Z-axis? E.g. would M574 Z1 S1 P"io2.in+zprobe.in" work?
Or should M574 be called from the script to re-define the endstop type after the microswitch has been triggered and Z=0 has been set?

My crude first approach would be:

• set endstop for Z-axis to microswitch (M574 Z1 S1 P"zstop")
• home Z-axis via microswitch (G1 H1 Z-500)
• set endstop for Z-axis to Z-probe (M574 + M558)
• set Z-probe trigger value (G30 S-3)

I've read about variables somewhere, those would be very handy to e.g. store
the trigger height and inserting into a 'G31' command to set the Z trigger height...
I also haven't checked/tried if the firmware loses home position for an axis if its endstop is re-defined.

I'm sure this idea isn't new, so I'd really like to hear about other approaches or if I was just too blind to find this in the documentation or the proper (simpler) gcode for doing this...

OK, so if this is an already known bug that is being worked on (soon-ish...) I'll cease further investigation and troubleshooting for now until there's a newer version...

Is there an open discussion about this issue I can follow or chime in to help if required? There's no related open issue at the DuetWiFiServer repo on github...

I've now tried Wifi firmware versions 1.21 and 1.22 with similar results on the cisco APs.

Using another AP (FS AP1167C) however solves the problem (or at least hides it). From the various discussions I found in cisco support forums, the error message (CCMP TSC replays) is usually triggered by malformed packages, caused by some broken WiFi Drivers (notably some Intel Windows drivers, e.g. older Centrinos). For most users this got fixed by updating the drivers.
So it seems the duet is sometimes sending malformed frames that are being dropped by some APs (like cisco, causing above mentioned error message) but accepted by others...

If true, this might also explain issues with disconnections or not being able to connect, especially for APs that have "crude" mitigations for deauth-attacks implemented (-> they just kick out the client...)

I totally forgot yesterday to mention that the AP logs the following errors from time to time:

[...]
Aug 11 17:19:53.181: %DOT11-4-CCMP_REPLAY: Client d8bf.c0fe.92c1 had 1 AES-CCMP TSC replays
Aug 11 17:50:23.178: %DOT11-4-CCMP_REPLAY: Client d8bf.c0fe.92c1 had 1 AES-CCMP TSC replays
Aug 11 18:18:23.199: %DOT11-4-CCMP_REPLAY: Client d8bf.c0fe.92c1 had 1 AES-CCMP TSC replays
Aug 11 18:35:23.242: %DOT11-4-CCMP_REPLAY: Client d8bf.c0fe.92c1 had 1 AES-CCMP TSC replays
[...]

An actual replay attack can be dismissed - I live on the countryside and there's nobody in range to reach my networks and I highly doubt someone is hiding outside for >12 hours and counting...
There's a known bug with several Cisco APs and Intel WiFi Chipsets:
https://quickview.cloudapps.cisco.com/quickview/bug/CSCsx50775
https://quickview.cloudapps.cisco.com/quickview/bug/CSCur62548

I'll try another AP at home just to verify if the problem lies within the wireless connection.

@Jenco what type/brand of AP are you using? Are you getting the same errors (given it is capable of logging/showing such errors...)?

@Phaedrux said in Cannot upload files. (Duet 2 Wifi):

@sko said in Cannot upload files. (Duet 2 Wifi):

Although upload speeds are a bit disappointing at ~500k max.

That would be normal speed. There isn't a lot of ram available to buffer the transfer.

Totally fine for this use case. It's not that you have to push multiple GB per day through that connection...
One can also put the duet behind a nginx proxy that buffers the connection (and could deal with SSL/TLS and authentication) to increase speeds, although it would of course take the same time until the files are actually available for printing.
In fact I already did that to reach the duet from outside of my network - it doesn't solve the upload issue though...

I haven't had much time this evening to do anything meaningful. I hope to find some time tomorrow. I checked the connection and interface stats on the AP and everything seems fine, although dropped frames are a tad high considering the duet is lying ~1m from the AP. OTOH the Amazon Fire TV stick has a much higher rate of dropped frames (b/c its wifi is total crap... ) and still works just fine...

Heres some debug output from the Webserver:

HTTP req, command words { POST /rr_upload HTTP/1.1 }, parameters { name=0:/gcodes/3D4U_Coffee_Clip.gcode time=2020-7-13T20:34:25 crc32=ba283f22 }
Start uploading file 0:/gcodes/3D4U_Coffee_Clip.gcode length 42855016
HTTP req, command words { GET /rr_reply HTTP/1.1 }, parameters { }
Sending reply, file = no
Sending G-Code reply to HTTP client 1 of 1 (length 2)
HTTP connection accepted
HTTP req, command words { GET /rr_model HTTP/1.1 }, parameters { flags=d99fn }
Sending JSON reply, length 1950
HTTP connection accepted
HTTP req, command words { GET /rr_model HTTP/1.1 }, parameters { key=volumes flags=d99vn }
Sending JSON reply, length 249
HTTP connection accepted
HTTP req, command words { GET /rr_reply HTTP/1.1 }, parameters { }
Sending reply, file = no
Sending G-Code reply to HTTP client 1 of 1 (length 1)
HTTP connection accepted
HTTP req, command words { GET /rr_model HTTP/1.1 }, parameters { flags=d99fn }
Sending JSON reply, length 1950
HTTP connection accepted
HTTP req, command words { GET /rr_model HTTP/1.1 }, parameters { key=volumes flags=d99vn }
Sending JSON reply, length 249
HTTP connection accepted
HTTP req, command words { GET /rr_reply HTTP/1.1 }, parameters { }
Sending reply, file = no
Sending G-Code reply to HTTP client 1 of 1 (length 1)
HTTP connection accepted
HTTP req, command words { GET /rr_model HTTP/1.1 }, parameters { flags=d99fn }
[...]

Right after the initial HTTP POST there's only the page refresh data. Nothing else about the file transfer.

Debug output from storage (P10) shows some writes right after the HTTP POST, but they disappear after a few seconds.

Network (P1) and WiFi (P14) don't show anything else but status/keepalive data. No errors or such (I can also post the whole, crowded output when logging everything together if requested...)

I also did a tcpdump while starting a transfer:

00:00:00.170736 IP (tos 0x0, ttl 64, id 0, offset 0, flags [DF], proto TCP (6), length 1500)
    172.25.52.99.53451 > 172.25.52.135.80: Flags [.], cksum 0xc6eb (incorrect -> 0x05c8), seq 1:1461, ack 1, win 65535, length 1460: HTTP, length: 1460
        POST /rr_upload?name=0%3A%2Fgcodes%2F3D4U_Coffee_Clip.gcode&time=2020-7-13T20%3A34%3A25&crc32=ba283f22 HTTP/1.1
        Host: 172.25.52.135
        User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:68.0) Gecko/20100101 Firefox/68.0
        Accept: */*
        Accept-Language: en-US,en;q=0.5
        Accept-Encoding: gzip, deflate
        Referer: http://172.25.52.135/Files/Jobs
        Content-Type: application/json
        Content-Length: 42855016
        DNT: 1
        Connection: keep-alive

        M4010 X300 Y300
        M4010 I0 T25960 'ffff3fffffff3fffffff3fffffff3fffffff3fffffff3fffffff33190000290141c2628373048364300562834a0231410840ffff311c08004a0283448ba5300c83445a43398218c118a030030000ffff31100800314149c35203'
        M4010 I25960 T623 '18816ac48ba5301193c5ac459c058b857b044a021880ffff310c000039427b448b857b0473046ac48ba5301283447b048b8583448ba530035a431080ffff3109000052038ba5300372c45244834593858ba530127b0472c47b44'
        M4010 I26583 T582 '8ba5300483443141ffff310839828ba530056ac49bc5b485ac458ba5300e93c5ac45a4458b857b448ba530075a430840ffff309700000860300518c129213004086030050000ffff305d18817b458ba53007ac45cd06dd86cd06'
        M4010 I27165 T287 'b486a40593e530028ba5300393e53002ac45bcc6cd06d546c506a4058ba5300a83442101ffff308d000008002101290149c24a02628372e430027b048ba5300f834472e4300262834a0249c22921300208000000ffff30530000'
        M4010 I27452 T315 '62848ba5300aa445bcc6d546ee06fe47fe87ee47ee07ee47fea73002fe47f606c4c6a4058ba5300e52030000ffff308500000840290141825a436ac483448ba530217b0472c44a02314118800000ffff304e31428ba5300993a53006'
        M4010 I2[!http]
 00:00:00.003299 IP (tos 0x0, ttl 255, id 29367, offset 0, flags [none], proto TCP (6), length 40)
    172.25.52.135.80 > 172.25.52.99.53451: Flags [.], cksum 0xbfb1 (correct), ack 1461, win 5840, length 0
 00:00:00.000007 IP (tos 0x0, ttl 64, id 0, offset 0, flags [DF], proto TCP (6), length 1500)
    172.25.52.99.53451 > 172.25.52.135.80: Flags [.], cksum 0xc6eb (incorrect -> 0xd43a), seq 1461:2921, ack 1, win 65535, length 1460: HTTP
 00:00:00.000004 IP (tos 0x0, ttl 64, id 0, offset 0, flags [DF], proto TCP (6), length 1500)
    172.25.52.99.53451 > 172.25.52.135.80: Flags [.], cksum 0xc6eb (incorrect -> 0xafd8), seq 2921:4381, ack 1, win 65535, length 1460: HTTP
 00:00:00.017993 IP (tos 0x0, ttl 255, id 29368, offset 0, flags [none], proto TCP (6), length 40)
    172.25.52.135.80 > 172.25.52.99.53451: Flags [.], cksum 0xbfb1 (correct), ack 2921, win 4380, length 0
 00:00:00.000017 IP (tos 0x0, ttl 64, id 0, offset 0, flags [DF], proto TCP (6), length 1500)
    172.25.52.99.53451 > 172.25.52.135.80: Flags [.], cksum 0xc6eb (incorrect -> 0x6e08), seq 4381:5841, ack 1, win 65535, length 1460: HTTP
 00:00:00.000005 IP (tos 0x0, ttl 64, id 0, offset 0, flags [DF], proto TCP (6), length 1500)
    172.25.52.99.53451 > 172.25.52.135.80: Flags [.], cksum 0xc6eb (incorrect -> 0x3e4c), seq 5841:7301, ack 1, win 65535, length 1460: HTTP
 00:00:00.001360 IP (tos 0x0, ttl 255, id 29369, offset 0, flags [none], proto TCP (6), length 40)
    172.25.52.135.80 > 172.25.52.99.53451: Flags [.], cksum 0xbfb1 (correct), ack 2921, win 4380, length 0
 00:00:00.009468 IP (tos 0x0, ttl 255, id 29370, offset 0, flags [none], proto TCP (6), length 40)
    172.25.52.135.80 > 172.25.52.99.53451: Flags [.], cksum 0xb9fd (correct), ack 2921, win 5840, length 0
 00:00:00.026213 IP (tos 0x0, ttl 64, id 0, offset 0, flags [DF], proto TCP (6), length 322)
    172.25.52.99.28373 > 172.25.52.135.80: Flags [P.], cksum 0xc251 (incorrect -> 0x4753), seq 1:283, ack 1, win 65535, length 282: HTTP, length: 282
        GET /rr_reply HTTP/1.1
        Host: 172.25.52.135
        User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:68.0) Gecko/20100101 Firefox/68.0
        Accept: */*
        Accept-Language: en-US,en;q=0.5
        Accept-Encoding: gzip, deflate
        Referer: http://172.25.52.135/Files/Jobs
        DNT: 1
        Connection: keep-alive

 00:00:00.003966 IP (tos 0x0, ttl 255, id 29371, offset 0, flags [none], proto TCP (6), length 239)
    172.25.52.135.80 > 172.25.52.99.28373: Flags [P.], cksum 0x3266 (correct), seq 1:200, ack 283, win 5558, length 199: HTTP, length: 199
        HTTP/1.1 200 OK
        Cache-Control: no-cache, no-store, must-revalidate
        Pragma: no-cache
        Expires: 0
        Access-Control-Allow-Origin: *
        Content-Type: text/plain
        Content-Length: 2
        Connection: close

So it starts to transmit the file (as plaintext) but the connection is dropped after a few lines and then only the keepalives are left...

I don't have more time right now (lunch break...) but I'll try to fire up another AP tonight to verify if it's a problem with how the wireless network is handled (by the duet?) or if there's another problem (e.g. MTU related...)

I took the board with me to work today to flash the 2.05.1 firmware and here uploads are working (with DWC 3.1.1 !).
Just to verify I re-flashed with firmware 3.1.1 and uploads are still working!
Although upload speeds are a bit disappointing at ~500k max.

So it seems the duet wifi has problems with some wifi setups. I'll investigate this when I get home from work this evening, but right now I have no clue where I should start...
At work we have aruba APs and at home I'm running 2 cisco APs and never had any issues, especially not such specific ones like transfers only in one direction (downloading from the duet works just fine!) and only above a certain filesize...

I'll try to gather some useful information from the debug output later. Here on the network at work all seems fine (=no errors/warnings) when I enable debug for network and wifi (M111 P1 S1 && M111 P1 S14)

Having the same problem here. After ~40kB any upload stalls. Smaller files transfer just fine...

M122
=== Diagnostics ===
RepRapFirmware for Duet 2 WiFi/Ethernet version 3.1.1 running on Duet WiFi 1.02 or later
Board ID: 08DLM-996AL-K6PSD-6J1DJ-3SD6L-99GGY
Used output buffers: 3 of 24 (10 max)
=== RTOS ===
Static ram: 27980
Dynamic ram: 93760 of which 56 recycled
Exception stack ram used: 240
Never used ram: 9036
Tasks: NETWORK(ready,384) HEAT(blocked,1320) MAIN(running,1912) IDLE(ready,80)
Owned mutexes: WiFi(NETWORK)
=== Platform ===
Last reset 00:00:40 ago, cause: software
Last software reset at 2020-08-10 18:21, reason: User, spinning module GCodes, available RAM 8992 bytes (slot 1)
Software reset code 0x0003 HFSR 0x00000000 CFSR 0x00000000 ICSR 0x04433000 BFAR 0xe000ed38 SP 0xffffffff Task MAIN
Error status: 0
MCU temperature: min 37.0, current 37.7, max 37.8
Supply voltage: min 1.7, current 1.7, max 1.8, under voltage events: 0, over voltage events: 0, power good: no
Driver 0: ok, SG min/max not available
Driver 1: ok, SG min/max not available
Driver 2: ok, SG min/max not available
Driver 3: ok, SG min/max not available
Driver 4: ok, SG min/max not available
Date/time: 2020-08-10 18:22:06
Cache data hit count 65784672
Slowest loop: 5.57ms; fastest: 0.10ms
I2C nak errors 0, send timeouts 0, receive timeouts 0, finishTimeouts 0, resets 0
=== Storage ===
Free file entries: 10
SD card 0 detected, interface speed: 20.0MBytes/sec
SD card longest read time 3.4ms, write time 0.0ms, max retries 0
=== Move ===
Hiccups: 0(0), FreeDm: 169, MinFreeDm: 169, MaxWait: 0ms
Bed compensation in use: none, comp offset 0.000
=== MainDDARing ===
Scheduled moves: 0, completed moves: 0, StepErrors: 0, LaErrors: 0, Underruns: 0, 0  CDDA state: -1
=== AuxDDARing ===
Scheduled moves: 0, completed moves: 0, StepErrors: 0, LaErrors: 0, Underruns: 0, 0  CDDA state: -1
=== Heat ===
Bed heaters = 0 -1 -1 -1, chamberHeaters = -1 -1 -1 -1
=== GCodes ===
Segments left: 0
Movement lock held by null
HTTP is idle in state(s) 0
Telnet is idle in state(s) 0
File is idle in state(s) 0
USB is idle in state(s) 0
Aux is idle in state(s) 0
Trigger is idle in state(s) 0
Queue is idle in state(s) 0
Daemon is idle in state(s) 0
Autopause is idle in state(s) 0
Code queue is empty.
=== Network ===
Slowest loop: 15.93ms; fastest: 0.00ms
Responder states: HTTP(1) HTTP(2) HTTP(0) HTTP(0) FTP(0) Telnet(0), 0 sessions
HTTP sessions: 1 of 8
- WiFi -
Network state is active
WiFi module is connected to access point 
Failed messages: pending 0, notready 0, noresp 0
WiFi firmware version 1.23
WiFi MAC address d8:bf:c0:fe:92:c1
WiFi Vcc 3.38, reset reason Unknown
WiFi flash size 4194304, free heap 24280
WiFi IP address 172.25.52.135
WiFi signal strength -43dBm, reconnections 0, sleep mode modem
Socket states: 2 4 0 0 0 0 0 0

Tried 2 brand new SD-cards with the same result, and as I can upload smaller files and edit the config through DWC I don't think its the SD card. Is there any max filesize or buffer defined in the Webserver that might interfere with uploads?

The chip seems to be genuine (Atmel ATSAM4E8E) and the board comes from one of the 'bigger' manufacturers in the MAKER community... (The PCB is black BTW...).

Success!

I tried another Win7 PC at work today.
Bossa still wouldn't connect in any version (1.7, 1.8, 1.9.1), so I installed Atmel Studio and finally was able to connect to the board and flash the current Firmware!

Being curious I erased the flash again, bossa again wasn't able to connect, but SAM-BA can now connect and flash the firmware.

Don't know why the board was locked up, but it seems Atmel Studio (which should use plain SAM-BA in the background as far as I understand!?) fixed it and now its working again.

Thanks for the help @bearer , I'll keep the link about JTAG programming in my bookmarks in case I should need it in the future...

Should the Diag-LED turn off at any point when the erase-Jumper is set? The Diag-LED on this board has been always constantly lit, no matter what I did (erase/reset).

I managed to borrow a Laptop with Windows 7, but I'm getting the typical Windows-experience:

bossa 1.9.1 can't connect
bossa 1.8 segfaults when connecting
sam-ba 3.3.1 won't even start
sam-ba 2.18 dies when connecting with an error in TCL_Open

It's a Version 1.04 board and the header isn't populated and 3 resistors next to it are missing, but the vias are there, so I could still use some e-z probes / SMD grabbers to connect or solder in the header...
As a last resort or to circumvent having to use the unreliable bossa-path I still wouldn't dismiss the JTAG variant IF it allows firmware flashing.

With virtualization there's the problem that USB-passthrough especially for low-level stuff is rather unreliable. So on top of a buggy software (bossa) I also add several layers of possible breakage.

If I can't find another solution, I might try to find a windows pc at work next week to try if it works there. But from what I saw here in the forums and elsewhere, with windows it's already uncertain if the serial connection will work...

EDIT:
I finally managed to also build bossac 1.8 . It seems to properly connect, but it fails with "SAM-BA operation failed"...

I don't use a mac, I've tried it on FreeBSD 12.1 and 11.3 with bossa 1.7 and 1.9.1 (current version from github) with identical results...

% bossac -d -i -pcuaU0
Set binary mode
Send auto-baud
Set binary mode
No device found on cuaU0
% bossac -d -i -p/dev/cuaU0
Set binary mode
Send auto-baud
Set binary mode
No device found on /dev/cuaU0
% bossac -d -i -pttyU0
Set binary mode
Send auto-baud
Set binary mode
No device found on ttyU0
% bossac -d -i -p/dev/ttyU0
Set binary mode
Send auto-baud
Set binary mode
No device found on /dev/ttyU0

cuaU0 is the correct device (and ttyU0 the matching terminal) and I can open connections to both without any error. It seems bossa is doing some "intelligent" probing, which fails and prevents any further operations...