ahoeben

> Use {speed_travel} in your start gcode instead of {travel_speed} {travel_speed} does not work with newer Cura versions. {speed_travel} does.

What GPU do you use? Can you update its drivers?

Use {speed_travel} in your start gcode instead of {travel_speed}

If you clear the start gcode script in Machine Settings, Cura will NOT default to a sane start script. It will just NOT use and start gcode, with the exception of a preheating sequence that is always added if Cura does not see you adding your own preheating in the start gcode script. So there will be no homing, no leveling, nothing. There currently is no easy way to restore the default start gcode snippet once you have modified it. Some day I will get round to adding a "revert" control.

Yes

Don't load the file into Cura, but instead Import it from the Profiles pane of the preferences.

Since this keeps coming back every so often, I made a quick and dirty html page that parses fdmprinter.def.json and fdmextruder.def.json and spits out a list: http://files.fieldofview.com/cura/Replacement_Patterns.html Source here: https://gist.github.com/fieldOfView/03636e14a1889d73b331cab2c3e06040#file-replacement_patterns-html Edit: yes, the list is quite long.

I have too much going on to go hunt for your code in other topics, sorry. Please have a look at cura.log in your configuration folder. It will tell you if there's a (Pyhton-)error in your code. The file is probably fairly large. You can delete it and Cura will create a new one. Then start Cura and the log will tell you what is going wrong. Specifically the bit " -> List[PrinterOutputDevice] " is called "type hinting"; it tells Python what sort of data to expect. It is optional (but recommended). It could be that Python is having an issue understanding what "PrinterOutputDevice" is; are you importing it? from cura.PrinterOutputDevice import PrinterOutputDevice

There currently isn’t a more readable version of fdmprinter.def.json

Without the rest of the code or an understanding of what your plugin does, there is no way we can tell you if that code is required.

Next time if this happens, please check if restarting Cura works to get the state right. If it doesn’t, that means OctoPrint is still telling Cura it is not ready.

Does the AppImage have a Toolbox menu? In 3.4, the plugin browser was renamed to Toolbox. The curaplugin file should be compatible with Cura 3.3 (the PPA), but you are using it in the wrong way. Remove it from the local/share/cura/plugins folder, and instead drag and drop it in the Cuar window. It will then be extracted to the correct folder. Note that this will not work with Cura 3.4, because that requires a .curapackage file. Finally, realise that freeCAD needs to be installed as well as the plugin.

Please follow the link provided by @ghostkeeper above

You would have to manually splice together multiple gcode files. What do you want to achieve?

Nog een optie: via OctoPrint. Maar als het via een usb snoertje gaat (via pronterface, via Cura, via repetier host of via OctoPrint), dan moet je de “Marlin” smaak gebruiken.

Printen via USB wordt eigenlijk niet ondersteund voor de UM2+. Mag ik vragen waarom je dat wilt doen? Als je computer halverwege een print beslist iets raars te willen doen (windows updates installeren, ik noem maar wat), dan gaat je print verloren. Mocht je het toch willen doen, dan moet je in de “Machine Settings” de G-code flavor op “Marlin” zetten ipv “Ultimaker 2”.

Worth it? It is a few mouseclicks and a restart of Cura. I don’t know how valuable half a minute is for you ? With Cura, supports are created while slicing, by what is called CuraEngine. This separate application runs in the background, and receives models and slicing settings from the main application. It returns gcode and layerdata, but it does not say much in specific about the supports it has created. That makes removing parts of generated support iteratively harder than it may be in other slicers, where gui and slicer may be more integrated.

Try it, and you'll know. It is pretty much the same as the Support Blocker, in that it lets you add "cubes" to the model. But these cubes are printed as support. It shares all the quirks of placing Support Blocker cubes. On small parts it is also easy to end up with support material on top of the model (where it will not do any good).

I'm not sure, but aren't you confusing setting_verion and version? VersionUpgrade32to33 sets the version to 6. Either way, that should not result in a crash after the license agreement window showing up, and if it did it would show in the logs. As is, the logs don't show the actual crash, which suggests to me that the crash happens "outside of" Cura. A common culprit in that sort of crashes is the GPU driver. @crash007, you specify a driver version, but not what Intel GPU you have (HD Graphics refers to a family of GPUs). Have you tried updating the Intel driver?

There's a log in C:\Users\[you]\AppData\Roaming\Cura\3.4.1. Please upload it somewhere and post a link here.

Note that the gcode snippet you quoted only works if you install this plugin: https://github.com/fieldOfView/LinearAdvanceSettingPlugin

Make sure your startgcode contains the literal strings “{material_print_temperature}” and “{material_bed_temperature}”, even if it is in a comment. Cura will see this as a preheating sequence, and won’t add one of its own.

What distribution of Cura do you use? The PPA? Note that that is not supported by Ultimaker. Have you tried the AppImage?

I have no idea how that could happen (PostProcessing too? That plugin ships with Cura!). @ianpaschal?

What remains grey exactly? Please be a little more descriptive so I can help.