rburema

libArcus for Cura needs to be compiled in such a way that it is compatible with python libraries (on Windows), which is what the 'Visual C libArcus and Python bindings build' heading is a guide to. libArcus for the engine is build with mingw ('MinGW libArcus build and install') I suppose you could do it all at once if you also build the engine with VS (or its command line equivalents/tools), but I haven't found time to make that work myself (yet).

@nubnubbud Yeah the linux build process is a bit easier ... As for cross compiling or CodeBlocks, I'm afraid I can't help you with that. I've always just just the OS that the build is for, and I've only used CodeBlocks once, years ago. Just remember that you'd probably still need to build libArcus twice in any case.

@nubnubbud Are you using the 64-bit version of the mingw compiler & linker? ( https://stackoverflow.com/questions/17988904/compile-64-bit-binary-with-mingw-dev-c ) If you're in VS itself you need to go to 'Manage Configurations'.

I've just committed a change to master, so the 4 decimal places (instead of 3) should be back in the release after next one as well.

The first location should be correct. I see you're building everything in 32-bit, are you sure you've also build libArcus as a 32-bit library? The error seems to indicate that this might be the reason that it's 'considered' but not actually used.

Perhaps also take a look at the 'Equalize Filament Flow' setting?

I remember what I eventually did was just start up cmake-gui for each time I had to use cmake, then manually fill in each entry I could find, press configure, repeat until no more entries showed up, then generate (you may have to do a 'show all' on the settings). This didn't always make it into the document, I see now. Could you maybe show the settings you have configured in cmake-gui?

I've never built it completely in VS, just relied on the tools. Please get rid of the 'cannot open' errors first, it just means that VS is looking in the wrong places for these files. I don't think you can rely on the other errors if those aren't fixed. ETA: For the engine, libArcus should be compiled into a static library.

Great! Thanks for reporting back. I remember going back and forth a few times between these instructions and I had to change a few things as wel (and changed the document), but I don't think I had to touch that particular makefile. But whaterver works 🙂

64-bit _systems_ are, in general*, compatible with (~= can still run) 32-bit _programs_. Mixing and matching 64- and 32-bit object code when linking isn't really possible for compiled code. I think there are separate 'VS 20XX tools' cmd-windows for both 32- and 64-bit. Rather than play ping-pong like this, it may be helpfull just to give a large part of the internal document (for building on Win) to you, so you can try it out for yourself (see attachment**). Why it's not official documentation will become clear when read ... it's in a rather rough state to say the least :-) So no guarantees, etc. etc. *) At least if we're talking about the intel-compatible chips that are in most PC's right now. **) Attachment zipped because the forum doesn't accept `.txt` files? 🙂 cura_windows_buildsteps.zip

@nubnubbud Maybe the following will help (snippet from an internal page):

We fixed at least the 'crash handler crashes when sending crash report' issue, so at the very least you'll only get one crash report (containing the actual relevant crash). If you can remember (or encounter again) some of those crashes, you could report it to the Cura github repo.

@latreides Which error does it crash with? (I assume you do at least get the stack-trace/send report window, right?)

@UMS5_VSM The plugins may (understandably) lag a bit behind the official releases, as they're released by 3rd parties. Here's the webpage of that plugin, so you may be able to contact the author. @Sassw Could you maybe add some reprocude steps and sreenshots? It'll be a lot easier to report to the cloud team that way. @latreides There a plugin that implements your suggestion: look for the 'Sidebar GUI' in plugins. Alternatively: We're looking into the UI complaints, which we hope to alleviate by making the settings (and color) pannels draggable.

Hi @alan-bc Concerning languages, translation options are available 'out of the box' from the Preferences menu (the Polish language is currently missing due to a misscommunication, but it's a pretty solid list otherwise including among others Standard and Taiwanese Chinese and Spanish, which you mentioned ... sadly, we don't seem to have Hindi). Concerning Imperial Units, while it's not exaclty what you asked for, there is a plugin that might help depening on what you need: it converts Imperial units to Metric, available in the Marketplace. edits #1 & #2: fix typo's

I suspect that last one is a different (but perhaps related) issue; we've since solved the 'tree support starts in air' problem.

We still have 'Recommended' and 'Custom'? We're aware of the feedback re: the new UI/UX, and are looking into it. However, it's likely that you'll not see much of our response to that in the next version yet, since we started working on that since before 4.0 came out, and we try to release often so what can be in any single release is often limited.

@jeb1 Regarding the wording of what is now the color scheme menu; what wording would you (or anyone else) prefer?

I know the infill patterns 'Cubic', 'Cubic Subdivision', 'Octet' and 'Quarter Cubic' all produce closed cells, so you could experiment with that, but they don't produce any horizontal layers. For that effect (the occasional horizontal wall), the easiest way I can think of is making large, flat holes in the model which have a height smaller than the layer height, so you get skin there (check to see if 'Ignore Small Z Gaps' is off first, though).

Hi @JaSe007, Perhaps it would be a good idea to put a pull-request on the github for this: https://github.com/Ultimaker/Cura It might be a while before it's pulled in though, there is still a bit of a backlog. cheers, Remco.

If you 'Save' a project to .3MF (as opposed to 'Export'), the print-settings used should be saved to that project file. So if you open that model again, the settings used when the save was made will be reloaded. Unless you choose otherwise in the menu that should pop-up; to load the settings, choose 'Open as Project' when asked, 'Import Models' will of course load the model only. After that you may need to choose 'Update existing' in the next menu, depending on if the printer used in that file was already in your list.

How much of an increase are we talking about here? Release 15.04 has been a while ago, there are many potential explanations, depending on the situation, but they come down to a few reasons: a) The default values of settings may have changed. (Some settings may not even have existed in the form they are in 3.5 during 15.04.) b) Bug fixes and other quality improvements, (and/or things like "we can only (soft) guarantee that 'bad thing X' doesn't happen if we slow down a bit") can also be the cause of increased printing time.

Hi @printer3008, The inability to load from external drives is a regression, and will be fixed in the next revision-release.

@Jan_Hirt Thank you. While the file you send to me does load for me (also Win10x64), the comment you made about 'loading directly from the internet' made me think that this (and perhaps the others' as well) might be related to an issue that we're seeing where .stl files loaded from USB or other sorts of external-type disks cause problems. (Since 'loading from Firefox' and the like will almost always store the file in a local temporary folder.) Is this the case? If so, we hope to get the fix in for 3.5.1. Also, in that case, a workaround would be to store the .stl on a non-external disk. Please let us know if this 'fixes' the issue!

We unfortunately can't do much if we can't reproduce the issue: What operating system are all of you on? Please send us at least one of the .stl files it's happening with.