StarNamer

To avoid a elephant's foot, a trick I've used in the past is to turn off "drop model to build plate" then lift the model a few millimetres and use support "touching buildplate" to lift the model away from the plate. In 5.3.1, I instead get very strange behaviour: no support is generated and the model is moved and may even be below the build plate. Here's a contrived example where I place the model several centimetres above the plate (Prepare view) and it gets and it gets generated below the plate (Preview view). Is this a bug? If not, what am I doing wrong?

I like that idea. Perhaps it's something that we should put in the first run wizard. I'd vote for that idea if you can do it. I only noticed the beta the day before the 'stable' release was available. Since the moment I ran it, I identified there was a problem, if I'd known about it before and given that you have made a fix so quickly, it would have been possible to fix it before the 'stable' release. I run Window Insider Preview and am quite ready to accept that a beta version will have the odd problem which the author would like to know about so they can fix it. Update: a setting asking if users wanted to be notified of beta releases as well as new releases would allow those of us who are happy to help improve the program (and put up with a few 'rough edges') to be notified, while people who just want to use a stable app would only get notified when it was stable.

Does that mean there's an installation setup (or at least a binary) I can download and test? Or do I have to clone the repository and build it myself? Or does it still need merging?

I've yet to get 4.7 or 4.7 Beta to load a single STL file without crashing immediately so can't comment of any of the actual feature changes. I gather this is because the config parser was changed and won't accept an equals sign in any line in the startup GCode for a printer even if it's in the comments required for OctoLapse! I hope Ultimaker have flagged this a priority to fix. At the moment, I'm still using 4.6.2 because it's stable and 4.7 obviously isn't.

