Extruder motor stops during print…

ofloveandhate

i printed on E1 last night, to no avail. still failed. i am unable to connect to the printer, "due to the duet firmware". wish i had a screencap of the page – did a refresh, and now get nothing. i am unable to connect to the printer through any other means. my normal fallback of repetier host, simplify3d, and all other programs fail to connect.

i have now wasted about two kg of plastic due to this problem...

ofloveandhate

so, i swapped boards to my wifi board, with firmware 1.19.2. another failure.

i updated on the wifi to 1.20, and am reprinting now.

ofloveandhate

another failure, on my wifi, 1.20. we can safely say:

either neither of my duet boards are defective, or both are
if this is a firmware problem, it exists in 1.19.2 and 1.20

i additionally believe that

we can rule out my wiring as a problem. otherwise, when i switched E0 to E1, the extruder would not have moved without a restart. however, if my wiring is causing this fault, it should be firmware detectable… ideally

one problem i have observed is that the firmware is unable to detect if the extruder motor comes disconnected. you can unplug, and replug, no errors. should this not be observable?

ofloveandhate

is this the same problem as i am experiencing?

https://community.ultimaker.com/topic/4733-print-stops-or-fails-halfway-through/

ofloveandhate

it seemed so at first, but no, my fans work fine. that post was about heat creep, not the motor stopping.

dc42

Does extrusion stop at the same point in the print each time?

The stepper drivers on the Duet can in theory detect when a motor wire is disconnected, but in practice we found it gave false positives, so I disabled that facility. If I can find a way to filter out the false positives, I will enable it again.

ofloveandhate

another thought i had – maybe i should put a fan on the duet? is the board overheating?

https://www.duet3d.com/wiki/Connecting_and_configuring_fans

ofloveandhate

no, it is not the same point every time.

ofloveandhate

here's a snippet of what my gcode looks like:

G1 X-9.773 Y20.202 E0.0240
G1 X-8.049 Y19.083 E0.0845
G1 X-7.228 Y18.592 E0.0393
G1 X-5.829 Y17.806 E0.0660
G1 X-2.005 Y15.805 E0.1774
G1 X-1.749 Y15.664 E0.0120
G1 X-0.741 Y15.031 E0.0489
G1 X-0.182 Y14.575 E0.0297
G1 X0.225 Y14.087 E0.0261
G1 X0.746 Y12.742 E0.0593
G1 X0.847 Y12.526 E0.0098
G1 X0.864 Y12.365 E0.0066
G1 X0.745 Y10.941 E0.0588
G1 X0.342 Y9.133 E0.0761
G1 X-0.212 Y7.194 E0.0829
G1 X-1.216 Y3.878 E0.1424
G1 X-1.686 Y2.198 E0.0717
G1 X-1.997 Y1.061 E0.0484
G1 X-2.338 Y-0.306 E0.0579
G1 X-2.657 Y-1.687 E0.0582
G1 X-3.138 Y-4.143 E0.1029
G1 X-3.300 Y-5.092 E0.0396
G1 X-3.519 Y-6.570 E0.0614
G1 X-3.767 Y-8.725 E0.0892
G1 X-3.921 Y-10.510 E0.0736
G1 X-4.038 Y-12.900 E0.0984
G1 X-4.060 Y-14.016 E0.0459
G1 X-4.047 Y-16.295 E0.0937
G1 X-3.986 Y-17.935 E0.0674
G1 X-3.894 Y-19.398 E0.0602
G1 X-3.771 Y-20.858 E0.0602

so it is a sequence of short extrusion moves the whole file. no long linear extrudes, just this.

ofloveandhate

here are my four attempts at 'seepferdchen'

ofloveandhate

another thought: should i prefer absolute or relative extrusions? i have only been using relative through this whole process.

ofloveandhate

i am starting to think there is a bug in the reprap firmware, in the part that processes relative extrusion distances. i printed the same model, same supports and all settings, last night. only change was that in simplify3d, i switched to absolute extrusion.

ok, there was another difference that i should have not let happen, and that was that i printed this one without the https://www.thingiverse.com/thing:2567240 bottom corner plates.

