Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Interface falls into an "disabled" state on warmup #339

Closed
imitation opened this issue Jan 6, 2014 · 11 comments

Comments

Projects
None yet
2 participants
@imitation
Copy link
Contributor

commented Jan 6, 2014

With the latest devel 260a378 , Octoprint chokes on my start.gcode. The interface goes into an "disabled" state, where all controls are disabled and the console is greyed-out. A reconnect to the printer does not fix the issue, a restart of Octoprint does.
I'm using two extruders in Marlin, one is my hotend, the other the second half of my bed.

This is my start gcode, Octoprint makes it approximately to ";Aufheizen":

;init
M80
M666
M220 S80
M221 S100
M201 Y600
M203 E40 Y150
M205 X15 E0.3
T0
;Licht
M42 P27 S255
M42 P25 S255
M42 P23 S0
M42 P17 S0
M42 P9 S0
;Temp während Home
T1
M104 S[first_layer_bed_temperature]
T0
;M104 S[first_layer_temperature]
M140 S[first_layer_bed_temperature]
;Home, Parken
G28 Z Y
G0 Z200
G28 X
G0 X20 Y10 Z2
G1 Z0.1 F200000
M400
G92Z1.9
G1 Z0.1 F200000
M84
;Aufheizen
M104 S0
M190 S118
M140 S[first_layer_bed_temperature]
M109 S[first_layer_temperature]
M190 S[first_layer_bed_temperature]
M400
M42 P17 S255
M42 P23 S255
M42 P9 S255
;Purge
G92 E0
G1 Z2 F9001
G0 X2 Y10 Z0.3 F100000
G1 E6 F150
G1 E9.5 Y50 F500
G0 Z1.5 Y5 E9.1 F200000
G92 E0
G92 E0
T1
M109 S120
T0
M333 L222 R222 A

unbenannt

@foosel

This comment has been minimized.

Copy link
Owner

commented Jan 6, 2014

Could you provide serial.log and octoprint.log? -> https://github.com/foosel/OctoPrint/wiki/How-to-file-a-bug-report

Also:

M140 S[first_layer_bed_temperature]
M109 S[first_layer_temperature]
M190 S[first_layer_bed_temperature]

I guess you copied that from the actual start.gcode definition in your slicer, not from an actual gcode file, right? If yes, if you could should an actual file my way, that would be great too.

@imitation

This comment has been minimized.

Copy link
Contributor Author

commented Jan 6, 2014

Your're right, sorry.
Octoprint.log: http://pastebin.com/9u5Nvbrp
Serial.log: http://pastebin.com/9t4xKLGL
First 500 lines of gcode, as generated by Slic3r: http://pastebin.com/efgY8XU9
Full gcode (likely not available forever): https://www.dropbox.com/s/glw5geqt6ycxa0q/speakerGrill%20%28repariert%29.gcode
I'm actually not so sure anymore when exactly it is that the interface becomes unresponsive - I hit print and the print information immediately looked funky, so i reloaded the page and got the defunct interface.

@imitation

This comment has been minimized.

Copy link
Contributor Author

commented Jan 6, 2014

Ok, this is interesting: Printing a file that was uploaded before the latest git pull works just fine. Both files have an identical startup gcode and the (defunct) file in .octoprint/uploads has apparently uploaded properly.

@imitation

This comment has been minimized.

Copy link
Contributor Author

commented Jan 6, 2014

Reuploaded the known-good gcode, and that also crashes the UI. So i think it's safe to assume that any file that is uploaded in the current state will end up failing the UI.

@foosel

This comment has been minimized.

Copy link
Owner

commented Jan 6, 2014

Currently simulating the print of your complete gcode file (uploaded via the devel version) without issues. This is a long shot but: have you tried clearing the browser cache? I've switched around so many things, and especially the format of the metadata for the gcode files has changed, so maybe some old code is getting confused here.

I guess the communication timeout messages in the serial.log are the regular long-move-things, at least judging from the preceding commands. Still haven't come around to looking further into reworking the communication layer, sorry :/

@imitation

This comment has been minimized.

Copy link
Contributor Author

commented Jan 6, 2014

Yes, the timeouts are normal, they're just the long move of the z-axis.
I tried reproducing the error in Chrome (freshly cleared), and it persists.
After removing .octoprint, the error is still there.
Even with a from-scratch clone i'm seeing the exact same behavior.

@foosel

This comment has been minimized.

Copy link
Owner

commented Jan 6, 2014

Do you see any javascript errors in Chrome? (F12 > Console)

@imitation

This comment has been minimized.

Copy link
Contributor Author

commented Jan 6, 2014

Yes.
unbenannt

foosel added a commit that referenced this issue Jan 6, 2014

@foosel

This comment has been minimized.

Copy link
Owner

commented Jan 6, 2014

The fresh config combined with a multi extruder file appears to be the trick, because OctoPrint then tries to access offset information for an extruder (T1 in your case) that isn't available and falls flat on its face. Just triggered that and see the exact same problem now that you saw. Fixed it and pushed the commit, can you confirm that it works for you too?

Now looking into the javascript error above, that's probably caused by the backend hiccuping and returning invalid data, but some more error resilience would be nice there I guess.

foosel added a commit that referenced this issue Jan 6, 2014

@foosel

This comment has been minimized.

Copy link
Owner

commented Jan 6, 2014

And should have fixed that too.

@imitation

This comment has been minimized.

Copy link
Contributor Author

commented Jan 6, 2014

Seems like that second commit did the trick. Awesome, thanks!

@imitation imitation closed this Jan 6, 2014

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
You can’t perform that action at this time.