Pause bug about octoprint

[eric-schleicher]

2019 on version 1.3.9 having just notices i'm having this issue.

[jakeebel]

I saw an interesting reaction after resuming from a pause also.

I had paused, raised the X by 10, changed filaments, extruded 15mm, then lowered X by 10.

When I resumed the first thing that happened was a fairly decent extrusion of plastic in a blob and then it resumed and finished the print as normal.

[JimZuber]

Also noticed that this bug (line numbers not being incremented correctly) appear to occur immediately after starting a print job, but seem to resolve themselves after the first layer is done printing. Depending on the object, the retries are not obvious, but on the small gear I was printing today you get a pretty pronounced chattering during printing of the 1st layer as a result of this bug.

[foosel]

Haven't been able to reproduce this, pausing and resuming works fine here, so any additional information is appreciated.

[JimZuber]

Here is a log from yesterday at the very start of the print job. Perhaps it is something about the gcode file structure (commands, ordering, etc.) that triggers the bug. If you'd like, I could email you a small gcode file that causes the problem consistently on my printer.

Changing monitoring state from 'Opening serial port' to 'Connecting'
Send: M105
Recv: ok T:208.09 B:3.00 @:45
Changing monitoring state from 'Connecting' to 'Operational'
Send: M105
Recv: ok T:208.09 B:3.00 @:55
Send: M105
Recv: ok T:208.09 B:3.00 @:60
Send: M105
Recv: ok T:208.09 B:3.00 @:64
Send: M105
Recv: ok T:208.20 B:3.00 @:63
Send: M105
Recv: ok T:208.67 B:3.00 @:55
Send: M105
Recv: ok T:209.49 B:3.00 @:54
Changing monitoring state from 'Operational' to 'Printing'
Send: N0M110_3
Send: N1M107_4
Recv: ok
Send: N1M107_4
Send: N2G21_56
Recv: ok
Send: N4G28_55
Send: N5M92 X63.2002_110
Send: N5M92 X63.2002_110
Send: N7M92 Z2284.5477_102
Recv: Error:Line Number is not Last Line Number+1, Last Line:1

[foosel]

That would be great! Just send it to [email protected]

[JimZuber]

Next week, I am going to re-image Raspbian Wheezy onto my SD card and only install the packages critical to running OctoPrint. Right now my environment is not stable, so it is possible that there is some kind of communication problem causing these repeat line numbers. Particularly in linght of the fact that others are not seeing the same issue. Probably not worth spending time trying to isolate this problem until I can confirm it still exists once I get a most stable Linux build and give it a try.

[foosel]

Has this reared its ugly head again? I've still not been able to reproduce this.

[JimZuber]

Hi Gina,

I think that all of the problems that I was seeing, including the pause
problem, the repeat line numbers, etc were related to retry issues that you
appear to have resolved over the past couple of days. I was able to
partially mitigate the duplicate line number problem by overclocking the
Raspi. There appeared to be some bad timing chemistry between my Printrbot
jr and theRaspi that seemed to accentuate the problems I was seeing with
OctoPrint.

Separate from the problem above, I continued to have problems with the
Raspi freezing when running both mjpg-streamer and Octoprint. I isolated
the mjpg-streamer to a stand-alone Raspi and it seems to run for days
before it hangs. Tried putting Octoprint on a PC running with wheezy inside
VirtualBox to separate the Raspi from the issue, but ran into a nightmare
of Linux permission issues. Finally gave up and decided to just wait a bit
for folks more adept at Linux that I to help mature OctoPrint on the Raspi
platform. Looks like that is happening in a hurry with your good work on
the serial communication issue.

Regards,

Jim

On Mon, Mar 18, 2013 at 1:24 PM, Gina Häußge [email protected]:

Has this reared its ugly head again? I've still not been able to reproduce
this.

—
Reply to this email directly or view it on GitHubhttps://github.com//issues/50#issuecomment-15079329
.

[Lions3]

