Hi, I'm trying to figure out how to disable the "travel_speed" notice for Cura. I'm using Slic3r PE, which still uses travel_speed instead of speed_travel - indeed, it will error out if you try to use speed_travel in any custom gcode. I've looked through all the settings and such, and I'm sure I'm missing something really basic...it also doesn't affect printing, it's just annoying to see every time I upload a new file.
What did you already try to solve it?
Already spent an hour or so looking through settings, paging through the posts here with no luck (but I fully admit I could just be missing it)
Additional information about your setup
OctoPrint version, OctoPi version, printer, firmware, browser, operating system, ... as much data as possible
OctoPrint 1.4.2, Octopi 0.17.0, Anycubic i3 Mega S, Firmware:
FIRMWARE_NAME:Marlin 2.0.5.3 (knutwurst, Github) MARLIN-AI3M_VERSION:1.0.6 SOURCE_CODE_URL:https://github.com/knutwurst/Marlin-2-0-x-Anycubic-i3-MEGA-S PROTOCOL_VERSION:1.0 MACHINE_TYPE:Knutwurst's Anycubic i3 MEGA EXTRUDER_COUNT:1
Using Slic3r PE 2.2.0
It doesn't matter which slicer you use, if {travel_speed} ends up unreplaced in your gcode, you need to fix that or you will run into trouble with your firmware. "Just disable the warning" is not going to solve the problem of your gcode containing garbage data.
That being said, if you still want to just disable that and other warnings because you would rather risk print failure than fix your files, disable the bundled File Check plugin.
I have tried to replace {travel_speed} with {speed_travel}, and with Slic3r PE 2.2.0 it will throw an error about the parameter being wrong, as I indicated in my original post. The only info I can find on this error points back to the FAQ page here stating:
you are either not using Cura to slice or are using {travel_speed} instead of {speed_travel} as a placeholder for the travel speed in your start/stop GCODE scripts in your slicer .
Both statements are correct. I am not using Cura and I am using {travel_speed} as follows: G1 Z+0.5 E-5 ;X-20 Y-20 F{travel_speed} ;move Z up a bit and retract filament even more
If I change this to {speed_travel}, files will no longer slice. Changing it back to {travel_speed} and files will slice and print normally.
I am using verbose gcode output for use with Octolapse, and if I'm understanding what you are saying correctly, then it is being replaced, since the only spot I'm finding the variable name is in the verbose, commented output. Eg:
Line 67643: ; travel_speed = 130
Lin 67469: ; end_gcode = ; printing object ENDGCODE\nM104 S0 ; turn off extruder\nM140 S0 ; turn off bed\nM84 ; disable motors\nM106 S0 ; fan off\nM107\nG91 ;relative positioning\nG1 E-1 F300 ;retract the filament a bit before lifting the nozzle, to release some of the pressure\nG1 Z+0.5 E-5 ;X-20 Y-20 F{travel_speed} ;move Z up a bit and retract filament even more\nG28 X0 ;Y0 ;move X/Y to min endstops, so the head is out of the way\nG1 Y180 F2000\nM84 ;steppers off\nG90\nM300 P300 S4000
It seems the actual gcode shows the correct information:
Line 67425: G1 Z+0.5 E-5 ;X-20 Y-20 F130 ;move Z up a bit and retract filament even more
Sooo....is this an issue with Octoprint? Prusaslicer? The plugin? Β―_(γ)_/Β― It's appearing in Octoprint, hence my post here, based on my reading that this change is for the Cura slicer...which again, I'm not using.
It's an issue of you using a placeholder in your slicer that isn't supported by it and hence not replaced. You need to fix that in your slicer. It probably needs something that is neither travel_speed nor speed_travel. Those are Cura placeholders.
Can confirm this issue. Here's an example gcode I made - note DO NOT print it, as the G1 X1 F{travel_speed} I added will probably break the print in some way or another. Just wanted to test
The issue is, using {travel_speed} (or other settings} in gcode scripts with verbose gcode. PrusaSlicer outputs the gcode script at the end of the file (L22437 in my code) without replacing the placeholder, as it is outputting the values of all settings. Can confirm this triggers the warning.
Aaaah, ok. That makes sense then. I'll have to find a way to somehow detect that scenario then. Thankfully I foresaw issues like that and thus the file check plugin is maintained separately from core.
