ghostkeeper

Perhaps it's in the end g-code of your printer? What printer are you printing with?

The original SolidWorks plug-in as it stands now was made for the 2016 version. We've made a fix for the 2017 version that's about to be merged. That should coincide (approximately) with the 2.7 stable release. We won't support older versions. There is a way to do this: You create a new custom material in the Material Manager, and in the Print Settings you can fill a few (6) settings in. Then you activate that material and you create a new quality profile with your settings. It's not pretty and it's not easy to share the profiles afterwards, but it's workable. Something for you, Maht? Hiding default materials has been requested fairly often. I think we can do that. Yeah, we found that bug as well. We've classified it as a blocker for the 2.7 stable release. Our "solution" right now is to (sadly) remove the Wall Extruder setting and retain only its child settings, Outer Wall Extruder and Inner Wall Extruder.

The source code for the SolidWorks plug-in has now been made public: https://github.com/Ultimaker/CuraSolidWorksPlugin So please take a look!

Sometimes it's easier to validate the syntax with JSON lint first: https://jsonlint.com/

Some virus scanners get triggered by how Cura communicates between its front-end and its back-end. This happens via a local socket and that's sort of uncommon on Windows. Changing this to some other technique would be fairly involved though... We sign our builds, so concerned people can always check the signature to make sure the application hasn't been modified in transit (Windows and MacOS do this automatically when you open the installer/app, but for Linux we provide a separate .asc file). In my opinion, the ideal solution on Ultimaker's part is to make sure that Cura gets whitelisted with some of the major virus scanners. There's some talk about that in the office now and then, but five minutes later everyone has forgotten about it...

My name is Ruben, I'm a 26 year old software developer working at Cura. I've been at Ultimaker for 3 years. My day-to-day task consists of processing bug reports, fixing bugs and developing new features for Cura. I like to think of myself as the one guy that knows about all components of Cura: Front-end, back-end, translations, profiles, etc. Basically being very broad. Nowadays I'm not the only one any more that knows both front-end and back-end, but I'm still quite knowledgable about Cura and the go-to guy for a lot of colleagues. I'm quite an idealist when it comes to open source software, and a champion of keeping Cura open. So I'm doing the best I can to keep the process open, keep Cura usable for the whole of the 3D printing community, and involve the community. The other influence I try to exert on Cura is to make it more stable (as opposed to featuritis) through automating tests and taking care of bug fixes. Aside from work I like to play bass guitar, write subtitles for films and of course to program. I'm afraid no music of mine has been published on the internet, but you can see my subtitles online and of course my hobby programming projects, though I'm afraid that I tend to not finish most of those.

Is that repo private? Yes, good point. It must be public because we are breaking the law otherwise. However I just asked my manager and I'm not allowed to make it public, so we will apparently continue to break our license requirements and nobody is allowed to make any contributions.

Development is going on here: https://github.com/Ultimaker/CuraSolidWorksPlugin You could help by modifying the code and making pull requests, or just by testing the plug-in in various ways (when SolidWorks is open in the background, when it's not, etc) and making bug reports when stuff breaks. The past few days we've been fixing a lot of stuff for the SolidWorks plug-in. It's currently in the fix2 branch but I expect that we'll have an update for that plug-in soon.

What feature are you (in your opinion) in need of most in Cura?

If you have an Ultimaker 2 Extended, then "_2.6ex" is correct. We should give that better names...

It could be a virus scanner, I suppose?

The sprinkles are testament of our Dutch culture! Once they've been printed, put them on your bread and enjoy. They are intended. It's actually the nozzle wiping off dripped filament and purging a bit extra before starting with the prime tower. We've purposefully distributed them with the golden ratio along the inside of the prime tower in order to prevent them all from clumping together (which topples the prime tower).

Keep in mind that we moved the data in the AppData folder from %APPDATA%\Local\cura to %APPDATA%\Roaming\cura, so if you deleted stuff you'd have to delete the new location (or both). It might be worth your while to see which of the settings are wrong (if the settings are wrong). That could pinpoint the actual problem better than your current description. We can't really debug this issue for you since we don't have access to the Wanhao.

Our testers tested this and it worked fine for them. Curious, I tried updating the firmware myself using Cura 2.6. Seems to work fine here! Perhaps use a different USB cable? You can always try going back to Cura 2.5 and uploading the firmware from there.

