berndjm

The correct variables for your startcode: {material_bed_temperature} {material_print_temperature} And about the heater commands Cura prepends: I can't remember exactly but it depends on some settings, this was discussed here not long ago ...

Hi Matthias, Seems like the two no-printing walls are slightly smaller than the others. Try "Shell thickness" a bit smaller than 1mm e.g. 0.9mm Or design your test object so that the 4 walls have the same thickness. Even in the layer-view? I don't think so Puuuh, this would become a very long answer. Basicly the 2.xx is a complete rewrite of the 15.xxx software with new features, more parameters to fiddle with and a new GUI. But it's still "Beta". For a newbie in 3D-printing I would suggest that you stay with the 15.xxx version and make your experiences and get become able to understand how the things and parameters work together. Regards Bernd

@ungutknut: this is not a bug - this is a feature Make sure that "Mesh Fixes" --> "Union Overlapping Volumes" is not checked

Hallo Hilko, keine direkte Hilfe, aber vielleicht probierst du es mal in diesem Forum. Dort ist man Fabrikats- und Softwaremäßig ziemlich breit aufgestellt.

As far as I remember the postprocessing plugin isn't installed automaticly in the Linux-(PPA)-Version, but you should be able to install it manualy either via Synaptic - search for "cura" - there should be "cura-extra-plugin-postprocessing" or via a Terminal with sudo apt install cura-extra-plugin-postprocessing

Don't know if it is relevant for the UM-Hardware but for some other printers, on Ubuntu it's necessary that you (the user) belong to the group "dialout" to be able to communicate via USB with the printer. Give this a try (in a terminal): sudo adduser $USER dialout

Changing the infill density during a print isn't possible as far as I know. Printig with 100% infill the whole model is surely not the option, 'cause it's a waste of material and time. But perhaps you can play with the "Shell Tickness" to force printing more shell-lines so there isn't any need for an infill in the smaller part?

Shure, you're right, "why should we have to" do such calculations when a clever software can do this automaticly. I only want to show that the 7 steps in your post are not necessary if you do a little math ...

Mmmh ... doing a little mathematics would make the life easier ;-) Assuming you have the following in your print profile: Layer Height: 0.1mm Initial Layer Height: 0.2mm No you want to Pause at Height at Layer No 10 So you have 1 x 0.2 + 9 x 0.1 = 1.1 mm No fiddling with layer numbers and so on needed ...

If you have a good-working start- and endcode in Cura I see no reason to use the start/endcode in Octoprint. The only part I use is "After printjob is cancelled" to force Octoprint sending the normal Endsequence when I cancel a printjob ...

At least in Cura 2.1.2 you could play with "Remove Overlapping Inner Wall Parts" and "Compensate Wall Overlaps" in the section "Shell" ...

Didn't realy understand your message - maybe my english is not good enough :( What is a "PR" ???

Wow - big words!!! Please tell me how I managed to work with 2.1.2 for nearly a month now on Ubuntu 16.04 using topiekars PPA ... Have you ever read the link I gave you above?!? Did you try to install the dependencies mentioned in this link: sudo apt install qml-module-qtquick-dialogs qml-module-qtquick-controls ? Have you ever made an update for this PPA?

Have a look at this thread on github, near the bottom there is a explanation what dependencies are missing ... and how to solve this.

Have seen this before, but not all (blender)files are affected, have here bunch of files here the work without problems. A quick workaround would be: open the file in old cura and save it there as .stl - then it should open fine in the new cura ...

Think your problem is the missing orientation if you rotate the whole buildplatform and you use a self-made printer profile? So there is an easy solution: Have a look at the printer-profiles shipped with cura, there is always a kind of backplate with a lettering (the key is "platform") - this is the "back side" of the printer, so asuming your Home(0,0,0) is in the front left corner.

Think this is not a software problem, looks more like a mechanical problem. What is your "Travel Speed"?

Some times I noticed that the legacy cura is a bit "bitchy" on some parts where the wall is whole-number from the nozzle size. In this cases helped me either to make the wall a tiny bit larger (e.g. 2.01mm) or "fake" the nozzle size (e.g. 0.39mm) ...

In 2.1 it's possible to place the parts as close as you want. You have just to disable Settings -> Preferences -> General -> "Ensure objects are kept apart" you can even do "funny" things then although the printpath-planing isn't very "intelligent" in this case

Just "thinking loud" about the connection to OctoPrint: A nice way would be to "hook" in the save button/dropdown something like "Send to Octoprint". The needed data (API-Key, IP-Adress ...) could be stored in a .cfg file in /profiles - like the material profiles (than with type = octoprint). If such a file (or even more) exists there will be additional entry(s) in the "Save" dropdown. Would this possible or are my thoughts to utopic or to simple-minded ...

Just played a bit with the TweakAtZ plugin. Seems that the (mis)function depends on the printerprofile and may be have something to do with the heated bed: If I use e.g. the Ultimaker 2+ profile all works fine and the changes in the gcode are present. If I use e.g. the RigidBot Profile there is the error and in the console on save I get: 2016-05-18 10:21:29,917 - ERROR - Script raised the following exception 'bedTemp'

The origin of your platform.stl should be in the center (at least in x and y) and not at the upper left corner ... right: wrong:

Is there a documentation for the printer.json files? Special which parameter goes to which section and what they affect in the different places. And what effect have the "visible", "always_visible", "active_if" settings in detail? For example: in prusa_i3.json is in "machine_settings" defined: "material_diameter": { "default": 1.75 }, in RigidBot.json is defined in "overrides" as: "material_diameter": { "default": 1.75, "visible": true },

Can't confirm this, just processed a part with 6,8 MB, 68446 vertices, 136879 faces without problems or noticable time consumption. If it didn't work for you, there must be an other reason than the file size ...

Should be ~/.local/share/cura ?!?