The most frustrating aspect of this board, which is great in every other way, is the Wifi module. It's downright dangerous sometimes because I know when I want to hit emergency stop, I'm going to have to re-connect, or refresh a grayed out html screen in order to do so.

Knowing what I know now with the many other reports of sub-par performance for this module and the fact it's the only wifi connected device I own that struggles consistently with connecting to my AP despite being the closest device to the AP, I would have much rather bought the ethernet version and run a third wifi mesh node just for this board.

In fact I may contact Filastruder and see if I can buy an Ethernet version and send this wifi version back. Is there any reason other than cost you guys went with the Expressif hardware? Realtek and Intel make IoT networking devices. ESP is both bad and susceptible to a myriad of common attacks, and it seems that just connecting to it and trying to use it triggers a beacon or EAP client crash.

Anyway, yeah, so if this thing can frustrate me, who has 20+ years in enterprise systems and datacenters, I don't know how your normal consumer puts up with the wifi issues. Obfuscating the issue with instructions to re-format the SD card or change wifi channel is just a smokescreen, lots of info out there in arduino communities about esp devices simply not being able to maintain connections. Next revision, please drop the bargain bin IoT networking hardware, if possible. Who knows, esp might be the only device that can run with your firmware, and if so, the wifi version should have been pulled off the drawing board.

@arhi Yes. I have a smarthome with many dozens of connected wifi devices, including cameras, motions sensors, temp sensors, windows sensors, vibration sensors, etc. I am not a "wired Ethernet or nothing guy", for enterprise systems, yes, No wifi of any kind on datacenter or enterprise systems except to provide wifi connectivity for employees. For home items, wireless is mature enough to be relied upon for most items. I run zigbee and z-wave devices on my smart things hub, and use Alexa routines to automatically tune light on/off, light colors, dimming, etc based on movement, time of day, weather and ambient light. My system also senses if people are home based on their phone present or not and performs routines accordingly, or arms cameras and sensors to keep home secure and alert on certain conditions.

As for the Duet, I have solved my issues by enabling FTP and using Filezilla to upload gcodes. If the ESP module has to re-handshake during the upload, Filezilla resumes the transfer elegantly, instead of the web control simply ending the transfer and sending a fail message. This my gcode upload times from ~15-30m to ~1-2 minutes.

So for anyone experiencing wifi upload issues in the web interface, just use FTP instead and then start the cgode file in the web interface. Problem is solved.

@bearer said in Duet 2 Wifi IoT module is disappointing:

@Dz said in Duet 2 Wifi IoT module is disappointing:

@bearer Output is below. I am not sure how much faith I have in it

thats hardly the point is it; but it is a quantitative report for dc42 and the other devs to evaluate the issue

WTF is your problem dude, seriously. I'm saying the report has proven false negatives in it.

Let me dumb it down: If my car stalls five times in a day and the mechanic produces a diagnostics report that lists '0 stalls past 30 days' then I would have a problem with all data in the report given that one metric is known false. That's the point.

@arhi Yes. I have a smarthome with many dozens of connected wifi devices, including cameras, motions sensors, temp sensors, windows sensors, vibration sensors, etc. I am not a "wired Ethernet or nothing guy", for enterprise systems, yes, No wifi of any kind on datacenter or enterprise systems except to provide wifi connectivity for employees. For home items, wireless is mature enough to be relied upon for most items. I run zigbee and z-wave devices on my smart things hub, and use Alexa routines to automatically tune light on/off, light colors, dimming, etc based on movement, time of day, weather and ambient light. My system also senses if people are home based on their phone present or not and performs routines accordingly, or arms cameras and sensors to keep home secure and alert on certain conditions.

As for the Duet, I have solved my issues by enabling FTP and using Filezilla to upload gcodes. If the ESP module has to re-handshake during the upload, Filezilla resumes the transfer elegantly, instead of the web control simply ending the transfer and sending a fail message. This my gcode upload times from ~15-30m to ~1-2 minutes.

So for anyone experiencing wifi upload issues in the web interface, just use FTP instead and then start the cgode file in the web interface. Problem is solved.

I know using the wrong type of switch for home (or maybe a failed switch) can cause that LED to go from dim to bright. I had to change the poles I used on my switch I used for homing and that dim/bright led thing stopped.

@bearer said in Duet 2 Wifi IoT module is disappointing:

@Dz said in Duet 2 Wifi IoT module is disappointing:

@bearer Output is below. I am not sure how much faith I have in it

thats hardly the point is it; but it is a quantitative report for dc42 and the other devs to evaluate the issue

WTF is your problem dude, seriously. I'm saying the report has proven false negatives in it.

Let me dumb it down: If my car stalls five times in a day and the mechanic produces a diagnostics report that lists '0 stalls past 30 days' then I would have a problem with all data in the report given that one metric is known false. That's the point.

@dc42 I think the crashing is due to the poor handshake manners in the ESP modules, and the vulnerabilities simply take advantage of this behavior. I'm certain this is my issues as well as @ElmoC and @joe92 after reading their threads.

@bearer Output is below. I am not sure how much faith I have in it because re-connections arent logged (listed as zero when I have been force re-connected a dozen times in the last hour), and failed messages show zero when i have them shown in the console.

