I have acquired a Duet 0.8.5 controller and a Duex4 expansion board, with the goal of running a Kraken hotend (4x extruders/heaters/thermistors) on my Kossel delta, as well as a chamber heater, various fans, and a handful of external controls. With this in mind, I need help getting past a few hangups:

1. Can someone explain the Duex4's breakout pins for me? I'm reasonably confident that I know what connects to what, but I want to be sure… I think "H-" and "V_IN" are the +12V and -12V connections to the heater cartridge, "TEMP" and "GND" are for the thermistor, but the last three ("STOP", "3.3V" and "GND"), I have no idea...

2. Despite being the most in-depth and helpful wiki I've seen in a long time, the Duet3D wiki says nothing about which pins specifically on the Duex4 that can be used to trigger events, the same way endstops can.

3. I have 4 subsystems that I'd like to control through the Duet: A chamber heater (110V AC), mixing fans (12V DC), water pump (12V DC), and layer fan (10V DC). While the chamber heater will be controlled with a relatively forgiving solid-state relay (3V to 32V input), I need to know the output voltage(s) of repurposed pins in order to select relays to control the remaining subsystems.

4. Last week, I had a spool of filament that somehow tied itself in a knot, and to my surprise, the Select Mini hauled the spool AND the filament dryer it was in right off the shelf… I've seen an article on out-of-filament sensors and interrupts in the wiki, but I've never seen any "filament tension" sensors. In either case, is it possible to pause the print, wait for a button-press before resuming, and most importantly, beep at regular intervals until then?

5. While I intend to wire a status light (110V DC) for the chamber heater in series with the system itself (I accidentally bought a 110V lamp instead of a 12V one), I'd also like the Duet to control the status lights (12V DC) for the other subsystems. This means wiring the override switches to input pins, wiring the status lights to more output pins. Simplify3D has an option to insert a script that follows every retraction event, which is probably as frequent as I can hope for. However, I'm unsure how to use M581/582 commands to scan repurposed input pins, and if necessary, update the repurposed output pins.

I know this is a complex design, but it should be entirely possible for the Duet/Duex4 combo… I just need a little help with the details!

I've never intentionally used the default feedrate of 30 mm/s, and 100 mm/s is completely out of the question. If I accidentally click "Extrude" without switching to a slower feedrate, 9 times out of 10 it will chew up the filament beyond recovery before it will extrude anything. I think it would be fantastic if a) the feedrate values on the buttons could be customized, and/or b) the default value on startup could also be customized. Is this possible?

Huh. I hadn't noticed that, but I'm hesitant to connect the two, unless the PSU is degrading very quickly. There were about seven or eight prints between the first and second occurences, and at least fifteen between the second and third.

Well, the subject line here really sums up the problem I'm running into… It's happened three times, but not consistently. I was able to get the printer running again after the first two events, and each event occurred while uploading different files. Nonetheless, the error has manifested almost-but-not-quite-exactly the same each time. At the risk of too much detail, here is the chain of events, as best as I can describe them:

1. Power on

2. Log in to web interface (password protected)

3. Calibrate delta

G28, G32, G32, G29, G28

3. Preheat hotend (Heater 1 Active temp > 180)

4. Prime extruder (Machine control > Extrude 20mm@5mm/s until extrusion appears, then retract 5mm)

5. Upload gcode file

During upload, an upload error is shown in the progress dialogue for maybe half a second, at which point the web interface crashed and reset itself (interface greyed out, yellow "firmware reset" progress bar appeared at the bottom of the page, then the page reloaded). However, there was no login required (not a good sign), and the printer was unresponsive.

1. The first time this happened, the extruder stepper started oscillating ~20mm@10mm/s back and forth until I manually powered off the system (web interface crashed, no e-stop button). The web interface appeared normal, but I knew something was up when it didn't ask for a password. The system remained unresponsive until I powered off the system for several hours, at which point it started up and responded normally.

2. The second time this happened, the system froze completely (unresponsive, no extruder oscillation), but the web interface remained online (no password required when reloading the page). E-stop commands triggered the "system reset" progress bar dialogue, to no effect. After sending G28 commands several times with no response, I checked Settings >System Editor >homedelta.g, and was shocked to find the file was blank. I copied the contents from a backup into the blank file, and the system immediately responded to G28 commands, and for all intents and purposes, behaved normally.

3. The third time this happened (about an hour ago), the web interface crashed during upload, again briefly showing the ERROR indicators in the progress dialogue. However, instead of resetting itself, the following message appeared in a red message box at the bottom of the screen:

[[language]]
Message: Uncaught TypeError: Cannot read property 'axesHomed' of undefined
URL: http://192.168.2.16/js/dwc.js
Line: 1584:30
Error object: {}

