ahoeben

Please read the last paragraph of my opening post. I have a version of OctoPrint Connection approved and ready to be published through the MarketPlace, but it requires Ultimaker Cura 4.0 beta 2. The second beta is not yet out. It was supposed to come out mid-januari, then last week. It may come out today or tomorrow. The Cura team is working hard on it. When the second beta of Cura 4.0 is out, the plugin should follow shortly.

I am the developer of the Z Offset plugin. @Das_Sams, thanks for the feedback about my plugin. What is your start gcode? Does it include a G92 command?

No, there is not. At least, not without changing the code.

They don't. "Support blockers" are not subtracted from support structures, but they mark areas of normal meshes that should not be supported. CuraEngine looks at all the polygons of your normal meshes and decides if they need support or not. If an area overlaps with a "Support blocker" (internally named "anti_overhang_mesh"), the overhang/orientation of that area is ignored and support is not created.

Could you post your cura.cfg somewhere and share a link to it? It can be found via Help->Show configuration folder.

Note that if you run into any problems with that build, be very sure to mention you are using one of @smartavionics private builds. They contain features that are not yet part of Ultimaker builds, and some of these features may not come to the official builds. Some official features will be half-baked. This build can also contain bugs that will not surface in official builds. There may be issues with plugins, and even with upgrades to future versions of Cura. I love the @smartavionics builds for what they are and do, but you should be aware that they come with certain caveats.

For details on the bug. see https://github.com/Ultimaker/Cura/issues/5156 Turns out the fix may already be in Cura 4 beta 1

Well, one could use support blockers to remove the support for the top hole. Arguably that probably prints ok without support.

Because of a bug. Cura is extending the support that is needed on the top of the model all the way down to the buildplate, disregarding the fact that it intersects with the model. I've read that this has been "mostly fixed" (whatever that means) for Cura 4.0 (but not yet in Cura 4.0 beta 1). Edit: support blockers will not fix this.

@marcottt:

Isn't the general 3d pen recommendation "don't do it" ?

Note that though @gr5 is a gr8 moderator here, he has no such power on the github queue. Only you or Cura developers can close your issue on the github issue queue.

That's a bug that has been fixed for Cura 4.0 (https://github.com/Ultimaker/Uranium/commit/b58ce0caa494fc8c798d869a612f12e259b91eb7#diff-e85a1a432b40396c54ca875559096df3)

They are likely all connected to a small computer each (think like a Raspberry Pi). Each individual small computer communicates with a cloud-server. You can control all printers through the cloud service.

I guess it is to prevent creating lots of small "islands" of support on some prints. Since PVA does not stick very well to PLA, these would have a larger chance of tipping over. And it should not do much harm because it will dissolve anyway.

It is more likely that your GPU supports OpenGl 2.0 (which is the minimum for Cura to run) but not OpenGL 4.1, which is required for the features you mention.

I would not worry about the thickness of the glass, but warping of the glass and the (alu) part that holds the glass. But since you tested and meassured, I guess you know what works for your printer.

The setting is called "Support Horizontal Expansion".

There’s a plugin for that. It should be available in the marketplace shortly after the launch of Cura 4 beta 2. See the link in the first post of this page.

I don't have an Alta, so I cannot help you with that part. I just have a piece of advice: printing flexible materials is harder than printing PLA. First get comfortable with PLA printing. Or, in the words of mr Miyagi:

Let me just give you one last reason not to do leveling and heating things up at the same time. Things expand when they get hotter. Not by an enormous lot, but they expand anyway. The nozzle will likely be slightly taller when hot, and your bed will probably warp ever so slightly differently when it is hot compared to when it is cold. If the top-left of your leveling procedure is done with a cold extruder and bed, and the bottom-right with a hot extruder, your leveling data will be skewed. The distortion may be smaller than the precision of your printer, or the convenience of a faster print start may outweigh the imprecision. This is up to you to decide.

While I generally agree with your argument against using USB, this is not quite true: It is true that "bits can go lost" in the communication between the host and the arduino (especially with cheap, long cables), and this *would* lead to "Amazingly bad gcodes", if the printer firmware didn't detect these faulty bits and didn't ask for the faulty gcode lines to be resent. If a lot of gcode lines end up being resent, this slows down communication, leading to stuttering prints. I do wholeheartedly agree with the advice to get a Raspberry Pi to run OctoPrint, though you also need to invest in a good power supply for it.

And in case you are wondering if there are more variables, there are (lots of them): http://files.fieldofview.com/cura/Replacement_Patterns.html

No, not quite. M280 P0 S160 ; BLTouch alarm release G4 P100 ; delay for BLTouch G28 ; home G29 ; auto bed leveling M140 S{material_bed_temperature} ; start heating the bed to what is set in Cura M104 S{material_print_temperature} T0 ; start heating T0 to what is set in Cura Feel free to change the order, but the idea is that the {material_bed_temperature} (as is, including curly brackets) gets replaced by Cura.

Cura looks for neither M109 or M104, it looks for the text {material_print_temperature} (including curly braces)