Can't upload "large" files

Exerqtor

They were good last time i checked them, but here we go :

M39
SD card in slot 0: capacity 8.05Gb, free space 8.04Gb, speed 20.00MBytes/sec, cluster size 32kb

M122
=== Diagnostics ===
RepRapFirmware for Duet 2 WiFi/Ethernet version 2.03RC3 running on Duet WiFi 1.02 or later
Board ID: 08DGM-9T6BU-FG3S4-6J9F8-3S46Q-1VQBD
Used output buffers: 3 of 24 (12 max)
=== RTOS ===
Static ram: 25680
Dynamic ram: 94392 of which 0 recycled
Exception stack ram used: 524
Never used ram: 10476
Tasks: NETWORK(ready,524) HEAT(blocked,1236) MAIN(running,3736) IDLE(ready,160)
Owned mutexes:
=== Platform ===
Last reset 01:06:00 ago, cause: power up
Last software reset at 2019-05-29 15:21, reason: User, spinning module GCodes, available RAM 10384 bytes (slot 1)
Software reset code 0x0003 HFSR 0x00000000 CFSR 0x00000000 ICSR 0x0041f000 BFAR 0xe000ed38 SP 0xffffffff Task 0x4e49414d
Error status: 0
Free file entries: 9
SD card 0 detected, interface speed: 20.0MBytes/sec
SD card longest block write time: 57.4ms, max retries 0
MCU temperature: min 18.9, current 47.3, max 47.3
Supply voltage: min 12.3, current 12.4, max 12.7, under voltage events: 0, over voltage events: 0, power good: yes
Driver 0: ok, SG min/max 0/1023
Driver 1: ok, SG min/max 0/1023
Driver 2: ok, SG min/max 0/274
Driver 3: ok, SG min/max 0/1023
Driver 4: standstill, SG min/max not available
Date/time: 2019-05-29 18:52:24
Cache data hit count 4294967295
Slowest loop: 56.28ms; fastest: 0.08ms
I2C nak errors 0, send timeouts 0, receive timeouts 0, finishTimeouts 0, resets 0
=== Move ===
Hiccups: 0, FreeDm: 154, MinFreeDm: 107, MaxWait: 651279ms
Bed compensation in use: mesh
Bed probe heights: 0.000 0.000 0.000 0.000 0.000
=== DDARing ===
Scheduled moves: 75218, completed moves: 75178, StepErrors: 0, LaErrors: 0, Underruns: 0, 0
=== Heat ===
Bed heaters = 0 -1 -1 -1, chamberHeaters = -1 -1
Heater 0 is on, I-accum = 0.3
Heater 1 is on, I-accum = 0.8
=== GCodes ===
Segments left: 1
Stack records: 3 allocated, 0 in use
Movement lock held by null
http is idle in state(s) 0
telnet is idle in state(s) 0
file is doing "G1 X144.146 Y153.534 F10800" in state(s) 0
serial is idle in state(s) 0
aux is idle in state(s) 0
daemon is idle in state(s) 0
queue is idle in state(s) 0
autopause is idle in state(s) 0
Code queue is empty.
=== Network ===
Slowest loop: 58.87ms; fastest: 0.00ms
Responder states: HTTP(0) HTTP(0) HTTP(0) HTTP(0) FTP(0) Telnet(0) Telnet(0)
HTTP sessions: 1 of 8
- WiFi -
Network state is running
WiFi module is connected to access point 
Failed messages: pending 0, notready 0, noresp 0
WiFi firmware version 1.23
WiFi MAC address 80:7d:3a:15:24:3c
WiFi Vcc 3.36, reset reason Turned on by main processor
WiFi flash size 4194304, free heap 24184
WiFi IP address 192.168.10.50
WiFi signal strength -70dBm, reconnections 0, sleep mode modem
Socket states: 0 0 0 0 0 0 0 0
=== Filament sensors ===
Extruder 0 sensor: ok
Extruder 1 sensor: ok
Extruder 2 sensor: ok

-70dBm isn't good-good, but it should be more than enough to transfere files. Last time i checked it was -64dBm and i haven't seen anything worse than -70 on it before

Phaedrux

@exerqtor said in Can't upload "large" files:

it's not a wifi signal issue

@exerqtor said in Can't upload "large" files:

WiFi signal strength -70dBm