The firmware update should be under Manage Printers, through selecting the correct machine. So it seems like you've done that correctly. That the LEDs go out is a good sign: It tries to update the firmware. You could also download the firmware here: https://github.com/Ultimaker/cura-binary-data/tree/master/cura/resources/firmware These are the files that are included with Cura. You can select the one that applies to you (I think that would be MarlinUltimaker2.hex or MarlinUltimaker2plus.hex). You can upload the hex file with something like XLoader: http://xloader.russemotto.com/ You should then select the ATMega2560 with a baud rate of 250000 (COM port depends on how many devices you attached to your computer). Cura seems to be uploading the firmware fine though, by your description. It's just that the firmware itself is broken. So it would also be broken if you download it from Github. I'm going to ask one of our testers to re-test the UM2 firmware... Thanks for the report.

From my perspective, I hesitated but ultimately decided against necro-ing this year-old thread to ask about your experiences with the technique, or to indicate that I would be working on it for the next 2 weeks. That decision was based on that Neotko already posted his experiences, and that the technique was very clear-cut and the implementation in CuraEngine would need to be very different from what he did in his Slic3r script anyway. In the end, by request, I did necro the thread, but only after the implementation was completed. I also implemented this slicer trick for the users. It was no request from higher up (the managers usually go for reliability and ease of use rather than print quality), but implemented during a period that we reserved for researching what we ourselves think would add to the quality of the application. I like making pretty prints rather than useful ones, and I thought (like Neotko) that for like-minded users this technique is very neat.

I originally called it Sanding. But we felt that someone who didn't know about this thread in the forum would have no idea of what it actually does when you call it Neosanding.

As a research project I implemented this technique in Cura under the name "Ironing". It's going to be added to the 2.7 release.

Layer height has 8 dependent settings right now. Line width settings have something similar, but a typical quality profile has 120-ish settings as provided to me from our material team, which I then optimise to 20-ish settings by putting the most common settings in higher-order profiles. But basically we need to increase those 8 dependencies to 120. It's certainly possible and you could probably interpolate the quality profiles we have right now to some extent, but it's a lot of work testing those formulas. The collision checking problem is of course removed once you enforce that there are no 2 layers that overlap in the Z direction

> Where is located the button to send gcode to Octoprint? If an Octoprint connection is found, I'd expect it to appear instead of the "Save to File" button. I don't know what configuration options it provides though.

Let me clarify a few things on this matter for you guys. Cura (15.X or 2.X) has no actual variable layer height. There's a few things that can sorta do layer heights for different parts though: The initial layer height can be separate from the rest. The infill layer height can be increased. This is actually a trick; Cura will combine multiple layers of infill together, and so it only works on multiples of the normal layer height. And only if there are enough layers of infill on top of each other so that they can be combined. Something similar is in the works for support in the 2.7 release (planning of this issue is not set in stone though). The raft air gap is also not dependent on the layer heights and can be set to anything you like. There's two major problems we are facing for variable layer height. For one, if you use variable layer heights then all of the built-in profiles in Cura become moot. Layer height is such an influential setting that if you change the layer height there's typically some 20-ish settings that should change alongside it. This can be seen when you switch profiles from Normal Quality to Draft Print or something, there's typically 20 or so settings that will change then. Ideally these settings would change automatically if the user changes the layer height (or is that ideal?) but we haven't figured out all the intricate connections and interplay between settings, so if the user changes the layer height right now, the quality will surely be less than optimal. That means that we can't enable Variable Layer Height by default. S3D solves this problem by... not having this requirement that we must guarantee good print quality for the Ultimaker printers. The second major problem is collision checking. Currently Cura will avoid going through walls as much as possible so as not to create scars on the surface of the print and reduce clogging. This is a 2D problem because we know that all parts that we can collide with are on the current layer. The rest is on lower layers. With variable layer heights, the layers become separate and so there might be some already-printed part that is 0.001mm lower than the current layer. You can collide with it if that layer is too close, so you have to consider some other layers to avoid collisions. This is a technical problem in our current architecture, which S3D did set up properly to account for this feature. It can be overcome with some refactoring, but before we think of a solution for the first problem we won't be trying to refactor the architecture to solve the second.

Could not find this in release notes of 2.5. Is it in? Yeah it is. It's a minor bugfix that wasn't even linked to any tracked issue. We don't usually put all bugfixes in the change log. But it's in the release!

We've had a problem where sending via wifi would cause some g-code to be omitted. Entire layers gone. That should be fixed for the second beta version.

Selecting a material for the UM2+ does set a lot of settings to more appropriate values for that material. It's just the temperature and retraction settings that can't be adjusted.