Thanks so much for these replies!

I did not know the Duet tool board existed.
Sadly I am still on the Duet 2 Wifi so the toolboard is not compatible.

But probably my reduction to common Gnd, Vin and 5V and a splitter board on the printer already is enough so I can fir everything in the 7mm cable chain.
And I also love the ide to be able to unplug stuff on the carriage board and not having to undo all cabling when changing one component.

@dc42 @deckingman
I'd love to upvote you, but due to reasons beyond my understanding, I have -1 reputation and can not upvote.
so just thank you

@Tryptamine

I found the solution! The issue was with my NGINX configuration limiting upload file size. Here's what fixed it:

In my NGINX config for the domain, I added:

client_max_body_size 100M;

location / {
    # existing settings...
    proxy_read_timeout 300;
    proxy_connect_timeout 300;
    proxy_send_timeout 300;
}

This increased the max upload size to 100MB and extended the timeout to 5 minutes. After restarting NGINX, the 413 error disappeared and I can now upload larger files through my domain without issues. So happy to have this resolved!

@o_lampe
I only hold the calliper there to visualize the problem. I made dozens of measurements in multiple prints.

@droftarts I have the 24V heater since a long time already The problem back then was i had all my wires through a cold water connection hose and could not change single parts.

And also, even though I planned to change the heater block anyway, I can not accept a problem to be just "unsolvable", especially with software. I thought there must be a way, just for my ego so to say.

Indeed it was your approach M307 H1 ... after the M950 H1 ... that solved the issue!
Big times thank you for this again. Made the printer last for some important prints before the heater core swap.

I understand the safety concerns, but for me, it makes no sense to destroy someone's reputation because he asked for advice.

Thanks for helping out on this one and for the upvotes!

I will update you when my new carriage and daughterboard are finished.

@droftarts Thank you so much for this qualified answer.
You were the only person here really helping me out.

I tried to fix a GCode issue and not to get moral advice from everyone.
And I find it condescending from all the others to put themselves in a position where they feel like they have the right to judge about me and give me commands i just have to follow.

We are all on eye level here. If you want to recommend something, do it like droftarts.
Give your recommendations, but do not impose them, and do not treat me as I am an idiot.

A smoker asks you for a lighter.
You can give a lighter or not.
You can give the lighter and tell them smoking is bad for them (which they probably know already)

But nobody in his right mind would not give a lighter and instead call them an idiot for smoking and start an argument about how stupid his decisions are.
"Oh you TRY to quit? Fucking quit now already! It is dangerous! You are stupid!"

You do the exact same thing only in another domain, and feel totally fine with it. Why so?

@Tryptamine

I found the solution! The issue was with my NGINX configuration limiting upload file size. Here's what fixed it:

In my NGINX config for the domain, I added:

client_max_body_size 100M;

location / {
    # existing settings...
    proxy_read_timeout 300;
    proxy_connect_timeout 300;
    proxy_send_timeout 300;
}

This increased the max upload size to 100MB and extended the timeout to 5 minutes. After restarting NGINX, the 413 error disappeared and I can now upload larger files through my domain without issues. So happy to have this resolved!

@Tryptamine

I just found out:
If i use the local IP of Duet Web, it succeeds. Using my Domain over Port forwarding to NGINX, the error occurs. So it is a network configuration issue, but not one of Duet Web.

I will still update this thread with a solution.

I have an issue in my Duet Web interface.
When trying to upload a gcode, i get:

Failed to upload FILE.gcode
bad status code 413

putting the files directly on the SD card works.
413 appears for The Upload and start, as well as upload gcode in Jobs.

this apparently is a file size issue:
Uploading an empty .gcode file (like 1kb) works.
Uploading a large other file to system files also does not.
Tested on multiple browsers.

And confusingly, i could upload the same gcode last week, and did not change the system.

What could be the issue here?

@droftarts
NOT inserting the SD card made the board available on Windows!!!
It is listed as Boassa Program Port (COM12)
I will update once I have news. Thank you SO much!

@droftarts Ah, and regarding the wiring issue: There is none
I can show you a schematic of the board once i boot my other machine.

You see the upside of the board in this image, what connects to the Duet.
This uses as many common wires as possible. There is one GND, one 3.3V, one 5V, one 24V - This is the 4 pin connector next to the fuse.
This power is distributed on the backside to the BLT, i know it needs 5V (this is why Board v2 is printed to the PCB... ), 3.3V, GND, and 2 control signals.

