I had a print fail again, but this time it wasn't through Octoprint; I ran it straight off the SD card in DWC. It just said disconnected, and when I connected back again the Duet had reset itself.

Here is the M122:

M122
=== Diagnostics ===
RepRapFirmware for Duet 2 WiFi/Ethernet version 2.0(RTOS)RC5 running on Duet WiFi 1.0 or 1.01 + DueX5
Board ID: 08DAM-999TL-MQ4S8-6J9D8-3SJ6N-15B3W
Used output buffers: 1 of 20 (9 max)
=== RTOS ===
Static ram: 28452
Dynamic ram: 96600 of which 16 recycled
Exception stack ram used: 348
Never used ram: 5656
Task NETWORK ready, free stack 440
Task DHTSENSOR blocked, free stack 36
Task HEAT blocked, free stack 1256
Task MAIN running, free stack 3588
=== Platform ===
Last reset 00:00:18 ago, cause: software
Last software reset at 2018-05-25 20:34, reason: Assertion failed, spinning module Platform, available RAM 5284 bytes (slot 3)
Software reset code 0x4090 HFSR 0x00000000, CFSR 0x00000000, ICSR 0x0041f80e, BFAR 0xe000ed38, SP 0x2001ffb4
Stack: 2001e6a0 2001e6d4 00445509 00000000 00000001 00000001 20006c68 20006bf4 00444885 2001e6ec 20006bf4 00000000 00f00000 e000ef34 c0000018 00000003 004449c7 00444738 61000000 b082b430 b33b9d04 b2c96804 41b4f041 3480f444
Error status: 0
Free file entries: 10
SD card 0 detected, interface speed: 12.0MBytes/sec
SD card longest block write time: 0.0ms
MCU temperature: min 50.2, current 50.6, max 50.7
Supply voltage: min 24.0, current 24.1, max 24.4, under voltage events: 0, over voltage events: 0
Driver 0: standstill, SG min/max not available
Driver 1: standstill, SG min/max not available
Driver 2: standstill, SG min/max not available
Driver 3: standstill, SG min/max not available
Driver 4: standstill, SG min/max not available
Driver 5: standstill, SG min/max not available
Driver 6: standstill, SG min/max not available
Driver 7: standstill, SG min/max not available
Driver 8: standstill, SG min/max not available
Driver 9: standstill, SG min/max not available
Expansion motor(s) stall indication: yes
Date/time: 2018-05-25 20:35:16
Slowest main loop (seconds): 0.005176; fastest: 0.000070
=== Move ===
Hiccups: 0, StepErrors: 0, LaErrors: 0, FreeDm: 240, MinFreeDm 240, MaxWait: 0ms, Underruns: 0, 0
Scheduled moves: 0, completed moves: 0
Bed compensation in use: none
Bed probe heights: 0.000 0.000 0.000 0.000 0.000
=== Heat ===
Bed heaters = 0 -1 -1 -1, chamberHeaters = -1 -1
Heater 3 is on, I-accum = 0.0
=== GCodes ===
Segments left: 0
Stack records: 1 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 ===
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.21
WiFi MAC address 5c:cf:7f:2c:27:2d
WiFi Vcc 3.38, reset reason Turned on by main processor
WiFi flash size 4194304, free heap 13136
WiFi IP address 192.168.2.143
WiFi signal strength -58dBm, reconnections 0, sleep mode modem
Socket states: 0 0 0 0 0 0 0 0
=== Expansion ===
DueX I2C errors 0

This was a different GCode file then the one that failed previously in Octoprint. Funny enough it was about 3.5 hours into the print again.

Thanks, that did the trick! I'm sorry, I misunderstood the documentation on the gcode page (it states "(was E3 Endstop on the expansion header)"). I can see now after looking at the pinout table how I incorrectly interpreted that.

I ran into an issue I have never seen before in the 1 series of firmware. I almost always run prints via Octoprint over the usb serial connection. About 3.5 hours into a print the connection died.

I am running firmware 2.0(RTOS)RC5 (2018-05-22b1).

Here was the error on the Octoprint terminal:

Unexpected error while reading serial port, please consult octoprint.log for details: SerialException: 'device reports readiness to read but returned no data (device disconnected or multiple access on port?)' @ comm.py:_readline:2417

In the DWC console it had this:

g-code buffer 'serial' length overflow

I ran an M122 in the DWC console interface:

