Jump to content

nubnubbud

Dormant
  • Posts

    42
  • Joined

  • Last visited

Everything posted by nubnubbud

  1. Huh... I see why this isn't standard, but it's better than the standard in my opinion, friendlier to people who've inevitably messed up their entire computer for this not to work, like me. is python 3.5.0/6 absolutely required?I have 3.6.6... or will installing it via visual studio work? the only difference I see is physical location. also, before I go through this chain of builds, rapidjson in when using cmake for CuraEngine has the exact same issue that sip did! (I build arcus without any python dependencies to check if there was any more to worry about). I didn't see RapidJson listed under any dependencies, so it might be good to list it somewhere. for protobuf, I was unable to build it before, but the install from vcpkg worked perfectly for filling out the arcus cmake dependencies, it's basically pip for c++. If you added arcus to vcpkg, installing it would cascade, find and install protobuf and all of protobuf's dependencies, too... then again I might need more sleep because how would arcus get its python dependencies, but it's a nice thought.
  2. alright, so I went through everything, set path where it was supposed to be, and it seems to get one step further and nmake actually runs now that it knows to find nmake in the VS 2015 tools, but there's still the issue of nothing being built. SIP still isn't being found. As well, I saw the error, and in a fit of gall I tried to run it with various settings, like trying to install it to the 32bit python, 2.7 python, and with/without the VS dev command prompt. I also uninstalled all other pythons just in case. I also tried the 2017 nmakes(x86 and x64) to the same result. no dice. I did however get it to say cd sipgen "C:\Program Files (x86)\Microsoft Visual Studio\2017\Community\VC\Tools\MSVC\14.16.27023\bin\Hostx86\x86\nmake.exe" Microsoft (R) Program Maintenance Utility Version 14.16.27031.1 Copyright (C) Microsoft Corporation. All rights reserved. NMAKE : fatal error U1073: don't know how to make 'sip.h' Stop. NMAKE : fatal error U1077: '"C:\Program Files (x86)\Microsoft Visual Studio\2017\Community\VC\Tools\MSVC\14.16.27023\bin\Hostx86\x86\nmake.exe"' : return code '0x2' using the 2017 nmake x86 version. I got this every other time. it seems to reference that I'm using a 64bit system, but shouldn't that be compatible with installing/compiling 32bit files?
  3. I am using the GUI- but that's not the issue, I think. I've installed sip, but... there's not a single file with sipconfig in its name on my entire computer. note that I am completely unable to install python3-sip-dev or python3-dev because those are not released or otherwise available for windows, as far as I can tell, and that probably gives me issues. it's always just said SIP_DIR = SIP_DIR-NOTFOUND Do you know what's going on here? it seems someone somewhere knew about it, because there is no guide to building libarcus in windows, unlike all the other repos. it just says "Building the Python bindings on 64-bit Windows requires you to build with Microsoft Visual C++ since the module will fail to import if built with MinGW." but gives no other help. I've tried building with the visual studio dev command prompt, but nmake finds nothing to work with anywhere in C:\sip-4.19.17 (where I slapped the python-sip-dev source files).
  4. I was able to set up protobuf, though only through vcpkg, and now cmake is asking for sip cmake files for arcus, because I'm using vcpkg's toolchain, even though I have it installed in python.... here's the error. I can't find sip cmake files wherever I go, so I can only assume they don't exist? I installed sip and qt5 with "pip3 install", but are python3-dev (3.4+) python3-sip-dev (4.16+) as listed in the arcus build guide the same, or something I don't know how to get? I'm on windows, and this bit in the arcus guide looks like it's for ubuntu or something, but there is no windows guide! $ mkdir build && cd build $ cmake .. $ make # make install EDIT 2 alright. after some careful searching and looking, pip3 install sip does not install the needed files, and I can't find python3-dev or python3-sip-dev anywhere.
  5. this, right here, gives me hope, and is exactly what I needed- and what I think a lot of source code needs. a one to two sentence breakdown of getting it set up in the right order (and places?), and how much fiddling you should expect. also, I'm curious about that too. I'm no expert (of that we can all agree) but it seems like there should be both an order and a place for all the files to go. How do I make sure everything sees each other properly, for build/running purposes? is there some kind of standard directory setup, are they set up to look out of their own directory to the ones in the same folder, or is there some setup I need to know, like placing libarcus or curaengine somewhere in cura?
  6. ironing isn't an extrusion multiplier or something quite that simple. it requires moving the printhead back and forth over the entire layer, in passes smaller than the extrusion width. as well, the print head does not rise, and even keeps extruding the slightest amount, to fill in any texture in the top surface. it already exists, and works wonderfully!... just it can only be enabled for exposed upper sections of layers wider than the extrusion width. I've proven results with handmade gcode, but then it just kinda fell off to the side of the road... but I want the feature because it's useful for me right now.
  7. it's probably not all frontend, and I imagine I might need to touch the engine a bit. basically, I want to add an option under ironing that will make it iron every layer, since that produces stronger, clearer prints (yes, I've been on about it for a long time now)
  8. Then... I'm terribly confused once again. don't I need the solution files? I can't get those without building the dependencies, and that's what I've been pulling my hair out over for days, and I do intend to work on the engine a bit. just, when I try to use cmake to build the solution files, it needs uranium, and protobuf, and arcus, and all of those have dependencies, etc, and they themselves don't compile, so I went to the environment, thinking it was where to get all the dependencies at once? if you can't tell, this is only the third open source project I've poked my nose in.
  9. I had to double check, but the repo does not have that file, nor is it made by building it, and I can't seem to find a link from your account to anything that looks like it. if you're talking about running env_win64.bat and then using cmake with the directory and build type arguments, I'm doing that already. were you also having that "python is not recognized" issue too?
  10. so, I tried it, and I'm getting the exact same result, cura or yours. I solved all the other issues, which turned out to be the combination of a misplaced mingw directory and needing both the previous and current python (2.7 as well as 3.5/6/7) now I have the same issue on both versions. after I run either your fork or the main build environment, it runs into some kind of issue with python, which seems to be an environment variable thing, I have added python to my path, though, so it should all be working. here's some snapshots of the output, if it's familiar to you. any guesses as to what it could be? it continues with those python files for a good while, no other issues, till...
  11. That's great, and I'll try it in a few hours when I can, but how does it differ from Cura's masters, and will those differences make any issues for making commits or pull requests?
  12. I've been trying to build the program so I could add some functionality that's sorely needed, but I've been sitting here for 2 days, building dependency after dependency, so that I can use those to build the dependencies for cura's dependencies, only to learn something is wrong from an indecipherable error. I'm at wit's end and now is as good a time as ever to ask: What am I doing wrong, from a technique standpoint? am I using the wrong build? why are there 4 different ways to build it, and which is the correct/current one? do I build the environment, and how do I manage that when following the directions don't produce any results? do I build all the dependencies manually like it says in the other guides?
  13. yes, I'm actually in contact with Slic3r pursa edition devs because they reached out to me, though I'm having a bit of trouble implementing it because the code has almost no documentation, and my printer is having some quality control issues at the moment (it's an old cr-10s and can't hit its projected temps due to hotend and capacitor issues.) the file attached was my last attempt before these issues started, but I was able to make an optically clear part to within .1mm of the projected width. Because it's clear at over a centimeter thick, I also have reason to believe it has crystallized very well, and is extremely strong. because this gcode is edited by hand, it's extremely tedious, and the relative extrusion makes it less predictable, depending completely on the machine to know exactly how much to extrude.
  14. played with some manual gcode. yes, this works, at least somewhat. printed in PETG. the clouds are in the print, and are all the same shape, so it is either a retraction setting in the model, or due to the model's shape and settings. they are, however, not just uniform shapes, leasing me to believe taller prints may not suffer from it as much.
  15. "jerk" is an integral setting of gcode that slows down the print head before a sharp corner. without it, your machine would shake itself to death, or at least wobble and wiggle a lot more, affecting print quality. I believe it's a bit soft, and will slow less for a 90 degree turn than a 180, but don't quote me on that. the issue is, most people don't print at 100-500mm/s, meaning the jerk setting at its basic setting of 500, 5000 or something does almost nothing. turn it to 10 then print a test XYZ cube, and you'll probably hear it working its magic.
  16. for basic bargain bin PLA on my CR-10s, I get my quality through the roof by dialing down my jerk settings to 20-5mm/s, printing under 25mm/s at 200c. if you have supports, use interfaces. 3 walls, 100% flow rate, and .1mm layer height. this is not how to learn, though. it's just copying some numbers and not knowing why they work. you want the lowest temperature that gives you good adhesion without creating friction and knocking over prints. it's a bit tough on extruder motors, but prevents blobbing, stringing, boogering, and elephand's foot, as well as giving you better bridging, easier to remove supports, and nice overhangs. Low jerk prevents ghosting and shaking, and the base jerk is at 500mm/s/s, which basically disables it until your print head is moving a quarter of a meter per second. basically cut the jerk number in half, and that's the fastest speed at which it will attempt to make a hairpin turn. outer layer options. time saver settings are here. print at normal speeds on everything but the outermost layer. if it's not obvious, you don't need the inside to be pretty. also gyroid infill is really fast unless you have a lot of thin gaps in your model. if you have everything else dialed in, layer height is almost a non-issue, because your layers will be nearly invisible, and your detail is limited by your nozzle.I would not suggest printing at the same layer height as your nozzle is wide. it seems to do wonky stuff with adhesion and part strength unless you overextrude, at which point you might as well just use a larger nozzle.
  17. Earlier, I began printing in PETG, and my first prints got successively better, till little parts of the prints I made were clear enough for me to hold against a screen and see the details through it! but no more. I was printing little 1cm cubes, and I began noticing that the issue lies in extrusion...lines? Essentially, little bubbles between the extrusion lines were left behind, even after dialing in my settings to the best of my ability. I believe ironing may be the solution here, but therein lies the issue. Cura only supports ironing on exposed upper surfaces. I believe it should be an option, and not hard to add a little check box to "iron everything". it should come with a warning that it will slow down prints immensely, but after spending 3 hours on a 1cm cube in an attempt to get it a little clearer, I think the feature can stand on its own. I'm not sure it will make things clerar, but I'd say there's a decent chance, and some extra heating on the top of every layer may actually help strengthen prints by removing fracture points and ensuring better layer adhesion, in any case. another option would be the ability to list which layers should be ironed and a checkbox for whether to include the entire layer or just exposed faces. I know a few people that wanted to iron only a couple layers.
×
×
  • Create New...