Reading to the end of the comments in issue 8230, it says it's the same issue as 8249, which is that the config parser has been replaced and obviously not tested very well! I found this the moment I tried 4.7beta so how come no one else testing the beta version picked it up? In my case, I used OctoLapse which requires having comments in the startup GCode like "; layer_height = {layer_height}" and Cura 4.7 crashes because there's an equals sign in the GCode (even though it's a comment!). So I currently have a choice of using Cura 4.7 or OctoLapse! From reading the comments about the change, I gather it was done to speed up startup from 2.5 seconds to 1.2 seconds. My vote would be that this isn't important. I'm about to do a 3D print which is going to take hours and you think I care about an extra second or two to start the slicer? I'd be more impressed if the speed of the slicing could be improved. So for a simple fix, can we have a version 4.7.1 with the old config parser or setting to switch between the two until someone can mend the new one?

I run Cura on a laptop with 2 display adapters - Intel HD Graphics 4000 and Nvidia GeForce GT 730M. BY default, programs run with the 'business' graphics processor (which uses less power). To get Cura's animation to work I had to use the Nvidia control panel to explicitly use the Nvidia GPU, which is quite adequate for Cura's graphics. Depending on your PC, you may need to do the same thing.

I needed to reprint an STL I downloaded from Thingiverse last week (Hero Me Geb5 - Hero_Me_Gen5_Base_1.stl). It printed fine in 4.6.2.I had 4.7beta installed and it crashed, so I reloaded 4.6.2, which told me 4.7 was now released, so I downloaded that and installed it. It also crashes opening the same STL file. I've told CURA to send a report each time. I've currently got both 4.6.2 and 4.7 installed and 4.6.2 will load and slice this file, so the file itself is obviously not corrupted. Is anyone else having trouble with 4.7 or could it be something specific to my set up. I'm running Windows 10 Pro Insider Preview version 20197. Update: I'm using Nvidia GeForce drivers. 4.6.2 works fine and I've never had a problem with any previous version. By the way, I find it amusing that every time I open 4.6.2 it tells me "Ultimaker Cura 4.7.0 provides a better and more reliable printing experience" when my experience is that it's crashed every time I've tried to use it.

OK. The reason I was asking about this was that I wanted to change it earlier today and when I went looking for temperature settings all I could find was the value 50 when I expected to see 60. I've since set it to 70 in the Profile and tried reset to defaults (50) to confirm previous behaviour, so, of course, now it puts 50 in the GCode, which is what I'd expect. So I guess I'll never know where it was previously getting the 60 from!

Hi Nitro2k01. As I explained, I've already looked at the Material profile for Generic PLA and in that the Default Build Plate Temperature is 50 degrees. There's no setting for temperature in the Printer profile and in the overall Profile the Build Plate Temperature and the Build Plate Initial Temperature both show 50. I know I can override it in the Profile, but what I want to know is where the initial value of 60 comes from which has been put into every GCode file I've sliced for the last 6 months. Until today, I'd never changed any temperature setting in CURA so why has it been outputiing 60 and not 50. Where does the value 60 come from?

Near the beginning of every GCode file I produced with CURA is a section similar to this: ;Generated with Cura_SteamEngine 4.6.1 M140 S60 M105 M190 S60 M104 S200 M105 M109 S200 M82 ;absolute extrusion mode ; Ender 3 Custom Start G-code (The last line shows is the first line of GCode from the printer's Start GCode) The initial commands set the bed temperature to 60 and the extruder temperature to 200. But I can't find where in CURA the value of 60 is set. There's no temperature setting that I can see in the printer settings. I'm using Generic PLA, but in the Material settings the Bed Temperature is 50, not 60. In the profile, the Material setting presumably is taken by default from the Material, and is also 50. Obviously I could override the initial GCode with additional GCode in the printer start, for example, but if I want a lower temperature I'm not sure if it will wait and if I want a higher temperature I should just be able to set it at the start. So where does the value 60 get set?

I'm trying out 4.6 beta and noticed, while it was printing, that one of the Tree Supports for a model actually started in mid-air! Given the model, I assume it should have had the tree's trunk extend through an opening at the side which would have grounded it to the buildplate. Fortunately, as shown, it seems to have got away with trying to print on air! Is there a forum or somewhere for reporting issues? Unfortunately (or fortunately?), due to the slightly random nature of Tree Supports, re-slicing does not reproduce the problem.

It must be from STL as @Catevari has sliced it. If it was GCode , you could see the movements and, if the GCode is tagged correctly, CURA could color it correctly, but it couldn't be sliced.

I know the feature Tree Support is experimental, but I've been having excellent results on some models, which means I often have it turned on when I open CURA. Unfortunately, it doesn't toggle the indicator icon in the summary bar so Support shows as Off when it's actually going to generate Tree Support. Is it possible to modify the flag so that any kind of Support turns the indicator On? I would also suggest that when Tree Support and Conical Support are not experimental, it would be more convenient to select Support as a dropdown - None/Standard/Tree/Conical. In fact, if possible, it might be convenient to have it before then - None/Standard/Tree(Exp)/Conical(Exp). I know this is a minor request since the only downside is having to open the settings, turn off Tree Support and re-slice, but it would draw attention to the fact that Support was on as it does slow down the slicing process and can waste several minutes when it's known that a model won't need support. Thanks.

Having noticed that CURA 4.5 was available, I read the release notes and was interested to see what effect Spaghetti Infill had. I tried it on an STL file I happened to have (Z rod knob for Ender 3 - http://www.thingiverse.com/thing:3568572) and got a very strange preview at layer 25: The profile I was using was the default Low Quality with the following changes: Infill Density: 40% Print Speed: `130mm/s Initial Layer Speed: 40mm/s Support Placement: Touching Buildplate (but Generate Support is off) Tree Support: On Spaghetti Infill: On There doesn't seem to be anything odd about the GCode and it looks fine when loaded: Of course, when looking at the infill, it's not clear what would happen as the Cubic infill is missing several layers and would, I expect, become spaghetti! Perhaps that's what's intended? CE3_Z_Knob_apl - spaghetti error.gcode

I've noticed on serval prints with curved surfaces that a vertical line is produced (see image). It's more obvious on some models than others, but seems to be because CURA always starts the outer shell of each layer at the same point. Is there some way to tell CURA to vary the start point or some other way to reduce this effect?

Given that there's SKIRT, I suspect there may be BRIM and RAFT - I can obviously do a quick test for that but, to date, I've never needed to use either. SKIN makes sense as I can see that a 100% FILL could look exactly the same as SKIN but would be completely hidden. After I posted the question, it occurred to me that a 'travel' would simply be a move without extruding anything; thanks to @bagel-orb for confirmation. FYI, my interest was due to an article about postprocessing the GCode to speed up sections which aren't going to be seen; e.g. it doesn't matter if any inner wall suffers from ringing as long as the outer wall is clean. The article used GCode from Simplify3D and I wondered if the same thing was possible with CURA. I've also wondered if 'travels' could be improved as I've seen several of my models where the hot end is moved in a zigzag following a nearby model wall, for example a horizontal screw thread, when the printer could obviously move faster if it just moved further out a did a single move to the destination! Thanks for both replies.

I've noticed CURA inserts 'TYPE' comments into the GCode, which is presumably how it identifies line type and colorizes when reading GCode. I've so far seen types FILL, SKIN, SKIRT, SUPPORT, SUPPORT-INTERFACE, WALL-INNER and WALL-OUTER. What is the complete list and, while I can probably work out some of them, what do they correspond to? For example, is there also a BRIM type> And what does SKIN mean? Also there doesn't seem to be a comment for travel; how is this identified? Does it simply detect the lack of an Ennn parameter on a G0/G! ro does it assume all G0 are travel? Thanks

OK. The NVIDIA Control Pabel has override setting to globally default to using the NVIDIA (instead of automatically selecting) and to set specific applications. After setting Cura to use the NVIDIA GPU, Simulation View works. 2020-02-02 20:17:11,872 - DEBUG - [MainThread] UM.View.GL.OpenGL.__init__ [111]: Initialized OpenGL subsystems. 2020-02-02 20:17:11,878 - DEBUG - [MainThread] UM.View.GL.OpenGL.__init__ [112]: OpenGL Version: 4.1.0 NVIDIA 425.31 2020-02-02 20:17:11,884 - DEBUG - [MainThread] UM.View.GL.OpenGL.__init__ [113]: OpenGL Vendor: NVIDIA Corporation 2020-02-02 20:17:11,890 - DEBUG - [MainThread] UM.View.GL.OpenGL.__init__ [114]: OpenGL Renderer: GeForce GT 730M/PCIe/SSE2 2020-02-02 20:17:11,896 - DEBUG - [MainThread] UM.View.GL.OpenGL.__init__ [115]: GLSL Version: 4.0.0 Thanks for the guidance where to look for what Cura was actually using. My conclusion is that I actually disabled it when I downloaded and installed the latest compatible NVIDIA driver.

Every log entry I could find reports that it's using the Intel HD Graphics 4000 2020-02-02 19:57:05,262 - DEBUG - [MainThread] UM.View.GL.OpenGL.__init__ [111]: Initialized OpenGL subsystems. 2020-02-02 19:57:05,271 - DEBUG - [MainThread] UM.View.GL.OpenGL.__init__ [112]: OpenGL Version: 4.0.0 - Build 10.18.10.5100 2020-02-02 19:57:05,278 - DEBUG - [MainThread] UM.View.GL.OpenGL.__init__ [113]: OpenGL Vendor: Intel 2020-02-02 19:57:05,284 - DEBUG - [MainThread] UM.View.GL.OpenGL.__init__ [114]: OpenGL Renderer: Intel(R) HD Graphics 4000 2020-02-02 19:57:05,290 - DEBUG - [MainThread] UM.View.GL.OpenGL.__init__ [115]: GLSL Version: 4.0.0 However, if I run the OpenGL Extensions Viewer, it only reports on the NVIDIA GeForce GT 730M Renderer: GeForce GT 730M/PCIe/SSE2 Vendor: NVIDIA Corporation Version: 4.6.0 NVIDIA 425.31 Shading language version: 4.60 NVIDIA Max texture size: 16384 x 16384 Max vertex texture image units: 32 Max texture image units: 32 Max geometry texture units: 32 Max anisotropic filtering value: 16 Max viewport size: 16384 x 16384 Max Clip Distances: 8 Max samples: 32 GL Extensions: 372 How do I tell Cura to use it?

The notebook does in nfact have 2 graphics processors, an Intel HD Graphics 4000 which seems to actually drive the displays and an NVIDIA GeForce GT 730M which is used for rendering. As setup it also has 2 USB to DVI drivers. However, my point is that the configuration of the hardware or, as far as I am aware, the software has not changed, except for a Windows Insider Preview update, and this setup was working and displaying the simulation preview a few weeks ago, but now doesn't display it. Is there some diagnostic information available from the program to indicate why it's stopped working and what I might do to re-enable it? Alternatively, is there an option to force the mode on the assumption that the software detection of the capabilities is wrong? --------------------------------------------------------- Update: I tried disabling the Simulation View plugin and this removed the layer View slider! Re-enabling simulation view brought it back, but I am now suspicious that the installation is corrupted. I tried a complete uninstall (removing config) and reinstall, but still don't have simulation view working again.

I checked the OpenGL version using the OpenGL Extensions Viewer 6.0.8.1 from here. It reports core features up to and including version 4.6 supported; a few ARB 2015 features are unsupported. What else could be disabling the simulation player?

FYI, I tried installing the latest NVIDIA drivers (425.31) but it made no difference.

I'm a novice with using Cura. A few weeks ago, when I use Preview mode, I got the simulation player and could check exactly how a model would be printed. Recently, it's stopped showing up. I've check the setting of "Force layer view compatibility mode" which was mentioned in this thread. Since it worked a couple of weeks ago, my GPU (NVIDIA GeForce 730M) must support a suitable version of OpenGL. I am on the Windows Insider Preview program, so it's possible that's broken it. What steps should I take to re-enable it or at least identify why it's not currently working? Thanks