Regarding the Z Motors, i connected the second Z motor to the E2 stepper driver to distribute the load.

@droftarts That makes me really, really angy.
As it was inserated as genuine Duet 2 Wifi board, and even comes with the Duet text on the front (other than the clone board), so i was not critical - now its too late to reship, but i will try.

Thanks for mentioning where i could get the iap4e.bin, but that is too late now. When first erasing, only after pressing reset, this blue LED came on. And i could still revert to normal mode by powering freshly.

The moment i reset the board to SAM-BA mode, like i read, by shorting the erase wire while the board is disconnected, then attaching USB, then unshorting, the blue LED remained on.
This is the state i described above:
@Tryptamine said in Duet 2 WiFi Trapped in Blue Light not recognised:

On Windows, it's still visible as "device descriptor request failed". This persists even after uninstalling the driver, trying to reinstall, rebooting Windows, or changing USB ports.

Ubuntu 22 doesn't see it under ls /dev/tty* and it's not listed under lsusb. I even tried formatting the SD card to FAT32 with 64KB allocation units, but there was no change.

i tried variious restarts ot switching of usb ports without any effort. are there specific drivers i could try to support this bootloader mode?

And why does not even Ubuntu recognize the board?

@dc42 i am 100% sure it is a genuine Duet2, v1.04.
I bought it new from eBay after frying my fake duet board. It was very important for me to get a genuine one, as i was working so much together with this community that i wanted to give something back.
The cooling blocks are these of my old board.

It also had firmware pre-installed, but i could not update to the most recent version.
M997: Firmware binary "Duet2CombinedFirmware.bin" not found
It was first not seeing the Duet2CombinedFirmware.bin (even though i placed all 3 relevant .bind it in /firmware), then i placed the binaries additionally in /sys and in /.

/
   Duet2CombinedFirmware.bin
   Duet2_SDiap32_WiFiEth.bin
   DuetWiFiServer.bin
/firmware/
   Duet2CombinedFirmware.bin
   Duet2_SDiap32_WiFiEth.bin
   DuetWiFiServer.bin
/sys/
   Duet2CombinedFirmware.bin
   Duet2_SDiap32_WiFiEth.bin
   DuetWiFiServer.bin

it then complained for M997: In-application programming binary "iap4e.bin" not found

At this point i decided to go for the erase route, which i regret now.
Is there any way out? Except buying yet another board? I have a Pl2303 programmer and an ST-Link v2.

It is so enormously frustrating. I re-build my printer from scratch, taking almost 2 years.
Re-do the full wiring, create a custom extruder daughterboard with common phases to reduce the amount of wires. And just before starting, i short the board and it literally blows up.
I then get a new board, reinstall everything, measure all individual contact points to be 100% sure to not fry the board again. All fine! Lets update the firmware...

A meanwhile dusty daughterboard:

@droftarts sure!

Leds which are on:
Diag (blue)
3.3 (red)
5 (red)
the one between reset button and the microusb connector (red)

@Tryptamine I urgently need help with this. Any idea is appreciated.

Hello all,

I recently got a new official Duet 2 WiFi to replace my broken one. It came without firmware, so I tried updating over YAT, but that didn't work.
I then decided to flash using BOSSA, which required erasing the board first.

I shorted the erase pins and reset the board. The blue light came on, but my Windows now only sees it as "device descriptor request failed".

To try and recover, I attempted to put the board in SAM-BA mode. This involved:

1. Disconnecting power and USB
2. Shorting the erase pins
3. Connecting USB while keeping the pins shorted
4. Removing the short

After this procedure, the board remains in the blue light state. On Windows, it's still visible as "device descriptor request failed". This persists even after uninstalling the driver, trying to reinstall, rebooting Windows, or changing USB ports.

Ubuntu 22 doesn't see it under ls /dev/tty* and it's not listed under lsusb. I even tried formatting the SD card to FAT32 with 64KB allocation units, but there was no change.

At this point, I'm considering reflashing the bootloader. I have various programmers available, but I'm not sure about the process for the Duet 2 WiFi.

Has anyone faced a similar issue? Any suggestions on how to proceed, or guidance on reflashing the bootloader safely?

Thanks in advance for any help!

Current state:
- Board stuck in blue light state
- Windows: "device descriptor request failed"
- Ubuntu: Not visible in /dev/tty* or lsusb
- SD card formatted to FAT32 (64KB units)