Regarding fuses: I recently blew the fuse on a Duet 0.6 board, and was surprised to find that @dc42 has since then moved to a self-resetting fuse in his designs. I made the modification to add it to my board, and find that to be a really nice feature, considering my likelihood of forgetting to turn off the board prior to working on the hotend. I can't find the post about it at the moment, but iby maso - RAMPS Electronics
Thanks for getting back to me. I'll probably stick with 1.18.2 on that printer, but here are some more data points if it's helpful: - My router recognized the MAC address and set aside an IP address while it was in its reset loop. I couldn't access it in the browser. - When I plugged Ethernet in after booting, starting the "Network down" cycle, the router still set aside the IP address, butby maso - Duet
Apologies if this was answered elsewhere, but I can't get my Duet 0.6 to play nicely with firmware / webcontrol 1.20. It's been powered on for over a year, and I've done updates over the web interface, and everything was working fine with 1.20/1.20. But after a power cycle, it would sit in a constant reset loop. I managed to narrow it down to the Ethernet interface, because if I unplug that itby maso - Duet
I've got a self-built delta printer as well, and have used 3 different controllers over the years: -RAMPS -AZSMZ (smoothieboard clone) -Duet 0.6 (old and "obsolete" now) When it comes down to it, even the RAMPS was sufficient. But things seemed smoother when I switched to the 32-bit controller on the AZSMZ board. I found the AZSMZ to be a bit of a headache to manage--poorly documented, and difby maso - Delta Machines
I use Octoprint with Duet, and I get E values back: Send: N38782 M114*33 Recv: X: 0.000 Y: 0.000 Z: 333.841 E0: 64369.1 E1: 0.0 E2: 0.0 E3: 0.0 E4: 0.0 E5: 0.0 It's an old Duet 0.6, with firmware 1.18.1 Octoprint version 1.3.5by maso - Duet
QuoteNapalm1432 It doesn't seem to initialize the sd card in octopi right now though, i'm looking for a fix now Running an M20 from the octopi terminal does list the gcode files (only 1, the testprint.gcode) I haven't ever put any effort into using OctoPrint to access g-codes from the Duet's SD card. In my experience with RAMPS and other boards, it takes a long time to send g-code files over tby maso - Duet
Have you gone through the steps listed under "First Connection" here?by maso - Duet
Also, now that you've discovered a bad USB cable, why not try the Raspberry Pi again?by maso - Duet
I'd try plugging the USB into a windows machine and see what happens. You should be able to communicate with it via Pronterface or Repetier-Host if everything's configured right. Also try changing USB cables -- maybe it's bad?by maso - Duet
Check out this picture: There's an "External 5V Enable" and a "Board 5V Enable" header on there. I'm pretty sure you have to choose one. (EDIT: Try the "Board 5V Enable". I think the "External 5V Enable" is for when you have an ATX supply attached.) Also, on the Pi, try typing ls /dev without the Duet plugged in, and then with it plugged in, and see if something new has shown up. That's youby maso - Duet
I'm running OctoPrint with my Duet 0.6 board, and have been for a while. I send commands over a USB connection to the Duet, just like you outlined, and there's no need for a router and another PC if you've got the touchscreen up and running. It's probably an issue with your connection settings within OctoPrint. For what it's worth, I've attached screengrabs of settings that work for me.by maso - Duet
I'd say that you probably only need 2 motors. Use 3 pivot points, but you only need to adjust two of them to get everything leveled.by maso - Duet
Quotedc42 You could try updating iap.bin to the new version. Follow this link and then press Download. That worked. I'm getting temperature updates in Octoprint now. Thanks!by maso - Duet
@dc42 has included the M190 temperature feedback in firmware 1.18 beta 1. Thanks again! SOLVED.by maso - Duet
Wow! Thanks for the M190 temp feedback too! Will install and test. -------- EDIT: The Duet 0.6 firmware doesn't seem to be taking. I downloaded it from Release/Duet-0.6-0.8.5/Edge but after uploading it and going through the "installing firmware, please wait" steps, I'm back to 1.17e.by maso - Duet
Here's my interpretation, following the last line on that screengrab: (note: This printer has 2 extruders, bed, and cooling fan. Nozzle 2 was cooling from having been heated) T:49.24 /0 B:27.44 /50 B@:255 @:0 T0:20.61 /0 @0:0 T1:49.24 /0 @1:0 T - temperature of active nozzle (in this case nozzle 2) 49.24 degrees / set to 0 degrees (off) B - temperature of bed 27.44 degress / set to 50by maso - Duet
Thanks for being willing. I'll see if I can find anything, since M190 seems to be how Slic3r generates a bed preheat. For what it's worth, here's how Repetier firmware responds to an M190 request: It continues updating temperature info while the bed heats. ----------------------------------------------------------------------- Edit: Upon further reflection, I don't believe it is responding tby maso - Duet
I don't think this is an Octoprint thing. I think this is a matter of the standard response to an M105 temperature request ceasing when the M190 command has been sent. I think it would be a problem in Repetier Host or Pronterface too, if that's where I was using this. I just happen to be using Octoprint. In the attached picture, you can see a periodic M105 "what's your temperature" request, anby maso - Duet
I agree that the Duet Web Server is nice. However I have a number of reasons that I'm using Octoprint, including the ability to generate a timelapse video of my prints (useful in case of failure) and previewing the toolpath of the G-code. But this is a consistent and reproducible issue for me that isn't present with other boards, running other firmwares. It would be nice if it would continue tby maso - Duet
I have a Duet 0.6 running 1.17e firmware. I'm finding that if I send an M190 command through the USB serial interface, I don't get temperature updates back until the bed has heated. I get updates during an M104 to heat the nozzle, but nothing for the bed. This is causing issues for me with Octoprint because it times out and thinks the interface is dead while the bed heats. (Plus I'd kinda likby maso - Duet
I've been using Nema 23's on my Duet with no trouble for the last couple years.by maso - Duet
Quotedc42 PS are you certain that heater 1 is not working but in a fault state? Use M562 P1 to reset it. Heh heh. Your reminder got me thinking. I've had this thing plugged into the USB on my computer in addition to my power supply lately. So my power cycles weren't really power cycles. I pulled all power to the printer, then re-applied it. The heater works again! I had just jumped straigby maso - Duet
Thanks for the idea @dc42. Unfortunately it doesn't appear to be the issue. Pin 66 is 3.3V as well, and pushing down on it didn't do anything really. I'm afraid that pin might be dead. I could perhaps try snagging one of the pins from the expansion header -- I'm not using it for anything. Is there an easy way I could re-assign another pin to that task within firmware? Or would that involveby maso - Duet
I've been running a Duet 0.6 on my delta printer for quite some time. The other day, in the middle of a print, the hot end temperature dropped and I have been unable to get it to heat anymore. I've probed the board with a multimeter, and find that the EO_PWM line (at the GATE of TR3) is always HIGH, regardless of whether I have set a temperature or not. If I pull that pin LOW by shorting to thby maso - Duet
I'm excited to hear about your work! I used the M117 command on my old controller, and see it as a nice feature for when I'm using my printer in demonstrations. "Warming up", "Printing skirt", "Cooling off", and "Done" are things that let casual observers see what the print is up to. A thought is that the M117 code could be displayed until the next layer change, or something else time-based. Buby maso - Duet
As a follow-up: I got a new Duet board and replaced my old one. Everything works great again! I don't know what failed, but it appears to have been a hardware issue, not a firmware one. The original error "Attempt to move the head of a delta printer before homing the towers" was due to the motors not moving at all, and the home process timing out without triggering the endstops.by maso - Duet
QuoteMasterjuggler At the end of the day, the quality of the filament can be almost completely compensated for just by tuning the printer well. That said, I really don't know whether or not my filament (hatchbox) is "good quality" compared to other filaments. What I can tell you is after the past year of working with it, I can get some damn beautiful prints out of it with the proper settings. Iby maso - Duet
It seems to me that you're basically looking to implement the flying extruder that's popular in delta printers. I recently outfitted my delta with one: picture in case you don't know what I'm talking about ...and the spring mounted suspension might keep your issues at bay. The extruders are free to twist and change height based on head position, but don't have to be moved around laterally at aby maso - CoreXY Machines
Agreed on the "too much cooling" front. I over-engineered a fan to blow just under the nozzles, right at my print. But the problem wasn't that print quality suffered, it was that the nozzle got cooled too and the heater couldn't keep up. So the temperature would drop until I got a "thermistor decoupled" error (in Repetier, not RepRapFirmware). Took me forever to find because it didn't happen wby maso - Duet
You're right--I'm reading 0.66V with 800mA on all but X. I was going from memory when I said 0.4V. I can verify that when I first power the board on, the enable(not) lines are HIGH. I press the "HOME" button, then quickly trigger all 3 endstops manually, and the enable(not) lines go LOW (and the firmware registers a successful HOME, so now we know why that "Attempt to move the head..." error waby maso - Duet