M122
=== Diagnostics ===
RepRapFirmware for Duet 2 WiFi/Ethernet version 3.0 running on Duet WiFi 1.02 or later
Board ID: 08DGM-917NK-F2MS4-7JKDA-3SD6T-THT4D
Used output buffers: 4 of 24 (11 max)
=== RTOS ===
Static ram: 30516
Dynamic ram: 91848 of which 32 recycled
Exception stack ram used: 560
Never used ram: 8116
Tasks: NETWORK(ready,640) HEAT(blocked,1240) MAIN(running,3668) IDLE(ready,156)
Owned mutexes:
=== Platform ===
Last reset 16:09:17 ago, cause: power up
Last software reset at 2020-01-30 22:29, reason: User, spinning module GCodes, available RAM 8196 bytes (slot 3)
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: 189.1ms, max retries 0
MCU temperature: min 27.3, current 38.0, max 40.1
Supply voltage: min 24.0, current 24.2, max 24.4, under voltage events: 0, over voltage events: 0, power good: yes
Driver 0: standstill, SG min/max 0/1023
Driver 1: standstill, SG min/max 0/1023
Driver 2: standstill, SG min/max 80/426
Driver 3: standstill, SG min/max 0/86
Driver 4: standstill, SG min/max not available
Date/time: 2020-02-02 15:58:54
Cache data hit count 4294967295
Slowest loop: 74.46ms; fastest: 0.09ms
I2C nak errors 0, send timeouts 0, receive timeouts 0, finishTimeouts 0, resets 0
=== Move ===
Hiccups: 0(0), FreeDm: 169, MinFreeDm: 109, MaxWait: 1614086ms
Bed compensation in use: none, comp offset 0.000
=== MainDDARing ===
Scheduled moves: 6, completed moves: 6, StepErrors: 0, LaErrors: 0, Underruns: 0, 0
=== AuxDDARing ===
Scheduled moves: 0, completed moves: 0, StepErrors: 0, LaErrors: 0, Underruns: 0, 0
=== Heat ===
Bed heaters = 0 -1 -1 -1, chamberHeaters = -1 -1 -1 -1
Heater 0 is on, I-accum = 0.1
Heater 1 is on, I-accum = 0.7
=== GCodes ===
Segments left: 0
Stack records: 2 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 idle 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: 189.93ms; fastest: 0.00ms
Responder states: HTTP(3) HTTP(0) HTTP(0) HTTP(0) FTP(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 60:01:94:2e:a9:1f
  WiFi Vcc 3.36, reset reason Turned on by main processor
  WiFi flash size 4194304, free heap 22144
  WiFi IP address 192.168.50.71
  WiFi signal strength -52dBm, reconnections 0, sleep mode modem
  Socket states: 2 0 0 0 0 0 0 0

My Plight:

@joe92 I am on the same firmware and experience the same issues uploading gcode files. I think my record is 34 consecutive upload attempts, but eventually, it goes. Just gotta keep trying to smash it in there and the stars will align and the wifi fairy will sprinkle the right dust.

Board: Duet WiFi 1.02 or later
Firmware: RepRapFirmware for Duet 2 WiFi/Ethernet 3.0 (2020-01-03b3)
Duet WiFi Server Version: 1.23

@jens55 You're a minority in the ESP32 populace and I envy your stable connection Helpful Google Search Link

@bearer You're right. I should just hit the hardware palm slapper emergency stop button included with the kit, right? Or walk down stairs and hit the toggle on the C14 I installed for the Meanwell. Oh wait, yeah, that will that take longer than hitting F5 and spamming the button location, I bought a network connected device so I can control it through a web interface, but soldering the eth module might be an option.

Yes this post is a product of frustration from this morning when all I wanted to do was upload a gcode file, which failed 14 times in a row because the very act of uploading it caused the espressif module to lose it's mind, for no reason. My printing enclosure is literally 18 feet from my router, which is an Asus GT-Ax11000 and it has no issues beaming wireless through physical infrastructure. My phone and laptop can connect to it through three stories of flooring and plumping.

This is an example is an otherwise incredibly well designed and built board instilling an undeserved amount of frustration into the end user because of the less than transparent human to product interface. And it's honestly not dc42's fault, it's the devs in China, and maybe, to a lesser extent, Tensilicia because Espressif uses some closed source IP from Tensilica which allows some of these vulnerabilities to float around longer than they should. But for anyone else searching these forums for a fix, you're not alone.

The most frustrating aspect of this board, which is great in every other way, is the Wifi module. It's downright dangerous sometimes because I know when I want to hit emergency stop, I'm going to have to re-connect, or refresh a grayed out html screen in order to do so.

Knowing what I know now with the many other reports of sub-par performance for this module and the fact it's the only wifi connected device I own that struggles consistently with connecting to my AP despite being the closest device to the AP, I would have much rather bought the ethernet version and run a third wifi mesh node just for this board.

In fact I may contact Filastruder and see if I can buy an Ethernet version and send this wifi version back. Is there any reason other than cost you guys went with the Expressif hardware? Realtek and Intel make IoT networking devices. ESP is both bad and susceptible to a myriad of common attacks, and it seems that just connecting to it and trying to use it triggers a beacon or EAP client crash.

Anyway, yeah, so if this thing can frustrate me, who has 20+ years in enterprise systems and datacenters, I don't know how your normal consumer puts up with the wifi issues. Obfuscating the issue with instructions to re-format the SD card or change wifi channel is just a smokescreen, lots of info out there in arduino communities about esp devices simply not being able to maintain connections. Next revision, please drop the bargain bin IoT networking hardware, if possible. Who knows, esp might be the only device that can run with your firmware, and if so, the wifi version should have been pulled off the drawing board.