Reloading the page brings up the web interface (note: no password required), but the system was again unresponsive, even after software reset (using emergency stop button in web interface). Attempts to reload the web interface (via F5) came back with "This site can't be reached" (ERR_CONNECTION_REFUSED in Google Chrome).

This condition did not change after hardware reset (pressing RESET button on the DuetWifi board), or after a hard reset (PSU turned off for 30 seconds).

I connected the DuetWifi to my PC with a USB cable, and Pronterface was able to connect to the board on the first attempt (COM4@115200,"Connecting… Printer is online").

Sending M552 via Pronterface indicated that networking was disabled

[[language]]
Network is disabled,
configured IP address: 192.168.1.10, 
actual IP address: 0.0.0.0,
HTTP port: 80

Sending M552 S1 via Pronterface started up the WiFi server without issue

[[language]]
WiFi server starting up; 
DuetWiFiServer version 1.02; 
Flash size 4194304,
free RAM 31504 bytes,
WiFi Vcc 3.35V, 
host name: duetwifi, 
reset reason: Turned on by main processor; 
WiFi server connected to access point <nope>,
IP=192.168.2.16,
signal strength=-47dBm</nope> 

Reloading the web interface appeared successful but did not require a password, and now G28 commands trigger a yellow message box (warning dialogue?) with the message "Macro file homeall.g not found". This was particularly concerning because the printer is a delta, and G28 normally calls "homedelta.g".

When I went to investigate the System Directory, it was completely empty. To be more specific, the frame that normally lists all the system files (Settings >System Editor) contained only the message "The current volume is not mounted" in a slightly-grey text.

At this point, I decided that this problem was way above my head. I hope this isn't too much detail, and if there is any information missing, please do not hesitate to ask. In every other respect, the DuetWifi has exceeded all my expectations, and if I have done something to damage it that would cause this error, I would buy a replacement board without hesitation. Hopefully that is not the case!

Here are some of the details that I anticipate might be useful:

Printer model: Kossel 250
Firmware name: RepRapFirmware for Duet WiFi
Firmware electronics: Duet WiFi 1.0
Firmware version: 1.17RC3 (2016-12-21)
WiFi server version: 1.02
Web interface version: 1.15

Firmware diagnostics:

[[language]]
M122
=== Diagnostics ===
Used output buffers: 1 of 32 (4 max)
=== Platform ===
Memory usage:
Program static ram used: 20260
Dynamic ram used: 83564
Recycled dynamic ram: 2672
Current stack ram used: 2872
Maximum stack ram used: 3828
Never used ram: 20748
Last reset 00:50:36 ago, cause: reset button or watchdog
Last software reset code: 0x5002, available RAM 12972 bytes (slot 2)
Spinning module during software reset: Webserver
Error status: 0
Free file entries: 10
SD card 0 detected, interface speed: 0.2MBytes/sec
SD card longest block write time: 0.0ms
MCU temperature: min 37.9, current 41.5, max 47.0
Supply voltage: min 2.1, current 24.6, max 25.0, under voltage events: 1, over voltage events: 0
Driver 0: standstill
Driver 1: standstill
Driver 2: standstill
Driver 3: standstill
Driver 4: standstill
Current date and time: 2017-04-21 08:47:32
Slowest main loop (seconds): 0.132088; fastest: 0.000000
=== Move ===
MaxReps: 0, StepErrors: 0, MaxWait: 0ms, Underruns: 0, 0
Bed probe heights: 0.000 0.000 0.000 0.000 0.000 0.000 0.000 0.000 0.000 0.000 0.000 0.000 0.000 0.000 0.000 0.000 0.000 0.000 0.000 0.000 0.000 0.000 0.000 0.000 0.000 0.000 0.000 0.000 0.000 0.000 0.000 0.000 0.000 0.000 0.000 0.000 0.000 0.000 0.000 0.000 0.000 0.000 0.000 0.000 0.000 0.000 0.000 0.000 0.000 0.000 0.000 0.000 0.000 0.000 0.000 0.000 0.000 0.000 0.000 0.000 0.000 0.000 0.000 0.000
Probe change coordinates:
=== Heat ===
Bed heater = 0, chamber heater = -1
=== GCodes ===
Segments left: 0
Stack records: 0 allocated, 0 in use
Movement lock held by null
http is ready with "M122"
telnet is idle
file is idle
serial is idle
aux is idle
daemon is idle
=== Network ===
WiFiServer is running
SPI underruns 0, overruns 0
=== Webserver ===
HTTP sessions: 1 of 8

I recently added two 40mm blowers to my hotend, positioned at 45º to either side of the JHead, and exhausting about 40mm away from the nozzle. They've been helping a lot, but tonight I had to turn the fans off momentarily during a print, and the hotend temperature spiked and threw a heater fault. I understand exactly what happened from a controls perspective, my question is how do I prevent it from happening again? Can a PID be tuned to handle that situation, or am I limited to disabling the fans gradually?