I fried my DuetWifi by shorting something. I have no idea what I have touched, but I heard a faint popping sound and it stopped working entirely. The damage I can see is a pool of molten plastic and a breakdown crater in U2.

I replaced the board with a Duet 2 Wifi and now the Duex5 does not register. I can't find any obvious damage in it and I have not touched it while replacing the Duet. The two endstop lights on the Duex5 are on, and that is all I can see. Is there a way to find out whether it is salvageable?

Thanks to everyone for useful suggestions. I have tested all and got wildly different results. Then I dug in a bit deeper into this whole calibration issue and found that there is really no good way to do it without dismantling the hotend. The best option is to calibrate the thermistor in a precise bath thermostat before putting it in. You might be able to obtain a sensible result by doing an in-place calibration if your hotend is small and well-insulated, but with the Diamond Hotend, that is nearly impossible.

I went ahead and did it the hard way, using a trick that does not seem to be easily reproducible. I did realize early on that it was a stupid thing to do, but it was too much fun to quit, and in the end, I did achieve a passable result. I have summarized my findings at https://github.com/selkovjr/gt-2-thermistor-experiment

The next time I have to do it (my bed thermistor is next), I will construct an external thermostat.

David, your suggestion that it could be104GT seems to have been spot-on, although the best-fitting curve looks almost parallel to 102GT, which is an odd one in the family. It is possible that it is a somewhat odd 104GT. Maybe it is a QC reject. Its room-temperature resistance is within the norm but the estimated B value is almost 3% off. I posted a couple NLS fits on that github page.

No, I don't have any idea about the origin of my hot end thermistor. All I know is that it is extremely small. It looks like a tiny glass bead, less than 1mm in diameter. It came with a Diamond nozzle I bought from BiQu.

Guess what. I was unable to achieve a 2-degree accuracy with this thermistor using the Steinhart-Hart model over the entire range of temperatures. Disappointingly, its worst error (-4℃) peaks in the most common range of printing temperatures. I am not sure if I overfit the model or it is just a weird thermistor.

But the good news is that heater faults have completely ceased after I applied the calibration settings and re-tuned. Prior to that, I had to reset the heater a dozen times before it was able to reach the target temperature.

[[language]]
M305 P1 T97000 B4800 C1.0705E-7
M303 H1 S240
M307 H1
Heater 1 model: gain 358.7, time constant 266.1, dead time 3.3, max PWM 1.00, calibration voltage 13.5, mode PID, inverted no, frequency default
Computed PID parameters for setpoint change: P39.9, I1.341, D92.7
Computed PID parameters for load change: P39

I suspected it all along but couldn't articulate it properly. I am still not sure I understand it, but something makes me think that if you calibrate your physical model in weird temperature units, you can't expect the resulting time constant to be commensurate with a time interval defined in seconds.

I don't trust myself to do even the most trivial calculations, so I went for the dumbest and most direct method of calibration. I took a thermistor that I received with the original RepRap kit (also of unknown type, but it didn't matter) and stuck it between the hot end block and the insulation blanket. I connected it to the Duet instead of the hot end-mounted one that I was calibrating, just so I had a thermostat. That allowed me to use a high-impedance meter to measure that thermistor's resistance directly. The reference thermocouple fit very nicely in a set screw hole in the heater block. I believe it is the set screw that holds the heater cartridge, so it was close enough to the heater to be an accurate reporter. The only little problem with that method was that the thermocouple had a higher thermal mass than the thermistor (about 20x), so I had to wait half-a-minute for their readings to equilibrate. Also, I took an equal number of measurements while heating up and cooling down, to reduce the residual delay bias.

So it feels like progress, but there are a few questions I am wondering about:

• How bad is the deviation of 4℃ over 220℃?

• Is the shape of the error curve I observed typical for the SH model?

• If not, is it symptomatic of any known measurement error?

• Is there a way to use the data I collected to build some sort of interpolated lookup table instead of a functional model?

On to the next problem.

I notice many people have problems with heater faults. So do I, but that's not the first thing I need to worry about. I have a theory for what might be the most common cause for it, and I want to check it out first.

I know my temperature sensors are not calibrated. Bed temperature gain is at least 50% off; the hot end is similarly out of whack. That did not matter much when the machine was controlled by Melzi. I simply knew what temperature values corresponded to good printing results and did not obsess about how far off they were. Besides, there was no easy way for me to get them right. Now I've got a good lab-grade thermometer with a very small thermocouple that will report accurate temperatures wherever I stick it. I can even insert it in the feed side of the nozzle. For that to be useful, I think I need to sample the ADC output (which I believe is fed directly into the PID model). I could calibrate it indirectly, by reversing the model, but that would no doubt require multiple iterations and a lot of time.