M122
=== Diagnostics ===
RepRapFirmware for Duet 2 WiFi/Ethernet version 2.0(RTOS)RC5 running on Duet WiFi 1.0 or 1.01 + DueX5
Board ID: 08DAM-999TL-MQ4S8-6J9D8-3SJ6N-15B3W
Used output buffers: 1 of 20 (10 max)
=== RTOS ===
Static ram: 28452
Dynamic ram: 96644 of which 16 recycled
Exception stack ram used: 380
Never used ram: 5580
Task NETWORK ready, free stack 420
Task DHTSENSOR blocked, free stack 36
Task HEAT blocked, free stack 1256
Task MAIN running, free stack 3620
=== Platform ===
Last reset 00:04:46 ago, cause: software
Last software reset at 2018-05-24 21:58, reason: Assertion failed, spinning module Platform, available RAM 5284 bytes (slot 1)
Software reset code 0x0090 HFSR 0x00000000, CFSR 0x00000000, ICSR 0x0041f80e, BFAR 0xe000ed38, SP 0x2001ffb4
Stack: 2001e6a0 2001e6d4 00445509 00000000 00000000 00000001 20006c68 20006bf4 00444885 2001e6ec 20006bf4 00000000 00f00000 e000ef34 c0000018 00000003 004449c7 00444738 61000000 b082b430 b33b9d04 b2c96804 41b4f041 3480f444
Error status: 0
Free file entries: 10
SD card 0 detected, interface speed: 12.0MBytes/sec
SD card longest block write time: 0.0ms
MCU temperature: min 46.6, current 46.7, max 49.5
Supply voltage: min 24.0, current 24.2, max 24.4, under voltage events: 0, over voltage events: 0
Driver 0: standstill, SG min/max not available
Driver 1: standstill, SG min/max not available
Driver 2: standstill, SG min/max not available
Driver 3: standstill, SG min/max not available
Driver 4: standstill, SG min/max not available
Driver 5: standstill, SG min/max not available
Driver 6: standstill, SG min/max not available
Driver 7: standstill, SG min/max not available
Driver 8: standstill, SG min/max not available
Driver 9: standstill, SG min/max not available
Expansion motor(s) stall indication: yes
Date/time: 2018-05-24 22:03:05
Slowest main loop (seconds): 0.372014; fastest: 0.000069
=== Move ===
Hiccups: 0, StepErrors: 0, LaErrors: 0, FreeDm: 240, MinFreeDm 240, MaxWait: 0ms, Underruns: 0, 0
Scheduled moves: 0, completed moves: 0
Bed compensation in use: none
Bed probe heights: 0.000 0.000 0.000 0.000 0.000
=== Heat ===
Bed heaters = 0 -1 -1 -1, chamberHeaters = -1 -1
Heater 3 is on, I-accum = 0.0
=== GCodes ===
Segments left: 0
Stack records: 1 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 ===
Responder states: HTTP(4) 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.21
WiFi MAC address 5c:cf:7f:2c:27:2d
WiFi Vcc 3.38, reset reason Turned on by main processor
WiFi flash size 4194304, free heap 15000
WiFi IP address 192.168.2.143
WiFi signal strength -65dBm, reconnections 0, sleep mode modem
Socket states: 0 5 0 0 0 0 0 0
=== Expansion ===
DueX I2C errors 0

I know I am weird to still use Octoprint with a Duet Wifi, but I like the various plugins and record keeping that it provides over the DWC interface. Thanks!

I am attempting to configure a DHT22 sensor (this model: https://www.amazon.com/gp/product/B01N9BA0O4/ref=oh_aui_detailpage_o01_s00?ie=UTF8&psc=1), and I also have a Duex5 attached to my Duet Wifi. By my understanding, the data pin on the sensor should be attached to pin CS6, i.e. the E3 endstop line. So I have made a connector that plugs into the E3 endstop slot on the Duex5, where I am pulling both a positive voltage and ground for the sensor in addition to connecting the data line. With this setup, I have had no luck getting the sensor to work in DWC; it always shows 2000 degrees and 2000% for humidity.

I am setting up the sensor as follows:
M305 P103 X400 T22 S"Chamber Temperature"
M305 P104 X401 T22 S"Chamber Humidity [%]"

I am running firmware 2.0(RTOS)RC5 with wifi server version 1.21.

I have verified the module does work on its own using a Raspberry Pi. I have tried using both 3.3 and 5 volts for the endstop power on the Duex5, with no change in the results. I have verified the connections from the Duex5 to the sensor using a multimeter. I have tried a basically blank config.g file with only the preamble setting up the network and the gcode lines I gave above to configure the sensors, and I had no luck there either.

Is there something I am missing here? I am wondering if the fact I have a Duex5 attached is somehow blocking the CS6 pin to be used for this.

Thanks for your help!