Extruder motor stops during print…
-
A way to test things faster could be to unplug XYZ motors from the bot, remove E motor, allow cold extrusion, tune accel and jerk up really high and increase print speed as high as you can, Or anyone with a spare board and motors. It would not prove anything if it works but if it still fails it might be a faster way to test things.
As a last resort you can swapping out the power supply and move the bot to another breaker/room that may help deduce if this is an interference issue.
When you get the error state again it might be worth attempting to sort out the true value that the motor is rotating at, maybe connect it to one of the bot axis so its easy to measure the movement.
After you test other things (like changing accel/max speed) in the error state it could be worth sending only one part of the M350 command at a time such as X Y and Z then I0 then last E16, to narrow down what really is fixing things. I wonder if the controller thinks its still at one microstepping/setting but the stepper drivers thinks it's in another.
-
unplug XYZ motors from the bot, remove E motor, allow cold extrusion, tune accel and jerk up really high and increase print speed as high as you can
good idea. doing that now.
i have requested an UPS to borrow to eliminate power line fluctuations… tech support is slow at my uni, tho, so that'll be a while.
the idea of swapping the supply out is interesting. i have a spare 24v supply from another printer, so i'll see what it will take to wire it in. i also have a big-ole variable power supply i can try, which would be simpler than re-wiring the alt-printer supply.
-
I'm glad you managed to track it down to the microstepping. Do you think it is possible that when the error occurs, it is running with x256 microstepping? That would cause extrusion to be 1/16 of the correct amount.
If the stepper motors reset themselves then the microstepping will default to x256. But that should only happen if the supply voltage drops below about 9.5V, and if that happened then an under-voltage event should show up in the M122 report.
-
how often does the system poll the voltage?
i experienced a power-related failure on my taz6 overnight (printer stopped mid-print), so now am thinking a UPS might solve this problem. argh.
-
-
Every 1ms.
with a polling interval of 1ms, it is unlikely that the log would miss a brief failure.
i got a fail on another attempt after using a spare 24v supply, so the stock supply is not to blame. nothing logged in the log file. i still don't want to rule out a local power line problem, maybe my building flickers or something. but, i think the extruder steps path is the fruitful one to go down. read on.
as suggested, i ran 350's one-by-one, and with
M350 E16 I1after the failure, it extrudes again. however, my attempts to run M350 while the printer was still printing the file were to no avail. it ignored them. it was only after I canceled the print that i was able to restore functionality. full disclosure: after canceling, the E command was the first i ran, before X|Y|Z, so i don't know if running a motion axis would have had the same effect.
M122 === Diagnostics === Used output buffers: 4 of 32 (11 max) === Platform === RepRapFirmware for Duet WiFi version 1.20 running on Duet WiFi 1.0 Board ID: 08DDM-9FAM2-LW4SD-6JKD0-3SN6N-T2ZVY Static ram used: 15448 Dynamic ram used: 99288 Recycled dynamic ram: 4048 Stack ram used: 1392 current, 8440 maximum Never used ram: 3848 Last reset 07:42:21 ago, cause: power up Last software reset at 2018-02-28 21:32, reason: User, spinning module GCodes, available RAM 11880 bytes (slot 2) Software reset code 0x0003 HFSR 0x00000000, CFSR 0x00000000, ICSR 0x0441f000, BFAR 0xe000ed38, SP 0xffffffff Error status: 0 Free file entries: 8 SD card 0 detected, interface speed: 20.0MBytes/sec SD card longest block write time: 19.4ms MCU temperature: min 37.0, current 54.7, max 57.0 Supply voltage: min 23.9, current 24.4, max 24.7, under voltage events: 0, over voltage events: 0 Driver 0: ok, SG min/max 0/1023 Driver 1: ok, SG min/max 0/1023 Driver 2: ok, SG min/max 0/1023 Driver 3: open-load-A open-load-B, SG min/max 0/1023 Driver 4: standstill, SG min/max not available Date/time: 2018-03-03 20:27:05 Cache data hit count 4294967295 Slowest main loop (seconds): 0.128808; fastest: 0.000044 === Move === MaxReps: 1436, StepErrors: 0, FreeDm: 123, MinFreeDm 120, MaxWait: 2078584986ms, Underruns: 5688, 3 Scheduled moves: 754935, completed moves: 754905 Bed compensation in use: none Bed probe heights: 0.000 0.000 0.000 0.000 0.000 === Heat === Bed heaters = 0 -1 -1 -1, chamberHeaters = -1 -1 Heater 0 is on, I-accum = 0.0 Heater 1 is on, I-accum = 0.6 === GCodes === Segments left: 1 Stack records: 2 allocated, 0 in use Movement lock held by null http is idle in state(s) 0 telnet is idle in state(s) 0 file is doing "G1 X-25.458 Y4.488 F12000" in state(s) 0 serial is idle in state(s) 0 aux is idle in state(s) 0 daemon is idle in state(s) 0 queue is idle in state(s) 0 autopause is idle in state(s) 0 Code queue is empty. Network state is running WiFi module is connected to access point Failed messages: pending 0, notready 0, noresp 0 WiFi firmware version 1.20 WiFi MAC address 2c:3a:e8:0b:20:8d WiFi Vcc 3.37, reset reason Turned on by main processor WiFi flash size 4194304, free heap 16720 WiFi IP address 10.0.1.2 WiFi signal strength -53dBm, reconnections 0, sleep mode modem HTTP sessions: 1 of 8 Socket states: 2 0 0 0 0 0 0 0 Responder states: HTTP(1) HTTP(0) HTTP(0) HTTP(0) FTP(0) Telnet(0)i conjecture that if it is an outlet problem, then if two printers running on the same circuit would more likely both experience a problem than individually. testing now. i also discovered that i have been slicing in absolute mode, so switched just to keep testing things.
-
for that voltage threshold being crossed to be logged in my file, what debug level do i need to be at? is there one in this firmware? is it possible it was emitted but ignored?
http://reprap.org/wiki/G-code#M111:_Set_Debug_Level
https://duet3d.dozuki.com/Wiki/GCode#Section_M929_Start_stop_event_logging_to_SD_cardalso, does "stall detection" mean anything to my printer? is this functional on a d300vs?
https://duet3d.dozuki.com/Wiki/Stall_detection_and_sensorless_homing
-
an update – i re-sliced tobel60 twice -- 1 w/ absolute extruder positioning, 1w/ relative, and got one success and one failure. guess which one succeeded? the relative. before, it was the relative that was failing. can safely say that the mode of extrusion is not the determining factor.
i will re-print these two files a few times, to establish a trend. if one fails consistently and the other not, hopefully we can use them to help debug.
an update on restoring extrusion after a failure -- it suffices to run
M350 E16 ```– the interpolation parameter is not necessary. i still want to know how to modify the firmware to print custom messages to the log file -- and how to compile it myself. -
I don't know if it could be done but it would be handy if we could read the set microstepping of the driver itself and not just the controller.
Could still be found by the rotation per mm extrusion and try and sort out what the microstepping is, if we know the drivers default to 256 on power up knowing its at 256 in the error state could confirm that the driver is getting reset some how. It is strange that its only on the E axis that this issue shows up on. Could some intermittent motor short cause a reset? Perhaps only after it heats up? -
Please remind me: which firmware version(s) have you used; and have you already tried:
1. Using the E1 motor output instead of the E0 motor output;
2. Replacing the Duetbecause it sounds to me like either a faulty motor driver, or a very obscure firmware bug.
-
PS - two other things that may be worth trying:
1. Ground the body of the extruder motor, in case static build up is causing arcing between the extruder motor body and the coils or connections, and that is resetting the driver chip;
2. Replace the extruder motor, in case something that the motor is doing is causing the stepper driver chip to reset.
-
i have already tried E1, another motor (thanks brad, sorry it didn't fix the problem), and another duet board. no avail, all still produced failure. currently using my wireless duet, the ethernet is in its box.
i have tried firmwares 1.18, 1.19.2, and 1.20. happy to upgrade if that's a recommendation.
i will try the grounding idea. that means the chassis of the printer must be grounded, too, eh. can you indicate how i should ground it? through the power supply? wire to a screw on the wall plug? is there a ground on the board i can tie in to? how should i attach the grounding wire to the motor? i'm not an electrical engineer, need help, please.
-
it is insufficient to run
M350 I1 ```to restore extruder functionality. running that command caused this to output:M350 I1
Microstepping - X:64, Y:64, Z:64, E:16:16(on):16:16:16:16:16:16:16 -
i have already tried E1, another motor (thanks brad, sorry it didn't fix the problem), and another duet board. no avail, all still produced failure. currently using my wireless duet, the ethernet is in its box.
i have tried firmwares 1.18, 1.19.2, and 1.20. happy to upgrade if that's a recommendation.
i will try the grounding idea. that means the chassis of the printer must be grounded, too, eh. can you indicate how i should ground it? through the power supply? wire to a screw on the wall plug? is there a ground on the board i can tie in to? how should i attach the grounding wire to the motor? i'm not an electrical engineer, need help, please.
What I do is:
1. Link the Ground terminal on the mains input end of the PSU terminals not only to mains ground but also to the V- output on the PSU terminals;
2. Connect the metal parts of the printer to mains ground/V- too.My printer has an AC mains voltage bed heater, so grounding is important for safety reasons.
The green/yellow wires are ground (standard European colours).
What I find really puzzling is that nobody else has reported any similar problems. Normally that would point to a hardware problem; but you have already changed most of the hardware.
-
What I find really puzzling is that nobody else has reported any similar problems. Normally that would point to a hardware problem; but you have already changed most of the hardware.
i know, right!?!?!?! i am baffled, too. but, i am persistent, and i will solve this problem.
thanks 2000lbs for the grounding tips. i'll get to it later in the week (maybe thurs?), and post back results after another print. i am also waiting on a loaner UPS from across campus.
-
the body of the motor is aluminum, and won't take solder. tips on how to ground the extruder motor in the face of this challenge?
-
i mechanically connected the grounding wire to the extruder motor body by stuffing the wire under the heat sink. it causes the heat sink to not connect as well, but it makes the ground connection, so oh well – i'll continue to think about how to have both at the same time. i did not yet ground the rest of the machine, the wiring is stock (as the build manual specifies).
since i grounded the extruder motor, i have had 6 successful medium-size prints (10-14 hours each), and no failures across all prints regardless of size, over about 70 hours of printing. this includes previously problematic gcode for tobel_norobust, which i have printed successfully twice now.
did the grounding solve the problem? so far, it looks like yes. but, it only takes one more failure to disqualify it as the solution. i do hope that it is the solution!
-
the body of the motor is aluminum, and won't take solder. tips on how to ground the extruder motor in the face of this challenge?
Remove one the mounting screws from the front or one of the assembly screws from the rear, and refit it with a solder tag or crimp eyelet under the head, with a wire already attached.
-
did the grounding solve the problem? so far, it looks like yes. but, it only takes one more failure to disqualify it as the solution. i do hope that it is the solution!
That is exciting i do hope that solves the issue, seems like a simple solution if that is the case.
Looks like the extruder and spool are well isolated from the frame, so it does seem logical that you could have a large static charge building up have then discharging down the stepper motor wires resetting the stepper driver. Is that a PVC pipe the spool is on? I wonder if that is helping things build up a charge. -
Is that a PVC pipe the spool is on? I wonder if that is helping things build up a charge.
i'm pretty sure it's pvc
