Posts made by Yonkiman

Excellent, thanks!

I'm sure this has been asked before, probably more than once, but I couldn't find it and the CoreXY wiki page still uses M667 S1. I'd like to upgrade from 2.01 but want to make sure I've got this right before I do. Thanks

Thanks - I'll try that the next time it happens.

@dc42 Nope - I don't even know how to upload files to the Duet without DWC.

@dc42 I don't think I had multiple http connections (though why should that be a problem - isn't one of the advantages of web-based control that I can run it on my PC and then check the print remotely on my phone?), but I initially had the USB serial port connected.

I had literally just powered up the Duet. I guess it's possible that I left a web browser open to my Duet's page somewhere from the last time I used it (about a week before this) - would that cause a problem?

@dc42 My Z sensor has more variation than my bed, so I just do a 4 point to make sure the 4 corners aren't out of whack and then I print with no bed compensation. That part's all working fine.

The problem is the non-stop repeated messages. There's no way to stop them or acknowledge them and stop them. And it's not just bed levelling - earlier this month it was a heater fault (messages continued after fault was cleared). I've had this problem with various messages ever since I started using the Duet ~2 years ago. As long as the Duet doesn't send me an error message (which is fortunately 99% of the time) there's no problem. But I thought after a few years I should figure out root cause and make it stop.

Thanks

I mentioned a specific instance of this problem a month ago. But I've had it off and on for the two years or so I've had a Duet. I just powered up my printer for the first time in a week, homed the axis, performed a 5 point bed compensation, and now I'm getting a constant stream of " Warning: Triangle interpolation: point outside all triangles!". I can't stop it. I reload the DWC web page and it keeps going.

I know it will stop if I reset the printer, but then I have to home and level again.

Is there a way to make it stop happening, or at least stop it when it does happen?

Edit:
Firmware Version: 2.02RC2(RTOS) (2018-09-07b2)
WiFi Server Version: 1.21
Web Interface Version: 1.22.3

@garyd9 That's very interesting and I do have the garbage at the end of my S3D-generated gcode.

Downloaded S3D 4.0.1 and verified that all three print time estimates are working again. Thanks!

Update: I put a new thermistor in and have printed for ~14 hours with no faults and no glitches caught on the graph. So the problem was probably the thermistor.

I did test the bad thermistor afterwards with a DMM. Couldn't find any leakage to the case, and tapping it didn't produce any visible shifts (DMM, not a scope, so hardly comprehensive). But I'm satisfied. Thanks for the support!

I actually noticed the same thing, but with Simplify3D. It used to work, and I don't think I changed any relevant settings in S3D, but layer and filament have stopped working, somewhere between firmwares 1.2x and 2.x.

@nuvag Wow - what you describe in your thread is pretty much exactly what I'm seeing (including the other jittery stuff). Thankfully no issues with my bed at this time. Did you sort out the bed glitches?

Time to replace a thermistor!

Just caught another one that didn't trigger a fault this time:

Just can't come up with a theory as to what's going on... It's probably wiring but I can't come up with a theory as to how intermittent wiring could cause this behavior...

I just had a heater fault occur and was able to capture the temperature graph:

It looks like the heater was stuck on 100% for a few seconds. The Duet was able to turn off the heater when it faulted, so it doesn't seem like a heater wire shorted to ground.

I can't see it being a thermistor/thermistor wiring error because there are no discontinuities - it looks like the thermistor was reporting the actual temp the whole time.

The only thing I can think of is that the PWM control of the heater locked up until the fault shut it down. Could there be any other cause?

And is there a way to log printer temps to a file?

I'm currently running:
Firmware Version: 2.01(RTOS) (2018-07-26b2)
WiFi Server Version: 1.21
Web Interface Version: 1.22.3

I believe I'll reflash all of it to 2.02RC2 and see if that helps. If anyone has any other theories please let me know.

OK, so in my case I'd set X and Y back to 0 in resurrect-prologue.g. I think Z would then need a relative offset to compensate for how much it was increased when the print was interrupted.

Looks doable - thanks!

After clearing a heater fault and getting everything working & printing normally, if I disconnect/reconnect DWC, I get this popup:

Per the photo above, the printer's heaters are both active and working - there's no fault.

I originally saw it inside Firefox, so to check if it was some stored state in Firefox, I disconnected, closed Firefox, and opened DWC in Microsoft Edge. I got the same erroneous message (the photo is actually from Edge). If I close the warning, everything works normally until there's another disconnect/reconnect or connection from a different browser or PC.

Firmware Name: RepRapFirmware for Duet 2 WiFi/Ethernet
Firmware Electronics: Duet WiFi 1.0 or 1.01
Firmware Version: 2.01(RTOS) (2018-07-26b2)
WiFi Server Version: 1.21
Web Interface Version: 1.21.2-dc42

In the same situation this AM - apparently I did not fix the root cause of the heater fault.

I'm in a better position because this time I backed up the resurrect file this time. I went through everything step-by-step, and I think I discovered what the problem was with my first attempt.

The 5th line in resurrect.g is G92 X111.876 Y150.826 Z29.612. So my printer was happily homed, sitting at (0,0), when this line made it think the printhead was at (112, 151). Now the resurrect function should still work if resurrect-prologue.g homes the printer (as the instructions say it should), but since mine didn't, there was a lot of painful banging.

So the only question I have now is Why does resurrect.g put G92 X111.876 Y150.826 Z29.612 right before it calls a script to home the printer? It seems unnecessary at best, potentially harmful if you're trying to restart a print that failed without losing power/position.

I had a problem trying to use M916 after a heater fault, not a power failure. The fault occurred about 9 hours into the print, and the firmware was kind enough to create a resurrect.g file. I thought resuming would be pretty easy, since the printer never actually lost power so none of the axes needed homing.

I fixed the cause of the heater fault, cleared and enabled the heater, and brought the bed and printhead temps back to 60C & 210C. I read the instructions for M916 and created a resurrect-prologue.g. Since none of the axes needed homing (and homing again could even introduce a very small error), I just put M83 ; relative extrusion in the file to keep it from being empty. I then extruded until plastic started oozing out, and entered M916.

This is when things took a turn for the worse. The printhead started banging against the X and Y home position - it was as if it thought it was in the middle of the printspace instead of at (0,0). I hit emergency stop and came here to see if I could find out what I did wrong and if it's possible to still salvage the print (looks like the answer to that is no - I didn't think to backup resurrect.g and it was overwritten when I emergency stopped.)

Does anyone have any ideas how I could have salvaged this print?

@dc42 Thanks - that should help debug.

I just had a heater fault stop my print about 18 hours into the print. It's clearly something that fails very infrequently. I've been moving/tapping wires and couplers to try to catch the temperature jumping but haven't been able to.

I was thinking that it would be great to have a test mode where the temp for a chosen heater could be sampled as fast as possible and displayed on the temp graph. That way (hopefully) I could tap/wiggle things around, and a disconnect as short as a few ms would be captured, narrowing down what part of the wiring I need to rewire.

I'm running an ~36 hour print, and overnight somehow communication was lost. An M552 S1 got the web interface talking to the firmware again, but all the Print Time estimates are gone. Filament Usage and Layer Time have been "n/a" for the last 6 hours, and File Progress has been stuck at 24h 16m 31s since I reestablished communication.

I'm going to keep trying to solve my disconnect issues, but it seems like it would be a good idea to keep all the data required for these estimates in the firmware, so the estimates can survive a disconnect or a surprise Microsoft OS update.