UltiMaker uses functional, analytical and tracking cookies. Tracking cookies enhance your experience on our website and may also collect your personal data outside of Ultimaker websites. If you agree with the use of tracking cookies, click “I agree, continue browsing”. You can withdraw your consent at any time. If you do not consent with the use of tracking cookies, click “Refuse”. You can find more information about cookies on our Privacy and Cookie Policy page.
I think there are at least 3 different issues on display here, which is part of what creates the confusion.
Like people already mentioned: Cura expects models themselves to be 'watertight'. (I think this is a reasonable requirement for anything working volumetrically, like a slicer.) This isn't really guaranteed out of the box by some modelling software. Cura will do its best nonetheless but might mess up even in seemingly simple cases when things aren't watertight. (Conversely, it might also largely succeed for what seems like a pigs breakfast of a model...)
In the initial preview visualisation of Cura (so right after slicing, as opposed to re-loading in the gcode), there is a hard to track-down bug that sometimes occurs causing the appearance of missing layers. We have had the hardest luck reproducing this, even though we very occasionally see it ourselves, and thus have had no luck fixing this. (And as a visual only thing that doesn't actually mess up prints and mostly goes away on its own, it doesn't get a ton of priority...) -- A tell-tale sign is a should-be higher layer seemingly appearing on the build-plate though!
Thirdly, there may or may not be an actual big with the slicing tolerance. (This is one of those waterbed features that's hard to balance in the sense that if you fix one thing, another is likely to regress...) Hence why it's still in experimental after all these years. (Or at least one of the things that actually has a good reason to still be in that category.)
You can (apparently) fix the first issue by exporting and reimporting in Cura, in this case at least. You can see if the 2nd thing is an issue (if it keeps happening), by reloading the already sliced .gcode in Cura -- it uses a slightly different method of visualisation then (with some info missing), but it doesn't have the bug either. The last item is 'fixed' (well, workaround'ed) by setting the slicing tolerance to middle (as said).
# Initialize camera
root = controller.getScene().getRoot()
camera = Camera("3d", root)
diagonal = self.getBuildVolume().getDiagonalSize()
if diagonal < 1: #No printer added yet. Set a default camera distance for normal-sized printers.
diagonal = 375
camera.setPosition(Vector(-80, 180, 700) * diagonal / 375)
camera.lookAt(Vector(0, 0, 0))
controller.getScene().setActiveCamera("3d")
The values fed to the `setPosition` function seem somewhat arbitrary, to create a view that would look 'dynamic' to a designer maybe.
In theory, you'd probably be able to make a plugin to set the camera to a more canonical position on start-up.
If you continue with the manual solution, alter and save the file via notepad or notepad++ instead of word, then save it over the original file.
Alternatively, you could also probably add a G29 either in a post-processing script (accessible from the plugins top bar menu in Cura), or even in the start gcode, in machine-settings (accessible via the printer/preferences).