AbeFM

Odds are you have to select "ungroup" from the menu, on your object. I've mentioned this a bunch of times, and apparently it's not a problem. Unless you download or create objects, then it's a huge problem, but not one the team seems interested in dealing with.

Sort of along his lines, the "linked materials" tells you it shares "SOME" properties, but since you don't know what they are, you are constantly getting bit in the behind by it. I suggest the pop-up is a LOT more explicit, or the settings themselves get little chain-symbols as the main print settings do, to tell you when you're altering other materials without realizing it. I couldn't GET my printer to work with PVA until I just took a PLA and changed the settings so that CURA would stop refusing it outright.

I have so many darned profiles I can't remember what they all do - they never make the changes I want. I certainly have two main ones ("CR10 Dual Ext PVA Support" and "Mk3 PLA 215C") and am very conscious of them. But changing materials AFTER choosing the profile will overwrite the retraction settings with the material's definition. The setting you get (non-explicitly) depends on the order that you chose your settings in. I would like it so that if I specify both the printer and the filament that the print will predictably use the same settings. The real issue is that retraction is set at the filament level, but while you could argue there's an *additional* retraction needed for some materials, there's a baseline retraction associated with the printer (you might want to turn it off in some cases). My Mk3 needs ~0.6mm of retraction for all materials where I use retraction. CERTAIN materials can use a little more. I would suggest the printer profile has some baseline retraction, and the materials only have a delta from that. In the meantime, I've just made two of everything: CR10_Inland / CR10_Black and copy that to Mk3_Inland / Mk3_Black so I can recognize from the color name that it matches the printer, and I change the brand so I can easily pick them off the list.

I don't think this is an important issue, but it's weird. I loaded and sliced this part, loaded a new part, sent that second part to a new build plate, sliced it, and everything looked fine. When I switched back to the first part, I got this: These look like travels, they don't leave the bed. The part shown has 89 layers, but now the slider goes to 128 layers (the height of the second part on the second build plate). The extraneous lines show up only when the layer #90 is displayed (i.e. first layer after the top of the physical part/print). Nothing interesting in the display of the first part. See attached profile. WeirdLines.curaproject.zip

I've been consistently getting issues with the filename reverting back to its previous state (unnamed, whatever the first model loaded was, etc). I'll enter the name but when it saves (unlisted on the SAVING" dialog) it will do so (and report it in the "saved as" notice, if you happen to read it. Sometimes I know I've hit the button without hitting enter first. I suspect it happens when you hit enter but then hit save too soon (within a second?). There is one caveat - I'm running two instances of CURA at one time - I have two different printers and the settings get confused going back and forth. That may be the root cause of the issue, but I never had it until 3.4b, and I feel it is related to the input checker.

This is not QUITE the thread I was talking about, which I cannot find. https://github.com/Ultimaker/Cura/issues/3875#issuecomment-398094699 It's going a little testy, so commenting should be with a light touch - but the information is solid. I've seen the same issue on basically a number of circumstances - printing on top of nothing leads to trouble.

A checkbox in options could fix that, as well as addressing the issues of those who "don't need it".

Quite often I find myself in the situation of having something to print, and as I try different settings, I quickly lose track of what I tried and what the consequences are. I've found screenshots help, but they aren't labeled. I'd like to see something like: The columns would be only things that changed between slicing, and the CASE would just be how many slices ago. A time stamp might help, as well as model name, etc... But making table after table, opening notepad, etc, is a big pain and very hard to list settings. I'm sure it could use a lot of cleaning up, and I'm hoping to start a discussion on what would be useful here. It kinda reminds me of the "g-code browser" from another popular slicer, but this would be head-and-shoulders above that functionality. You wouldn't even need to keep the g-code, just the settings and summary, and reslice when the user selects one.

There's an issue where CURA often chooses to print stuff in mid air, because there is "support" on the layer below - but it is not below where the extrusion happens. Please make an explicit call stating your interest in having top surface features printed above existing infill/support. It's been mentioned in a few other threads and the official response is that it is not a priority. I don't want to raise a stink, but if all interested people would say that they would like features-above-infill to print correctly, they may move it up their priority list. OMG! Thanks! I will be trying that.

Yes, poorly defined surfaces often trigger bizarre behavior when slicing. You can attach the STL here for others to check out, but bring it into a package that will check for and fix model errors (Win10 has 3D builder built in), see if it helps. Maybe try another orientation, too.

I'd say fully 10% of my slicing has obvious and fatal errors - entirely missing layers, spurious artifacts. Not looking at EACH sliced object before hitting print would mean fully 1/3 of my prints would go straight in the trash bin. Many models are well behaved. Perhaps a round of automated sanity checks after slicing (are there unsupported things being printed?, printing taking place outside of the printbed) that could suggest/trigger a manual review could fix this, but it seems like a larger undertaking.

Uh huh, there's other issues with file names (which aren't getting any attention, literally not ONE response so I don't even know if I'm the only person it is happening to). Ensuring the file name and the only model on the bed match seems like a good place to start. I very much support GhostKeeper's wildcard strategy. I thought it would be too big to implement compared to a single blank where you type in what you want, but hey, if you can make it happen that rocks!

