Thread Rating:
  • 0 Vote(s) - 0 Average
  • 1
  • 2
  • 3
  • 4
  • 5
Printing stops in the middle of print job
#1
This is the second time I have encountered this in the last couple weeks.

I started a long print job last night and it was successfully printing when I last checked on it. This morning I find that printing stopped in the middle of the job. Wondering what is causing this -- I am beginning to waste a lot of material and time on half-printed projects.

Here is the status of everything as I found it:
[ul][li]Printer screen says 'stopped'. [/li]
[li]Print head stopped in it's tracks. [/li]
[li]Extruder and bed are cool. [/li]
[li]OctoPrint machine state says "printing" [/li]
[li]OctoPrint terminal says Send: N117420 M105*22
Communication timeout during printing, forcing a line
[/li]
[li]No sign of a power failure or brown-out. All my clocks, etc are still set correctly.[/li]
[li]OctoPrint still indicates that the extruder and bed temps are at operating temperature [/li]
[/ul]

Da Vinci 2.0 Duo; Repetier 0.9.2Mod 1.15-01-28_1.3 ; OctoPrint 1.1.1-32-gd974ab0 (master branch)
Reply
#2
if all is cold when octoprint says it is hot, I would say watchdog reset
now about root cause of reset, I would guess usb connection lost if you did not applied the usbcore.cpp patch?
if you applied the patch ...could be a bad command due also to usb connection, does your cable has a ferrite on it?
Reply
#3
No, it is the cable that came with the printer. I will buy a shorter cable with ferrite tomorrow and try again.

Interestingly, I ran the same job again and it stopped at nearly the same point again.
Reply
#4
If same positions I see 2 posibilities:
GCODE is root cause in some way
the specific position make the wires to have short and then reset the printer
Reply
#5
Thanks Luc,
I concur. Tonight I will try with new shielded cables; will run the model through netfab and slice with an older version of Slic3r (just upgraded to 1.2.6 because it has a nice 'Upload to Octoprint' integration). Come to think of it, I have not yet had a successful print job since I started using the Slic3r 1.2.6 a few days ago. I have checked their forum [url=http://forums.reprap.org/list.php?263[/url] and did not see any related issues reported.

I do agree that there could be a short in the wiring harness, however the model I am printing is essentially a rectangular box, so the X & Y movements are very repetitive throughout the job and it is getting about 1/2 way through the Z layers before the failure (object height is approximately 3cm at time of both failures). I suppose this could point to an issue with the bed wiring harness. I'll try running a quick tall test object to see if I can reproduce a failure around the same Z height.
Reply
#6
An update:
I bypassed OctoPrint and printed directly from Repetier Host, utilizing a shorter USB cable. I had one successful print and then the next stopped similarly to the others - I found the bed and extruder in a cooled state. This eliminated OctoPrint as the cause of the issue. I have also tried different slicers and .STLs with the same result so I have eliminated GCode as the culprit.

Next, I printed from the SD card and again experienced the print stop, however this time the bed and extruder remained ON. The print head remained in the position it had been in while printing and left a burn mark in the printed piece. This eliminated the USB cable and communication errors as the cause (although I have found that ever since I have gone to Repetier Firmware, I am frequently having to reboot the printer because it is doing the "Resend {line #}" thing and the only way to get the host and printer to communicate again is to restart.

As my next steps I am going to do a re-flash of the most recent version of Repetier firmware and test again. If this fails I will have to face the fact that there is probably a wiring issue -- I plan on re-seating all connectors at the print head, axis motors and at the main board. If it is still failing I will re-flash to XYZ firmware, test, and as a last resort I will go to XYZ support (ugh).

Possible causes:
* Octoprint - eliminated by using Repetier Host
* USB cable - eliminated by swapping cables and also by printing from SD
* GCode/Slic3r - eliminated by trying different slicers
* Repetier Firmware - pending further testing, however since the same problem is not being reported by others this is doubtful.
* Wiring/hardware/board issue - pending further testing

@Luc: Question: Is there any sort of logging/debugging available in Repetier firmware? I would like to find out if Watchdog is triggering a reboot or if there is any other useful information to be had.

Any other suggestions for narrowing this down?
Reply
#7
you can disable decouple test in configuration, there is a flag for this, you can disable the watchdog in variant.cpp: uncomment disable watchdog
all log are in serial terminal so far
Reply
#8
I think I have resolved the problem.

I went to flash to the latest Repetier firmware and the flash kept failing. Finally, I went ahead and erased the board via the jumper and the subsequent install was successful. (I had been re-flashed without the board reset in the past.)

I have made several prints now and have had no unexpected print job stops; plus - my communication problems between the printer and OctoPrint seem to be resolved. I am wondering if some residual data had remained on the board due to me not resetting the board.

@Luc - Thanks again for your help and hard work on the firmware customization.
Reply
#9
I had something very similar to this yesterday, for the first time ever (that I remember). The print job stopped mid print while I was away, and when I came back the steppers were disabled (after the configured power saving timeout, I guess) and all the heaters were off despite the LCD screen still displaying the printing temperatures (@luc, I guess this could be a bug with the power save feature?). The print head was stopped in its last printing position, with a small blob of plastic extruded (not burned though). In the Repetier Host there was no error visible, just the last gcodes sent to the printer. I suppose this looks like a USB communication issue, but it's hard to tell. Certainly the printer was no longer responding and I had to reset it and reconnect to get it to work. Luckily I could resume later the failed print by using the 'start printing at height' feature of Simplify 3D Smile

If it happens again then I'll try the so called USB patch... or a new USB cable altogether.
Reply
#10
Quote:....all the heaters were off despite the LCD screen still displaying the printing temperatures ...
this looks more that printer crashed as powersave may disabled stepper but do not change temperature without affecting the LCD rendering, update on LCD is done every second reflecting sensor
so if temperature is not correct it means printer crashed - but seems strange that watchdog did not reset printer if out of control or you disabled watchdog also ?
Reply
#11
I have not disabled the watchdog... but not sure what it was supposed to do in such case? If the firmware had crashed then the watchdog might no longer be actually running, right? The LCD menus were certainly working and the LED lights turned on again when I pressed a key, so at least some of it was working as normal. I did not try things like jogging the axis, unfortunately.
Reply
#12
No watchdog is always working, but if menu is working that is explain why Watchdog is not triggered.
so no temp / stepper disbled is due to the max inactivity timer , printer was stuck for some reason waiting for commands and reached the timer limit.

Still do not get why LCD displayed wrong temperatures
Reply
#13
It has happened again today! I went to work and left it printing an updated version of the same model I was printing the other day. I could see it the webcam, happened at almost the same layer than before, and RH was not responding at all. Unable to reconnect to the printer even after rebooting the host machine. I'll see what the printer is able to do in a moment when I get home. Let me know if you want me to perform some test in particular (using the LCD menus).
Reply
#14
Mine has remained stable since my post a couple weeks ago, and I have put quite a few prints through it. When this problem was happening I had about a 50%+ failure rate. In my case I firmly believe that clearing the board (using the jumper) before reloading Repetier resolved the problem.
Reply


Forum Jump:


Users browsing this thread: 1 Guest(s)