Jim, what version of the RPi are you using? I have a similar issue when running mjpg-streamer and Octoprint together. I have an original RPi from this last summer. The guys on RepRap IRC said the newer version of the RPi has been updated. Now just waiting on a new RPi to arrive so I can confirm.

˜Bill

[JimZuber]

Bill,

I have the 512K version purchased right after the first of the year. Did a
lot of research on this (lots of known causes for Raspi instability) and
tested Octoprint and mjpg-streamer running on same system as follows...

-Removed USB hub, didn't solve problem
-Went with a more robust power supply (2 amp), didn't solve problem
-Verified my class 10 SD Card was on tested list (it was),
-Tried multiple Raspi boards, didn't change symptoms
-Overclocked, didn't overclock, didn't help crashing problem
-Tested with and without video/keyboard attached, didn't make a difference
-Tested with Wifi and Ethernet, didn't make a difference.

-As noted in my earlier post, mjpg-stream running on a medium overclocked
Raspi seems to stay up for a couple of days. Even though the mjpg-Video
seem to not take much cpu horsepower, the overclocking does seem to make it
more reliable. No idea why.

Ran out of time to play with this any more, so taking a bit of a break
before I jump back in. Hopefully all the good changes Gina is making will
stabilize the code in my environment.

Jim

On Mon, Mar 18, 2013 at 3:35 PM, Lions3 [email protected] wrote:

Jim, what version of the RPi are you using? I have a similar issue when
running mjpg-streamer and Octoprint together. I have an original RPi from
this last summer. The guys on RepRap IRC said the newer version of the RPi
has been updated. Now just waiting on a new RPi to arrive so I can confirm.

˜Bill

—
Reply to this email directly or view it on GitHubhttps://github.com//issues/50#issuecomment-15086529
.

[foosel]

It looks like the Raspberry Pi still has some issues driver wise. When mine started the occasional crashing again last week (btw, the moment I got a UART data logger handy it of course doesn't happen anymore grml) I googled around and found references to this: raspberrypi/linux#40 However I have not been able to verify if that's the reason for my crash, since my Pi runs headless (and the issue hasn't reappeared with the data logger, see above).

Thinking about it I tried a simple firmware update last week (rpi-update), and haven't seen a crash since then. I of course cannot say if that actually fixed the issue or it was just luck so far... Also for the record, I have a model B rev. 2

[jakeebel]

I'm still having an issue with pausing myself. On restart it begins moving very slowly for the first few moments and then switches to a jerky motion.

It still is completing moves and extruding but in a very stilted manner and at a slower pace.

Once it makes a move to the next layer everything returns to normal.

Quick screen shot of the terminal attached.

[jakeebel]

This last time I had small layers and it didn't resume to normal operation after layer change.

[foosel]

This "slow after pausing" thing sounds suspiciously like #81 ... what are you doing when the printer is paused?

[jakeebel]

On this print all I did was pause, raise the Z-axis by 10mm in one click, changed filaments, lowered the Z-axis by 10mm in one click, and resumed.

I can test pausing and resuming without any other actions if that would be helpful.

[foosel]

It would, as my guess would be that in that case it wouldn't slow down, and therefore proof to be the same non fixable issue than #81

[NCBob]

Slow printing after a pause is part of the acceleration in the firmware. When you first unpause the printer will be very slow until it gets enough information to start calculating the acceleration look ahead and then it will run at normal speed. I've had this happen in a printer that I use the LCD control panel on and finally figured out that's what it was when I turned off acceleration and look ahead in the firmware

[foosel]

Anyone here still having an issue with pausing? Otherwise I'll consider this solved / duplicate of #81

[JimZuber]

As the person that originally posted the bug, I am happy to say that after a few months break from playing with Octoprint, I just tried the latest release and the pause functionality seems to work just fine. I'd consider this resolved.

[foosel]

Alright, closing then

[kmbecker13]

Just saw this post and i'm seeing behavior very similar to what jakeebel posted about on March 23...after hitting pause, raising z height and changing filaments - once i hit resume, the printer goes super slow at the new z-height and then finally drops down to the correct one a little while later. Is that normal?

[Salandora]

Yes thats normal.