ahoeben

The red areas would normally indicate overhanging geometry that needs supports. In this case it looks like the surface normals are inconsistent, which breaks the visualisation of overhangs. The model likely doesn’t slice as expected because it has small holes or internal geometry. The model needs to be “repaired” before it can be sliced correctly.

Support blockers should be used to “mark” overhanging parts of a model to not receive supports underneith them. So the should ovetlap with part of the model, not with the supports.

I don't think @SpaceKnight is using a UM3 or S5.

I don't know how dissimilar the UHD 620 is from the HD 620, but my laptop has a i7-7500U which includes the HD Graphics 620 and Cura runs just fine on it (without having to set any compatibility options). I'm using driver version 21.20.16.4542. What do the logs say? %APPDATA%\cura\*.log

I think the index is just a random number to defeat any caching.

Cura does not support this.

Not as far as I know. Not even using printrun through USB, because you cannot do that on an UM3E without hardware modifications.

Did you try the steps I outlined?

The .gz file is a compressed (zipped) gcode file that your printer does not support. If you slice a file and then go to the file menu and select the “save as” option, you should be able to select gcode instead of compressed gcode. I think if you do that once, Cura should remember your choice.

My bad, I did not properly read the opening post. The reason you have to change the gcode flavor @domenick_s is that normally the bed temperature is taken care of on the printer by selecting a material there.

Go to the Printers pane of the preferences, press the Machine Settings, and enable the Heated Bed from there. Edit: see post by @Dim3nsioneer below. I did not read what printer you use.

I am working on a plugin that will let you add more settings to the Print Settings for materials on the Materials pane of the Preferences: At its simplest, it just adds the Flow setting to the Materials pane. Note that if you have a Flow values specified in a profile or in the sidebar, that value still overrides whatever you set in the material.

That functionality was removed because it did not work reliably in Cura 2.3 and newer.

Cura and CuraEngine are complex projects. You are not jumping in the deep end, you are jumping into the middle of a lake. My advice is to first get comfortable with what you can do without building all of Cura. It seems you have managed to compile the CuraEngine now. You can easily just unzip the Cura 4.1 installer, replace the CuraEngine binary with your compiled version, and run Cura from the unzipped version. In my opinion a simpler approach is to start with some frontend stuff; create a theme, develop a plugin. Even if it is not your endgoal of changing how ironing works. Feel free to ignore me and jump in the deep end, but if you ask me to help I expect you to know that you need to breath.

Just to make you feel "better", there's also that report on github I linked above. So I guess there must be more people suffering from this issue but I am not getting more reports of it (out of around 12.000 downloads of the plugin from the Marketplace).

Yes, the latest version at the time. However, that gets you a snapshot of the "master" branch which is actively being worked on so like any copy of a working document it will not remain the latest version. You use `git pull` to get the latest changes. If you don't mind me asking, what do you plan to accomplish by running Cura from source if you don't know what version control is, and don't seem to understand C++ or Python?

The gcode file is first transferred over the network in its entirety before the print is started. Once the print is started, the computer running Cura can be turned off and the reliability of the network is irrelevant.

You seem to have a snapshot of the curaengine source that does not do the conditional include that I linked to. Pull in the latest version, and DON'T build tests. I think that is the default.

See https://github.com/Ultimaker/CuraEngine/blob/27cbc13cab69c24e96f7e293985893f08410695d/src/MergeInfillLines.h#L7 The file is only included if the BUILD_TESTS compiler flag is set. I don't know where you are getting protobuf_BUILD_TESTS from.

I am fairly sure that gTest (and gMock) refer to the google testing framework: https://github.com/google/googletest The header file that is failing specifically only includes the gtest_prod.h file if you BUILD_TESTS, so your initial guess is correct. This is about that optional test.

The problem seems to be that there's a fairly big darker grey area around the edge of the buildplate, and the model does not fit inside that. This darker grey area is reserved for printing a brim or skirt. If you make your brim smaller, or your skirt closer to the model, or turn off buildplate adhesion alltogether, the model should fit just fine.

There is a lot missing in your report, making it unnecessarily hard to help you. It would help if you included a link to download a model. It would help if you said *what* slicing error you get. It would help if you added a screenshot so we could see the model hashed in two colors. It would help if you said what version of Cura that came with your printer. As is, all we can do is guess. I'm just guessing that the model may load in such an orientation that it does not fit the build volume. Try making it smaller (using the scale tool), and/or moving it around so it does fit in the build volume..

I'm working on a new plugin, lets the user add settings to the Print Settings tab for materials on the Materials pane of the preferences. At its simplest, it adds the "Flow" parameter to the list of print settings for materials. The plugin also adds Extensions -> Material Settings -> Configure Material Settings. This will open a dialog that lets you configure what settings will be available, so you can add arbitrary settings such as Z Offset and Linear Advance Factor (both requiring an additional plugin already available in the Marketplace). It may not yet work with all settings, let me know. Note that a value set in the sidebar or in a profile still overrides what is set in the material. This plugin does not intend to change that. A testing version of the plugin can be downloaded here: For Cura 4.0 and 4.1: http://files.fieldofview.com/cura/MaterialSettingsPlugin-v6.0.0-2019-06-14T14_49_58Z.curapackage For Cura 3.5 and 3.6 (untested): http://files.fieldofview.com/cura/MaterialSettingsPlugin-v5.0.0-2019-06-14T14_49_58Z.curapackage After downloading, just drop the file into a running Cura window, and restart Cura when requested.

In answer to your original question: this is a different bug, and should be reported.

Without a log, there's no way of telling. Help -> Show configuration folder. Locate cura.log, upload it somewhere and post a link.