{"action":"created","issue":{"url":"https://api.github.com/repos/prusa3d/Slic3r/issues/1345","repository_url":"https://api.github.com/repos/prusa3d/Slic3r","labels_url":"https://api.github.com/repos/prusa3d/Slic3r/issues/1345/labels{/name}","comments_url":"https://api.github.com/repos/prusa3d/Slic3r/issues/1345/comments","events_url":"https://api.github.com/repos/prusa3d/Slic3r/issues/1345/events","html_url":"https://github.com/prusa3d/Slic3r/issues/1345","id":372252881,"node_id":"MDU6SXNzdWUzNzIyNTI4ODE=","number":1345,"title":"GCODE sent to MK3/MMU2 in single extruder mode to octoprint contains problematic T? gcode","user":{"login":"ruedli","id":5008440,"node_id":"MDQ6VXNlcjUwMDg0NDA=","avatar_url":"https://avatars1.githubusercontent.com/u/5008440?v=4","gravatar_id":"","url":"https://api.github.com/users/ruedli","html_url":"https://github.com/ruedli","followers_url":"https://api.github.com/users/ruedli/followers","following_url":"https://api.github.com/users/ruedli/following{/other_user}","gists_url":"https://api.github.com/users/ruedli/gists{/gist_id}","starred_url":"https://api.github.com/users/ruedli/starred{/owner}{/repo}","subscriptions_url":"https://api.github.com/users/ruedli/subscriptions","organizations_url":"https://api.github.com/users/ruedli/orgs","repos_url":"https://api.github.com/users/ruedli/repos","events_url":"https://api.github.com/users/ruedli/events{/privacy}","received_events_url":"https://api.github.com/users/ruedli/received_events","type":"User","site_admin":false},"labels":[],"state":"closed","locked":false,"assignee":null,"assignees":[],"milestone":null,"comments":19,"created_at":"2018-10-20T21:05:53Z","updated_at":"2018-12-20T17:40:51Z","closed_at":"2018-12-13T09:27:14Z","author_association":"NONE","body":"### Version\r\n_Version of Slic3r used goes here_\r\nv1.41.0\r\n_Use `About->About Slic3r` for release versions_\r\nv1.41.0+win64\r\n_For -dev versions, use `git describe --tag` or get the hash value for the version you downloaded or `git rev-parse HEAD`_\r\nstable\r\n### Operating system type + version\r\n_What OS are you using, and state any version #s_\r\nwindows 10\r\n### Behavior\r\n* _Describe the problem_\r\n* _Steps needed to reproduce the problem_\r\n  * _If this is a command-line slicing issue, include the options used_\r\n* _Expected Results_\r\n* _Actual Results_\r\n  * _Screenshots from __*Slic3r*__ preview are preferred_\r\nAny gcode generated for the MMU in single material mode, contains a T? gcode. The standard profile in fact contains this:\r\n\r\n; select extruder\r\nT?\r\n\r\nWhereas this is fine when printing from the SD card, when such a file is send to octoprint, it cannot be used. From SD card, there is a prompt which filament to use, but when using octoprint  there is no prompt, instead it attempts to load filament from extruder 2, which fails when no filament is present.\r\n\r\nUntil the MK3 / MMU2 firmware deals with this GCODE properly, gcode T? should never be present in gcode sent to octoprint. When I manually changed the code from T? to T0, it worked, however, not enough material was extruded, so more gcodes might be to purge extra material after loading.\r\n\r\n_Is this a new feature request?_\r\n\r\nYes, until the MMU2 firmware deals with it more graciously. Allthough is is easy to fix ones you know what is causing this, I imagine many new MMU2 users with an octoprint server struggeling with this one....The numerous failing prints frustrated me...\r\n\r\n#### STL/Config (.ZIP) where problem occurs\r\n_Upload a zipped copy of an STL and your config (`File -> Export Config`)_\r\nIt is not .stl specific, the problematic gcode sits in the profile, in the tab \"printer settings\" setting: \"custom Gcode\" section \"Start G-code\", the relevant section is this (copied from Start G-code):\r\n\r\nM107\r\nM115 U3.4.0 ; tell printer latest fw version\r\nM83  ; extruder relative mode\r\nM104 S[first_layer_temperature] ; set extruder temp\r\nM140 S[first_layer_bed_temperature] ; set bed temp\r\nM190 S[first_layer_bed_temperature] ; wait for bed temp\r\nM109 S[first_layer_temperature] ; wait for extruder temp\r\nG28 W ; home all without mesh bed level\r\nG80 ; mesh bed leveling\r\n\r\nG21 ; set units to millimeters\r\n\r\n;go outside print area\r\nG1 Y-3.0 F1000.0\r\nG1 Z0.4 F1000.0\r\n; select extruder\r\nT?                                                          <===== THIS CAUSES THE PROBLEM\r\n; purge line\r\nG1 X55.0 E8.0 F2000.0\r\nG1 Z0.3 F1000.0\r\nG92 E0.0\r\n"},"comment":{"url":"https://api.github.com/repos/prusa3d/Slic3r/issues/comments/449078675","html_url":"https://github.com/prusa3d/Slic3r/issues/1345#issuecomment-449078675","issue_url":"https://api.github.com/repos/prusa3d/Slic3r/issues/1345","id":449078675,"node_id":"MDEyOklzc3VlQ29tbWVudDQ0OTA3ODY3NQ==","user":{"login":"ruedli","id":5008440,"node_id":"MDQ6VXNlcjUwMDg0NDA=","avatar_url":"https://avatars1.githubusercontent.com/u/5008440?v=4","gravatar_id":"","url":"https://api.github.com/users/ruedli","html_url":"https://github.com/ruedli","followers_url":"https://api.github.com/users/ruedli/followers","following_url":"https://api.github.com/users/ruedli/following{/other_user}","gists_url":"https://api.github.com/users/ruedli/gists{/gist_id}","starred_url":"https://api.github.com/users/ruedli/starred{/owner}{/repo}","subscriptions_url":"https://api.github.com/users/ruedli/subscriptions","organizations_url":"https://api.github.com/users/ruedli/orgs","repos_url":"https://api.github.com/users/ruedli/repos","events_url":"https://api.github.com/users/ruedli/events{/privacy}","received_events_url":"https://api.github.com/users/ruedli/received_events","type":"User","site_admin":false},"created_at":"2018-12-20T17:40:51Z","updated_at":"2018-12-20T17:40:51Z","author_association":"NONE","body":"You are welcome, please let us know after trying if it works correctly in\nyour setup after waiting with starting the print until the boot sequence is\ncompletely finished.\n\nOp do 20 dec. 2018 om 18:05 schreef Tim Gold <notifications@github.com>:\n\n> @ruedli <https://github.com/ruedli>\n> Yes I think this might be what I am experiencing. I did upgrade the mmu2\n> to 1.0.3 and I think this may have made this problem worse because with\n> this new firmware for mmu2 the homing sequence doesn't happen on boot\n> anymore. It now happens when the filament load command is sent. I haven't\n> upgraded to 3.5.1 yet. I will do that and then try your workaround. One\n> more thing to add. I just tried to start a print again probably not waiting\n> long enough after connection but this time it started using f1 but never\n> fully loaded the filament and started printing empty. I don't have the\n> sensor on so it ddidn't ense the filament missing. Anyway I do think there\n> are some bugs with this process that show up with certain circumstances.\n> Thanks for your input.\n>\n> —\n> You are receiving this because you were mentioned.\n> Reply to this email directly, view it on GitHub\n> <https://github.com/prusa3d/Slic3r/issues/1345#issuecomment-449067924>,\n> or mute the thread\n> <https://github.com/notifications/unsubscribe-auth/AExsOK7HX_cG-InC0t3zBujJMWSaHaCsks5u68NvgaJpZM4XyIg1>\n> .\n>\n\n\n-- \nRuud Rademaker\nprefered mail: ruud.rademaker@gmail.com\n"}}
{"actor":{"display_login":"ruedli"}}