Jump to content

rburema

Member
  • Content Count

    37
  • Joined

  • Last visited

Community Reputation

7 Neutral

About rburema

  • Birthday 06/02/1983

Personal Information

  • Field of Work
    R&D / Exploration
  • Country
    NL
  • 3D printer
    Ultimaker 3

Recent Profile Visitors

The recent visitors block is disabled and is not being shown to other users.

  1. Yes, you just move the executable to the Cura-folder. More importantly, I reply because a contributor has decided to clean up the Windows build instructions, and we've added them to the wiki over here. (A small note is that these instructions work for VS2015 and possibly VS2019, but VS2017 has a regression that requires some extra work to get it done.)
  2. I could have sworn I saw one of the other dev's commenting on my change, but I see that hasn't happend yet: Long story short, there was a reason we started cutting it off at 3: The engine only works with (integer) microns, so x.xxx millimeter is the best precision you're going to get out of it. Anything else would just (in effect) deceive the user. Therefore, I've had to revert the change 😞 ... and this is why we usually make tickets 🙂
  3. We're aware of this issue: It happens for most printers that don't have maximum z speed explicitly defined in their profile. What happens then is that we instruct the printer to go 'as fast as possible' ... meaning light speed. This confuses a lot of printers (moving the extruder at relativistic speeds is probably not within normal operating parameters...), which then either pauze or just stop, instead of just moving at the maximum speed they're capable of. The workaround is either to explicitly specify max z speed, manually change the profile, or disable z hopping. This will be fixed in 4.2
  4. Allright, fair enough. I'll bring up the build-instruction clarity with the other dev's sometime soon.
  5. It's not _just_ to babysit you, it's also nice for future reference, if anyone else stumbles on this thread 🙂 One of the reasons I didn't recommend this route in the first place is that the migration to our new system(s) isn't fully done yet (I don;t even know if the branch is already merged ... it should be), and the documentation might be out of sync with what we currently have. What you _could_ do, I suppose, is see what we did in the docker-files and replicate that without docker? That's a whole other rabbit-hole though...
  6. Good point @burtoogle @nubnubbud Those repo's are here: https://github.com/Ultimaker/cura-build https://github.com/Ultimaker/cura-build-environment if you want to try it that way.
  7. Yeah, Cura + CuraEngine is not exactly the easiest to build. We're ramping up our efforts with C.I. as well, so eventually people (at the very least on Linux) should just be able to use cura-build / cura-build-environment. The CuraEngine file should the one. The file-size difference is maybe becasue we optimize for speed, not size? I think you might be able to unpack an AppImage, then sneak it in, then repack it. See https://superuser.com/questions/1301583/how-can-i-extract-files-from-an-appimage for inspiration.
  8. 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).
  9. @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.
  10. @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'.
  11. 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.
  12. 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.
  13. Perhaps also take a look at the 'Equalize Filament Flow' setting?
  14. 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?
  15. 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.
×
×
  • Create New...

Important Information

Welcome to the Ultimaker Community of 3D printing experts. Visit the following links to read more about our Terms of Use or our Privacy Policy. Thank you!