At a stab it looks like you're getting both "circular" and "square" prime towers at the same time. I'd suggest turning on ALL the settings, then carefully turning them off one at a time (or thereabouts) to see if some setting can't be turned off while hidden. If that works, post what did it, perhaps they can implement the logic on the backend.

As mentioned, I was able to get the behavior to go away just my translating the object slightly along the bed. I do not feel it is *directly* the cause of the brim, or at least, not in isolation. It does need sorting. --------------------- Moving the object changes the bad slicing, but did not fix it (on this model, past models that worked). Swapping brim for raft DID fix it (15H, 150g, no unexplained travels). Setting brim to "brim on outside only" also worked. Perhaps she's right and Brimming is the issue.

Is there a chance what you're seeing is the perimeters starting on a hole, causing a bad foundation? It's a topic that was being discussed on GitHub, but kinda got shot down by the development team saying that good holes on top surfaces are not a priority. I'm hoping with a more unified voice, we can generate enough interest in the topic to get the developers interested.

I'm not sure how related this is, but I have a similar problem - I have a couple very different machines, and settings get confused between them. I have a bowden style, multi-extruder machine, and a stock Prusa Mk3 (short path/direct drive). The filament which works wonderfully at <0.6mm retract on the prusa needs 1.5-2.5 mm retract on the Creality. The issue is the carefully tuned settings are following the filament instead of the printer. I believe (though folks with more than 3 printers likely know this better than I) that the bowden set up likes an additional ~1-2 mm of retract - but the settings are following the filament not the printer - and causing failures and low quality prints. I'm not quite sure how this is useful, but I feel it is a discussion that could be fruitful if it gets some thought. So far the only solid solution is using a different competitor's software for each printer, just to keep settings from contaminating. Anything to prevent that would be VERY appreciated.

Quite likely your issue is grouping - I've mentioned this and the team says they don't care one iota. But the solution to a lot of my bad STL's I've downloaded is to right click and pick "ungroup". You can tell if this is the problem - when you load in an STL there will be an empty box bigger than the boundaries of the part. When you ungroup it, the empty space ceases to exist. It is effectively reassigning coordinates, and it seems it could be easily implemented - but if you're using Cura, then you'd better get used to doing that on your own. I hope one day the fix this - I haven't heard a good argument why you would want to leave object unslicable because they have an odd origin.

Several different models have given me this weird slicing - I'll get an unrealistic amount of time/filament (12 days for something under (100mm)^3 and kilograms of plastic), along with these lines which go off to infinity and presumably are printing something over there. Moving the object slightly on the bed fixes the issue. (300 grams/2 days after moving object by y += 5) I have never tried to print one of these when sliced like that. This has the air of an issue that will get ignored so I haven't bothered posting it, but here's hoping that this thread is intended to find issues with the beta and fix them. --------------------- Edit: Oh, the two days one was also, spurious. Playing more based on Rebecca's suggest in the next post.

After spending a bunch more time with this, it is pretty obvious - you have to hit 'return' in the filename box, and just plain wait a little bit, to get the filename to stick. Whatever the "checking" that is going on, it's ruining file names, causing me to overwrite files with the wrong name, and print quite a number of objects saved under the wrong filename. Can someone explain the logic of NOT saving under the filename displayed after someone goes through the trouble of putting one in?

I've also heard it is for limiting current draw on marginal machines. I like your explanation better. If I'm really in a rush, I hit "preheat PLA" before a print.

How could you send a badly sliced file that hasn't been sliced? Even if the screen is showing you StarWars#17 you still can't send sliced code that doesn't exist. ? Whereas I end up in Solid view all the time, slice my code, get horrible slicing like a solid inch just missing out of the middle of my part, don't see it, and print garbage. Please explain how having a solid object and a "Prepare" button would lead to bad code showing up in your printer - it easily happens the other way as I explained.

The object itself came in as invalidly defined when opened in another program. Unrelated, I think, the settings for your print didn;t come across - did you save the object, or a project (project will end in ".curaproject.3mf"). I'm wondering if your variable settings just ended up with the layers so tall they didn't print well. You can post a pic like this: You can see I have layers up to 0.3mm, perhaps yours is larger?

Is there a chance your model has some seam in it? Check the object for holes in 3D builder or something? That won't fix the problem with the slicing, but it might make your print slice well enough to move on.

Exactly this. OR, when in Layer View, if the object isn't sliced, can we have "solid"? It's just an extra step to go back and forth.

I was trying to say something like this - it's a bigger job. The printers really need to be aware of the header - and the header needs to have some sensible structure. It's kinda at the printer level, no? Suffix only makes sense when the __-fix is very long. Most of my reason for wanting to customize it is to get the length down from 5 characters. Lastly, I'd like to reiterate that the Material Choice is far and away the most important. I'd rather print with the wrong size nozzle than the wrong machine, and I'd rather print on the wrong machine than with the wrong material loaded. And I'll GLADLY debate anyone who feels otherwise. ?