That's debatable. It's not awful, but not great. Only way to test would be to temporarily improve the line of sight to the router and see if the transfers still fail.

Is it just large file transfers that fail, or smaller ones as well?

You could also try backing up the SD card and formatting it with 64kb cluster size and trying again. Do a full overwrite format incase the card is failing. The full write format would touch every cell and turf any bad ones and replace them with the extras in over provisioning area.

Exerqtor

@phaedrux

Yeah it ain't as good as it could be, but it shouldn't be a problem with 10-20MB files as long as the client is stationary should it?

I've changed SD-card once trying to remedy the issue with no luck. It's really up and down as to when it fails. Before i started the print that's going now i tried to edit the config.g, and it threw a Network Error when i tried to save it. And my config.g ain't more than 9kB.

I tried to reboot the printer and it didn't help. Rebooted my Switch and AP and it didn't help, then i just turned off the whole printer and ate dinner. When i flipped it back on 1-1.5 hours later it accepted the 5.6Mb file i tried to transfere earlier.

Phaedrux

What model is the router?

Exerqtor

@phaedrux

No routing is happening on my side at all. But I'm running a Ubiquiti Unifi setup, the AP is a UAP-AC-PRO.

Phaedrux

It may be worth exploring what the ubiquity has for options particularly with 2.4ghz clients.

Exerqtor

In what regard? I'm running a separate SSID for 2.4Ghz and 5Ghz with the printer on a static ip outside the DHCP range, and all band steering is disabled since i have separate SSID's.

Just checked what connection i have to the printer from the AP side and it say -61dBm there, which sould be more than enough as far as i can understand.

gtj0

Try uploading with FTP and see if it's any different.

Exerqtor

@gtj0
Forgot to mention that, FTP's totally useless. When i connect with winscp, and go to say macros, and then try to go back root it crashes and i get timed out.

gtj0

@exerqtor said in Can't upload "large" files:

@gtj0
Forgot to mention that, FTP's totally useless. When i connect with winscp, and go to say macros, and then try to go back root it crashes and i get timed out.

Yeah, better FTP compatibility is on my list of things to look at.

The ncftpput command seems to work reliably for just uploading a single file.
ftp://ftp.ncftp.com/ncftp/binaries/Setup NcFTP 3.2.6.msi
Well, except for the first attempt after the Duet resets.

Not a permanent solution of course but it may indicate where the issue lies.

dc42

I think the issue is the low signal strength (-70dBm), which combines with the small antenna size on the WiFi module to give this type of problem. The simplest solution is probably to put a WiFi repeater in the same room as the printer.

Exerqtor

@dc42

Okey, then i'll try with another AP in the second floor haha.

What speeds is normal on the transfere btw?

dc42

@exerqtor said in Can't upload "large" files:

@dc42

Okey, then i'll try with another AP in the second floor haha.

What speeds is normal on the transfere btw?

With a good signal strength in an uncongested WiFi environment, 700 to 900 kbytes/sec is typical.

jrjones88

@exerqtor
Where I have my printer connected to is similar, and I'm not getting any issues uploading, so I would say that -70dBm is good enough.

I have -71dBm connected through a Ubiquiti AP-AC-LR
Unifi reports a -65 dBm signal and a TX rate of 65 Mbps
I have speeds of around 200-250 kb/s as well, which I had before too located closer to an AP.

FYI my phone connected to the same AP has a self reported signal of -65dBM and a TX rate of 130 Mbps, while Unifi reports it has a -82 dBm signal and TX rate of 234 Mbps. My phone is about 4 meters further away from the AP.

oliof

The reported TX rate is unrelated to actual attainable throughput and is "just" dependent on the chosen wifi variant (i.e., 5GHz will almost always show you a higher tx rate even though that is only attainable in oractice at very short distances between AP and client).

My duet WiFi is located at the outskirts of home WiFi range and if a large mass of water intervenes between the WiFi AP and the printer (i.e., if I sit between the both), the signal is sometimes dispersed well enough to make uploads impossible.

And, as I learned from working on large WiFi installations, the best way to fix WiFi issues is to switch to Ethernet (-: (only applicable where practical).

Phaedrux

@oliof said in Can't upload "large" files:

the best way to fix WiFi issues is to switch to Ethernet

The problem with wifi is the lack of wires. Air is an awful conductor.