1.3.11 update makes my printer move to origin, then do nothing on print command

Get Help
1

What is the problem?
As the title suggests, I updated my Octoprint to 1.3.11 and now it does not work with my Maker Select.
Basically what happens is I start the print job, then it moves to Origin to begin, and then it sits there doing nothing.

What did you already try to solve it?
I've tried to roll back the firmware to 1.3.10 but now that problem has followed it back to .10
I've tried safe mode, which straight up doesn't connect to the printer. Included a log about that below.

Additional information about your setup
OctoPrint version:1.3.11
OctoPi version: 0.16
printer: Maker Select v2
firmware: Not sure.

octoprint.log (93.9 KB)

I'm at a total loss. Was hoping that rolling back the update would fix it for the moment, but I need help. I love Octoprint and would love to continue using it instead of the SD card.

Any help you can provide is well appreciated. Thank you!

2

loop log.log (5.4 KB)

3

plugin_pluginmanager_console.log (35.1 KB)

4

plugin_softwareupdate_console.log (19.1 KB)

5

safemode error.log (453 Bytes)

6

Hi @Rocinante!

Have a look at this info: When I try to print something I keep getting a "format error" from the printer on a line containing "{travel_speed}"

1 Like
7

The gcode file you are trying to print has stuff in it that your printer doesn't understand. Specifically the line:

G1 Z15.0 F{travel_speed}*61

{travel_speed} should have been replaced by an integer. Most likely, this came from the start code defined in your slicer.

Tell us about the slicing software you used. Does it have built-in support for your printer or did you have to define it yourself?

8

That's what I already stated in my post...

9

Doesn't hurt to have another person confirm that.

I'm using Cura 3.5 atm, and a profile chosen originally for the WanHao Di3 which my MP Maker Select v2 is a direct clone of. Before that I was using a Prusa i3 profile that was working just fine through octoprint. I did switch to the Wanhao profile fairly recently, around the same time as I updated Octoprint. Could be related!

I'll have to check that and perhaps try the latest version of Cura.

10

Different slicers have a different syntax for "variables" in the start code that should be replaced with a value that usually will be set/changed in the GUI. Cura uses {variable}, Simplify3D uses [variable] and some others (I don't remember their names) use <variable>.

Marlin G-code doesn't like any of those :grin:

Printer profiles get passed around fairly often and moving a profile from one slicer to another requires some care to get the syntax correct in the start gcode and end gcode. Double check the start gcode and end gcode in the slicer you are using to make sure you haven't fallen victim to this.

Cura is a good slicer and Ultimaker keeps making it better and better. I think you will like 4.0 (or 4.1 if you are daring).

11

Cura was started by Europeans who have a noun + adjective grammar ordering in their native language. So at one time it was travel_speed and then got changed to speed_travel. Edit it in Cura's settings to whatever ordering it currently isn't.

The assumption here is that this is sliced with a recent version of Cura. It's possible that this file was sliced several versions ago. Just make it work, would be the advice.

1 Like
12

This has nothing to do with the setting key. When Cura was rewritten from scratch, it was decided to standardize the setting names on "category"_"setting name". This convention is not true for all settings by the way. Best is just to look them up here:
http://files.fieldofview.com/cura/Replacement_Patterns.html

13

It was the printer profile. When I use a modified Prusa i3 profile it works just fine! The Wanhao Dup i3 profile does not work when translated through Octoprint