I can't see how an auto-tuned PID model can behave well if it is trained on the wrong temperature scale. I may be wrong, but I suspect that the key to successful PID tuning lies in a reasonably accurate sensor calibration. We should be able to get it to within ±2℃ without much effort. It probably isn't much of a problem for people who use well-known high-precision thermistors, but I have no idea what mine are and want to get a good estimate of their parameters. I will appreciate any clues on how to read the encoded temperature values from the Duet.

Yes, I had noticed pressure advance and it did help a little bit, to the extent that I was able to find an optimumal setting. But it did not solve the problem.

Here's what happened. I guesstimated speed and acceleration limits from major resonance modes, and they turned out to be pretty good estimates, but I forgot that the g-code commands for setting those values expected per-minute velocities. The result was mesmerizing. I just sat there and admired the smoothness of motion. I took it as a sign of Duet's intelligence and forgot to check whether the character of the movements I observed had anything to do with the values I had entered. Best of all, I thought, was that none of the motion was transferring to the walls of my apartment. Surprisingly, that newfound smoothness didn't really affect the overall print time too much, so I didn't realize what I got wrong until much later.

Today I found and corrected the error, and now the machine shakes like crazy again, but it produces passable prints. Not bad for a second try. The strokes are still thinner in the middle than near the ends and there is a small ridge on the top surface where the infill meets the perimeter. Traces of ringing are visible on the sides but are not really palpable (way under 0.01mm) – which is an excellent result for a frame that is not famous for its rigidity and a print head whose total weight is approaching 1 kg.

Thank you for thinking with me. I wouldn't be making as much progress without your help.

Sorry, I was stuck in a rut and needed a fresh start and a heads-up, so thank you very much for that.

I simply overlooked the trigger height parameter. I got very close to it when I tried to print without the glass and saw the nozzle stop approximately at negative trigger height (as it turned out), but misinterpreted what I saw.

The Z homing switch is at the bottom of the axis. It is essentially the original Mendel arrangement except for X-axis hardware, which I borrowed from Hephestos. When the Z endstop triggers, the gap between the nozzle and the bed is about 0.25 mm. And then there is a 2.5-mm trigger height subtracted from that:

[c]config.g[/c]:

G31 P600 X0 Y0 Z2.5                                ; Set Z probe trigger value, offset and trigger height

[c]homeall.g[/c], [c]homez.g[/c]:

G92 Z2.5         ; set Z position to trigger height

So I adjusted the end stop to take that into account, and I am printing again. The first few tests came out ugly, but that's a different issue. I am using the previously-working Cura profile for the same filament and the same extruder drive that produced nearly perfect results with Melzi (although the hot end is now different and the nozzle is smaller). The issue now is that the accelerated motion (which is super-nice and I'm not giving it up) results in gross over-extrusion at the end of each move. I'll work on that and yell if I need help.

Thanks a lot!

I am trying to make my old Mendel (ca. 2012) work with the Duet board and all mechanical end stops (no probe). I thought it would be a drop-in replacement for the Melzi board with some added magic, but it appears that there is too much magic in the Duet and I can't figure it all out.

I have arrived at a point where it moves on command (very nicely) and homes correctly. But while printing, it seems to ignore the Z-homing result and rams the head into the bed, shutting off the extruder. I tried all the round-about ways of solving this problem; I have done everything short of looking into firmware. Raising the end stop has no effect. Adding a vertical offset in the web GUI or in g-code has no effect. Whatever I do, it starts at the correct home position, raises about 5mm, then descends to its target position on an inclined trajectory. It does not stop descending until the extruder touches the bed.

I have lowered the bed by a couple millimeters and that releaved the extruder somewhat, so it was able to push some material through but the nozzle was still sliding on the bed, just with less pressure. I forced it through the first layer, hoping to see better action as it got to the next layer, but that didn't happen. As it reached the next layer, it started scraping the previously laid material clean off the glass, completely shutting off the extruder. That looked as though it went down instead of up.

The Z motors on the Mendel go in reverse if wired in the same orientation as other motors (they are mounted on the top of the frame). Are there multiple parameters in settings that need to reflect the fact? I used https://configurator.reprapfirmware.org to compose my current configuration files and haven't touched it since.