Jump to content

nubnubbud

Dormant
  • Posts

    42
  • Joined

  • Last visited

Everything posted by nubnubbud

  1. no, I only copied and pasted ironing moves from different files to make a frankenfile. I edit the part, and export it once for every layer, each time one layer higher, then take the ironing moves from the last layer in each file and paste it at the end of the corresponding layer in the full print. that's why they're cubes. if it's a tower, the ironing moves will be the same every layer! (hence the ignored corners being cloudy all the way up) I set it to relative, letting me put a flag at the end of each layer so I could just replace the flag with the same ironing gcode each layer using a script. It was still inaccurate, but after about a minute of sanding, I got those parts in the images above. any tower shaped object works like this, but the relative extrusion mode is a bit inaccurate at times, or more likely, the inaccuracies build up over time. this is why I'm pretty sure it would work. I was literally using Cura's own ironing algorithm on every layer for my tests.
  2. thanks again for the help, and expect a thing here and there from me from now on!~
  3. glad to hear! yeah, my first foray into it was my friend vetting some clothing choices to me, and realizing how much I took full color vision for granted. Since he's also using this, I'm glad there's a decent chance this'll get accepted. it's currently up to date with the master, but so long as the main themes don't change it'll stay that way. As a visual effects artist, the whole "how things look for other people/first time viewers/users" is my home field, so if there are any changes it needs, I'll gladly take suggestions.
  4. Alright, got my first fork made! it's a simple one- a theme to help out people affected by colorblindness. I noticed everything was red next to green, or blue next to yellow, a bit of a pain for people with more serious color-blindness. I asked one of my friends (I swear color blindness is way more common among tech workers somehow) and he said he generally has a bit of trouble with the greens and yellows being really bright and always next to each other. -so I made a theme that works for the two most common kinds of colorblindness (Deuteranopia and Protanopia), and works as well as I could make it for Tritanopia (because each one is missing a primary color, one of them had to use alternating shades and hues of the same color for them all to at least work). I also duplicated it so there's be one to match ultimaker light and one to match ultimaker dark. The colors are a little wonky looking, mostly orange, yellow, purple and turquoise, but it's not meant for me, so the jury's still out on aesthetics. In any case I'm hoping this is worth a pull request-worst case scenario, it's rejected/ignored I guess. I'll wait a day to see if you guys tackle me in case I'm being dumb, cause I'm not sure if it's okay to just submit a pull request out of the blue for a feature not often asked for. Then again, where does that put iron every layer?~ you can check it out here, though unless you're colorblind or have colorblindness simulation software, it's not really visible how useful it can be: https://github.com/nubnubbud/Cura Or if you just wanna slap them in your themes folder use these. I think it should work. JSON's nice like that. https://github.com/nubnubbud/cura-themes
  5. well, it would be the same as ironing, hopefully. here's what ironing does: moves the printhead in a pattern over the entirety of the prints upper surface. this means it will not go back and forth over the air unless there's a disconnected part. the pattern can be changed, but it's usually concentric or zig-zag. the movements must make the flat part of the printhead move over every surface at least once. this means for a .4mm nozzle, for example, it must be treated as if it was a .1 to .2 mm nozzle to make enough lines close together printhead must be able to move to the very edge usually much slower than the original layer, (10-20mm/s) if the top surface is zigzag or lines, iron perpendicular to it. extrudes a tiny amount. (usually expressed as a percent, like 10% normal line flow) this helps it fill in and even out the surface, partially annealing and filling gaps that would normally cause bubbles and fracture points Ironing is already enabled in Cura, just load in a calibration cube and see what it does to the topmost layer. you'll see it even without travels enabled because it renders the tiny extrusions made to fill gaps
  6. the entire reason I wanted to do both is because I'm under the impression you need to edit both the frontend "Cura" and engine to add a new setting like ironing (or an option of said setting). feel free to correct me if I'm wrong though. any information is like gold to me. I'll probably learn as I poke around more, though. and I've gotten compiling the engine to a science, without a single issue, now that the little hiccup with the protobuf tests is out of the way. (id does work with both vs 2015 and 2019, and there's no noticeable downside to having a current sip version) and yeah I know I got a little butthurt earlier, but you're right. as for the frontend stuff, it looks like I need opengl2 or better, virtualbox doesn't support it though...so it'll be a day or two while I clean up my own computer till cmake and nmake are functional again. (edit never mind turns out vbox has its own implementation of gl)
  7. I plan to accomplish the act of getting better at C++, Python, and version control, as well as contribute the tasks I have set for myself when I've done it. What I'm lacking is the syntax, mainly, but I do sit down with my friends and help them debug their code and work on solutions, because while syntax isn't my forte, I'm relatively strong at use cases and roughly what background processes are needed to produce a certain qualitative result. I have taken some classes but sadly they've all focused on the code itself, and even several courses in no one formally introduced us to collaborative work or anything beyond basic compiling in an IDE, or even working with dependencies, so here I am, pursuing it solo, because I learn far better from doing than any other way. There are features that I want, and being in the industry of VFX myself, at some point I'll probably need to know scripting, build workflows, and such to develop tools anyway. I won't (and can't!) force you to help me, and I know by this point it could be considered meddling, because I've actually impacted the work of others, but this is the same as jumping in some water to learn to swim, but I stand to help other people and advance general FDM technique if I'm successful. It's also why I had the angle, earlier, that better build directions could result in more rapid development/interest. I got these issues repeatedly by following the build guide exactly on a clean install of windows, so I had reason to doubt this most recent error was my own ineptitude for once. I had an entire day of the same issue. I didn't bother pulling because I was doing it from scratch and cloning everything about once an hour. I stopped trying to go to sleep at 4AM, which ended up being about the same hour the commit you mentioned happened, hence my surprise when it suddenly worked today!
  8. I did this, as the build guide said: git clone https://github.com/Ultimaker/CuraEngine.git C:/dev/CuraEngine so it should have gotten me the latest version, right? if this isn't the most up to date version, what is? (edit: I tried it with curaengine-master and it worked! this does mean that the provided curaengine from the guide is defunct as a build source though.) now I just have to figure out how to run it, seeing as python app_cura.py throws errors about sip and UM
  9. I'm probably getting it from here, the header file that cmake produced. it's trying to include this because there's no if statement. I removed the include line, and that just made it ask for a bunch of "friend tests" so I can't just do that... it has to be generated correctly. is the easiest workaround just to enable tests? or could it be that mentioning them at all is tripping the flag? (edit- ah, I see what you mean now. I don't know where it's coming from either. This happened while I was using VS 2019, but I thought it was just because that version wasn't the recommended one, so I started from scratch and just followed the directions closely, copying and pasting all the commands just in case. It might be nice to see if someone else gets the same result, but I understand that's a lot of work just to troubleshoot this with me =3=)
  10. alright, so just checking, I've never done it outside of CMake gui, so do I just change -Dprotobuf_BUILD_TESTS=OFF to -Dprotobuf_BUILD_TESTS=ON or is it on by default? furthermore, there's an #include in the code that makes use of it, so is there a reason the guide says to set it to off? it looks like that would break the compile every time, seeing as I did not build tests, and it still looked for it.
  11. alright, I spun up a windows VM to make the environment as clean as possible, and it all worked until compiling the engine, which ended up throwing these errors. I tried it a second time, and though the percentages changed, the files supposedly causing the issues did not (I assume because it was skipping completed files) I can't find gtest_prod.h, so the program is right and it's absolutely not there, but no other file in any of the dependencies include it or anything of the same name. I remember there being some options in a cmake file about an optional test, that could be switched off. Is this related? (edit, they don't seem to be. gtest looks like it handles gcode export testing which seems super important, so now I'm even more confused as to why it was never made.) man, I feel a lot closer this time, and I bet this is the only thing missing, too.
  12. Thanks! There are still a few things unanswered for me though. What is the deal with using 32 bit everything to build cura? I understand if you're building a program most people should be able to use it, but at this point, 64 bit has been the majority for the better part of a decade, and 32 bit support is being dropped more and more, so I'm curious why it's preferred. The only things I can think about are issues with building or that something requires it to be 32 bit. speaking of that, I do have a couple questions as an outsider reading the guide. I can work them out on my own, but it's mostly curiosity. it says to download the correct shapely library, but what counts as a "64 bit install"? just python as I assume, or is it referring to everything, or the expected final cura version? I don't remember libsavitar and charon from my previous attempts, I think they're proprietary file loading and marketplace stuff? also as someone from the outside, I want to thank you so much for a few features in particular: noting that uranium does not need to be compiled is huge. I was so confused about it. noting the function and reason of commands instead of blindly following them means building cura might even be good for learning how to build and contribute to open source projects. Even blender doesn't go into such depth. the blurb on how nmake is used through the VS dev prompt is great. all in depth information is both succinct and in actual everyday english. it may be overlooked often, but most of the time, in-depth and accurate terminology only serve to alienate the people who can't causally breathe code. reminding us to verify if things are installed. I'm dense and forgetful. this is really useful. I'm getting some issues regarding wonky installs and cl.exe apparently being broken? It's most likely me being super dumb and installing things and vs not uninstalling properly and I've left my computer a mess. In any case, I'm setting up a windows virtual machine. I've decided it's the best way to develop in a stable, repeatable manner. that's why I'm being so long-winded (looking at you, storage allocation bar.), it'll take a day just to set up the machine and install visual studio/get it optimized to the point I can open a file folder in under a minute. I'll get back to you to tell you how it goes.
  13. That would be great. It's not just for me I imagine. A large number of the issues on github are build issues, and in any case, the easier it is to work on, the more features casual users will begin to work on... hopefully. The most confusing parts for me are cross-compiling (if it's easiest to build in linux but most users have windows this is important I think) and what happens to CuraEngine once it's made. It doesn't seem like it's properly installable, so do you move it to some folder in Cura or is there some step where you point the compiler at it? I haven't gotten that far yet but it's aomething that I haven't figured out after reading everything.
  14. And considering all that, I think the wisest choice may be simply to wait until you guys are done migrating it. As you can guess, I'm no career developer. I've only really compiled Blender and Slic3r before. Unless I can get this working by following the directions mostly blindly, (or at least fail with a descriptive error message) I'm not going to have much luck troubleshooting. I'll keep trying through the normal workflow. I've found some alterntate ways to make prints just a little clearer without overextruding, but all of this was for the purpose of adding "iron every layer" and a few settings to make PETG and other "boogery" materials print better- essentially temperature modulation depending on the structure (lower/higher temps on supports may help.) i also want to take a look at the delayed layer code to see if anything's up because it doesn't seem to work for me, and see if running the side of the print head around the outer edges can change surface quality somehow.
  15. I know where it is, no need to babysit me quite that much XD... though I do appreciate you guys being my safety helmet. I was able to use cmake on cure-dev-environment, but when I use make I get "make: *** No targets specified and no makefile found. Stop. " and sure enough, there are actually no makefiles in build, just cmakecache, lib64, and all the dependency files. lib64 is only 3 bytes, so I can't imagine everything worked perfectly.
  16. that's probably the reason. in any case, I tried just taking it all and putting it into a folder, then using the apprun and it worked for all of .2 seconds! I saw the ultimaker logo, and it brought me to the same send crash report popup. Both my compile and the appimage (when deconstructed) did this, so I can probably assume it's working? maybe? probably not. (one day later) ...linux being what it is, provides no GUI or any guided method of doing so, I learned. I try to run the new appimage, but I just get execv error: Permission denied, even though I'm root and own it. I think I just need to learn to cross-compile the whole thing from linux to windows, to know if it's working, though tell me when you guys get that cura-build/cura-build-environment working. I wasn't aware it was in progress the first time I tried.
  17. ah, so that's what's so important about the arcus.pyd. basically, you need to compile the c++ into both python and normal c++. That totally explains why I was getting deja vu when I was Following the build guide. so nmake for python, and cmake for c++... so I... supposedly compiled curaengine in linux, but from what I understand, you just drop it into cura proper to make cura runnable... but all it seems to have made are these lib_CuraEngine.a files and this 4.1 mb CuraEngine file. that seems like the one, but it's 1.7mb smaller than the main release's, and because debian is super protective I can't just drop it into an appimage and try running it with cura. like I could with the exe in windows. I'll see if the cura-build or cura-env are better for linux. I'd prefer to build all on windows, but windows really, really needs a folder just for libraries to be installed. this is getting silly.
  18. build it twice? what for? If cura and curaengine both need it, just building and installing once should do it... maybe that's what I was doing wrong before? and like I said, I'm not in love with codeblocks yet, so if you know the command line commands to build using mingw-w64 in debian/mint (I have it installed already) feel free. I'll look it up, though if you know any caveats for cross-compiling, some tips would be appreciated.
  19. actually, I've been using the last couple days to learn about/how to use debian/linux. I'm running it on a virtual machine, and I've got everything going right on the first try! (I knew it wasn't just me being dumb! it was the OS that made it nearly impossible to both link and set up dependencies.) at this point all I need to figure out is how to cross-compile a windows 64 bit distribution on linux (i'm using codeblocks. is there an easier solution?), and I'll be set. maybe there's a way to do it from command line? I really don't know the various mingw make commands, and using them on linux just adds another layer of confusion for me, though XD.
  20. ...I'm not sure how that would end up leaving out exactly 2 files, but oh well... that said, 32 bit hurts my soul. might I ask... how you build in 64 bit? I followed the directions blindly until they didn't work, then fiddled around till I got the right output, so it seemed, but there was no clear indication of what causes things like mingw32, cmake, and visual studio to build 64 bit programs. I was assuming they did, because as far as I know, it's the standard now.
  21. yeah, here's the most recent one. I forget what I did before that made it actually find and build with arcus, but I've tried C:\dev\libArcus\install_dir\lib\cmake\Arcus and C:\dev\libArcus\build the only two cmake files you can end up with: one used the cmakegui to build, the other was built and installed with nmake.
  22. Well, I would rely on the tools, if they actually worked more than half the time. 😞I'm new to in depth builds like this,(I have built blender and slic3r before but they both use allmost no external libraries) so I'm not exactly sure what to do when the tool fails, then refuses to work even after I set a viable output. (Cmakegui tells me it "considered" arcusconfig.cmake, but decided not to use it.) For VS I've tried putting the .h files in with the others in Curaengine but it still doesn't find them, and I think that some linkage is messed up, and as this is my first time dealing with that kind of thing. Is this just a windows thing? I've been able to fudge arcus into working, but for some reason nmake and cmake from command line only really make .a files. For example, when I used the VS2015 command prompt to build arcus like in the tutorial, I never got a Libarcus.pyd file. I only got it after using cmakeGUI to build the solution files and then building build_all, but when I do that, I just get a release folder, and then there's nothing to install, but I have all the .py, .pyd, cpp, and .h files I did find a good tutorial on more advanced linking practices in VS so l'll get back once I confirm or deny that it's visual studio/my computer/technique that's janky. If that doesn't work I'm setting up a virtual machine and trying from scratch on debian/mint.
  23. Update: when recompiling Arcus, I ran across this in VS. it seems to directly correlate to this, which is stopping me from being able to build the engine. has anyone come across this before, and should I open an issue? I looked around, and this error seems to hint that some of the code is written in a very nonstandard, risky way where it exports. it seems doing things like this causes issues in any case where compiler, compiler settings, or compiler version change at some point in the project... which does happen. a lot. reference: https://stackoverflow.com/questions/24511376/how-to-dllexport-a-class-derived-from-stdruntime-error
  24. I still haven't been able to compile cura yet. whenever I try to run or build CuraEngine, those errors at the top show up, and because it's not my code, I don't know how it's "supposed to be". right now, all my files are just kinda set in the "c:/dev" directory. it feels kinda wrong, but I've never had to build dependencies of dependencies before. I did try to just take a curaengine.exe to a cura repo clone, but I got stuck trying to build uranium, 'cause there are no instructions at all for that one. libSavitar worked perfectly in the first try, though!...but it is self-contained, meaning my computer/setup has loads of issues finding dependencies.
  25. IT WORKED!...sorta. well, it didn't, till I did something. every step other than protobuf changed a bit, so here's the explanation: I kept getting errors like "access denied" and "could not find directory" from using nmake install on sip, which meant something was wrong in its makefile (lucky guess I swear) I went into the sip makefile that popped up after using configure.py, and one of the lines... looked a little screwy. so I removed it and it worked with no issues. it seems that line was just to make/read a text file? weird. (see included image and tell me if I shot myself in the foot.) then I built Arcus. no errors, other than that I needed to use the cmake gui and build from within visual studio. It kept making .a files and doing other weird things when I followed the directions. CuraEngine stumped me till I faffed about with cmake gui till I found it wasn't finding its own lib files, that explained why clipper and rapidjson aren't listed as dependencies. after that (thank you vcpkg for having my back for protobuf and cppunit) I was able to open CuraEngine in visual studio, and immediately found some of the files and code I'd need!(cool!) Now, I have one last hurdle before the engine's out of the way... does this mean I have to put arcus somewhere inside curaengine's directory, or am I just really bad at system variables or something? The header files listed exist, but not directly inside the arcus directory. they're in layer lower than arcus/, in LibArcus/src/.
×
×
  • Create New...