i am re-printing the same file now. if it fails again, then we know that the relative / absolute distances had nothing to do with my problem. if it succeeds, we have stronger evidence that it is a firmware bug.

ofloveandhate

i am now convinced that there is a bug in the firmware dealing with relative extruder distances

another success with absolute extruder distances, print time was 36h 21m

video:
https://youtu.be/7BCaq2k_oJk

pic:

a little problem at the top. caused due to top layers being set to 0 for that process in simplify3d. (6 processes used total, to reduce the amount of plastic used by varying the infill %)

dc42

Most Duet users - including me - only ever use relative extrusion distances.

Did you turn off "Allow zeroing of extrusion distance" in S3D? You should do that when using relative extrusion, although AFAIK it doesn't matter if you leave it enabled.

ofloveandhate

zeroing was indeed allowed in s3d, both in my relative and absolute prints.

brad at ultibots indicated that he thinks people mostly use absolute, where you think it is relative…

i have > 70 hours of absolute distance printing with no errors now, so am growing in confidence that i was experiencing something problematic with relative. i think some stress-test kinds of gcode files are merited. i was thinking that cylindrical circles or ellipses with ever-smaller faces might be useful, and mix in the zeroing.

are there known smallest distances that the extruder should be asked to perform? i read the code in the reprap firmware, and nothing immediately jumped out at me as risking underflow or rounding error. i was however concerned in GCodes.cpp at lines 2044 or so,

const float moveArg = eMovement[0] * distanceScale;
float requestedExtrusionAmount;
if (gb.MachineState().drivesRelative)
{
  requestedExtrusionAmount = moveArg;
}
else
{
  requestedExtrusionAmount = moveArg - virtualExtruderPosition;
  virtualExtruderPosition = moveArg;
}

that in one case, the value of virtualExtruderPosition is adjusted, and not in the other. is it assumed to be always 0 if relative? where is it adjusted?

i just want to know exactly how to manifest this problem, as i am not content with absolute distances as a workaround.

garyd9

Taking a WAG based solely on the code you posted:

If doing relative extrusion, the "virtualExtruderPosition" variable is meaningless (simply because it's not needed: It's a variable only used to calculate requestedExtrusionAmount if and only if absolute extrusions.)

If relative, then the value of "E" is the amount that is extruded in this step.

If absolute, then the value of "E" (moveArg) is the amount that is extruded in this step and all the previous steps combined. So, in order to know how much THIS step extrudes (requestedExtrusionAmount), you have to subtract "all the previous steps combined" (virtualExtruderPosition) from moveArg. At that point, "all the previous steps combined" (virtualExtruderPosition) needs to be updated to reflect the added amount THIS step extrudes (requestedExtrusionAmount.)

That could be written any of the following ways, and all would be accurate:

virtualExtruderPosition = virtualExtruderPosition + requestedExtrusionAmount;

virtualExtruderPosition += requestedExtrusionAmount;

virtualExtruderPosition = moveArg; // because moveArg == (virtualExtruderPosition + requestedExtrusionAmount)

ofloveandhate

gotcha.

do you have references to any other places people have had problems with relative extrusion and zeroing on?

ofloveandhate

the drama continues.

i printed a surface called "tobel", and it failed, even with absolute extruder distances. we can rule out relative as the culprit.

added a heatbreak out of lexan, with a fan blowing directly across the duet.

the print still failed.

here is what it is supposed to look like:

i think we can rule out heat as the source of the problem. because the two prints failed at such a similar place, i am hopeful that i can develop a short gcode file that fails every time i run it. then, hopefully, someone else can also try it, and fail.

ofloveandhate

my journey continues. i have re-wired the extruder motor, used a heat shield and fan to cool the duet board, and played with various slicer settings. nothing has worked – i continue to experience failures.

is there an alternate firmware i can load on the board?

whosrdaddy

Think about it, if this was a "firmware bug", this forum would be swamped with threads similar as yours, but it isn't ;).
Having read your thread @ultibots, I think you are having ordinary nozzle jams.
You use 185 deg, which seems to me a bit on the cold side, I use 205 for my PLA prints and never had any issue.

Can you share the STL for above model? I Can do a test print if you want…

Cheers,
Kris