Posts made by ofloveandhate

OP here, posting back about 1.5 months later. since adding the grounding wire, the problem is solved. i have logged hundreds of hours of printing with no failures. thanks to everyone for their help and patience.

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

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?

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.

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.

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.

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_card

also, does "stall detection" mean anything to my printer? is this functional on a d300vs?

https://duet3d.dozuki.com/Wiki/Stall_detection_and_sensorless_homing

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 I1

after 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.

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.

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.

Well that's something, did you try and have fail any of the other settings before you got the microstepping command to fix things? I wonder what bits and flags this command bumps that would cause it to start working.

i tried many reports, G92 E0 before extruding, and various speeds of extruding. the M350 command was the first i tried that should have modified any internally stored parameters.

i think i need to know the union of the things that are set by this command (M350…), and the things that can set those things. then, i can search in the gcode file, or insert debug statements into the firmware, and re-test.

to github i go. i am so glad the firmware is written in c++, cuz i can read that.

anyone know how i can insert my own print-to-file statements into the firmware, and how i go about compiling it, so i can run my custom firmware?

@garyd9:

@ofloveandhate:

so far, no-one's tried my gcode files on a duet delta machine, so i have no information on replicability.

Not even the folks at UltiBots? That doesn't speak well for their support…

to their credit, my gcode files are long. some are 16-24 hour prints, with the error occurring anywhere in there, and not guaranteed to occur… brad has been very helpful to me so far, with a thread on the ultibots forum with > 70 posts, and several long phone calls. forum.ultibots.com/viewtopic.php?f=59&t=297

i would like someone to try my code, though… will you, dear reader? links above

update: running

M350 X64 Y64 Z64 E16 I0

```allows me to extrude
i do not know how to return it to errored state without printing another object.

tell me, what do you think of this idea: i insert this statement into my layer change gcode, and see if i can make it through a whole file? there will be gaps where the machine went error.

@Kezat – these are all good wonders. i still have the machine errored, so will try sending some gcodes to "restore" settings, see what happens.

1.

So strange, all other motors/fans/heater PIDs operate normally correct? Its only the extruder motor that stop/slows mid print yet the printer keeps on "printing" until the end of the gcode?

yep

2.

Other then a tool change or full reset have you found any other way to clear the error state? Will another print without a reset start normally i wonder

no, it's errored and nothing seems to fix it. the only way i know to get it working again is to M999 or power cycle. additional testing as you suggest it merited (re-sending machine parameters, etc). i will do that now.

3.

Also to test E movement in the error state are you heating the nozzle or enabling cold extrusion to let you test it?

A: heating it.

4.

Are you able to tell if the error is happening at truly the exact same spot in the gcode or just around the same layer/print time?

it is not the same spot every time. it varies wildly. i wish it was the same spot every time, we probably would've solved this by now, ha. repeatability / replicability is highly desirable. this is the major reason i doubt it is a firmware bug – otherwise, it would be repeatable. unless it's an intermittent problem caused by something like dynamic memory allocation, that stuff can be intermittent. so far, no-one's tried my gcode files on a duet delta machine, so i have no information on replicability.

no errors in the text log, but it did log the completion of the file. thus, i cannot trust the web interface's gcode console – things show up in the text file that don't in the web interface, when i am not connected to the machine.

no, putting in higher feedrates doesn't really make it move faster. this is hard to measure. putting in longer extrudes and higher feedrates doesn't seem to make a difference.

still in errored state:

M92
Steps/mm: X: 800.000, Y: 800.000, Z: 800.000, E: 700.000:700.000:700.000:700.000:700.000:700.000:700.000:700.000:700.000

M572
Extruder pressure advance: 0.000, 0.000, 0.000, 0.000, 0.000, 0.000, 0.000, 0.000, 0.000

M201
Accelerations: X: 1000.0, Y: 1000.0, Z: 1000.0, E: 1000.0:1000.0:1000.0:1000.0:1000.0:1000.0:1000.0:1000.0:1000.0

M203
Maximum feedrates: X: 20000.0, Y: 20000.0, Z: 8000.0, E: 20000.0:20000.0:20000.0:20000.0:20000.0:20000.0:20000.0:20000.0:20000.0