Jump to content

Darinth

New member
  • Posts

    7
  • Joined

  • Last visited

Personal Information

  • 3D printer
    Other 3D printer

Recent Profile Visitors

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

Darinth's Achievements

0

Reputation

  1. This is printed with PLA. I've tried printing with ABS exactly once. I gave up on what I was trying to do at the time and since then 3D printing has mostly moved on to better alternatives from what I understand. I really don't see anybody recommending it for anything these days. I've also used PETG and keep some available, but I tend to avoid it unless I've got concern about needing my print to be a little bit more heat resistant. I still use PLA as my general purpose workhorse. Might make another attempt at just trying to resolve bed adhesion issues, but not gonna lie I really like the solution of just reordering the lines. I've printed a dozen or so of these with the manually altered gcode at this point and have a 100% success rate with 0 defects.
  2. Bigger issue honestly right at the moment is that I tried again yesterday and, unless I'm missing something, the logger used to debug post processing scripts is broken and that makes actually writing the script a PITA.
  3. I agree that this would make more sense for Cura to do, but I have little to no capability to get draw attention to this need to see it implemented and right at the moment I'm not gonna lie I simply don't have the desire to go through and learn Cura's codebase well enough to make the PR. I do, however, feel confident in my capabilities to write a post processing script that will read & analyze the different lines and can reorder them in such a fashion that (if possible) it'll start with longer/straighter line and from there select lines that are already adjacent. Even at an N^2 algorithmic complexity, this should be doable for a python script that's just reordering the lines for the first layer. If that turns out to be too high, I already know how to get this down to what should be N log N.
  4. Neither outside to inside or inside to outside is the right print order on the first layer. Both have problems which required me to go into the gcode and manually reorder the lines. Hoping to create a post-processing script to automate the process, but I'm having issues with debugging. Logging in general appears to just be non-functional in post-processing scripts. Nothing in the video which is new to me. I generally print using a PEI sheet on a heated bed, and that's solved most of my adhesion issues. It's only an occasional issue like this that cause problems. With 10 tiny holes (measure 2.87mm from corner to corner on the model) in rapid succession and all of them are actually functional components rather than just something aesthetic, they basically have to be perfect. So taking the time to clean them up at the end gets frustrating. And don't get me wrong... there's probably a like >80% of the holes adhere with the default print order... but with 10 holes that means that there's almost always a hole or two that gets a little mangled. Good squish, heated bed, don't generally have adhesion issues... but apparently when I get down to small 'outside' lines on the inside of the model I've still got issues. I'll admit, I haven't tried an increase in the first layer flow rate. I may give that an attempt. But honestly it still seems like options to reorder the lines on the first layer is a really good, viable solution to an issue that I know (from finding other people who've had similar issues) causes a problem for some prints.
  5. After manually modifying the gcode to print the lines in this order, I am now at 4 for 4 with zero defects. Just need to figure out how to write a post-processing script to automate re-ordering the lines of the first layer... manually reordering gcode is a PITA.
  6. I've been trying to write a post-processing script (trying to see if I can get the problem I outlined here fixed) and as part of this I started off just trying to learn generally how they work. I've been able to make changes to the script, but I can't get the any kind of logging to work which makes debugging a pain. All of the scripts I've seen thus far use UM.logger, but I've not actually been able to figure out where these log messages show up. They don't show up in the normal cura.log file and they don't show up in the actual console (I've got cygwin and ran cura from a cygwin bash prompt with the --debug flag). I'm running cura 5. Am I missing something obvious? Is there potentially a bug with the logger not working correctly in Cura 5?
  7. I'm trying to print something that has a number of small holes in the bottom, and running into an issue that I feel like there should be a good and obvious solution to, but every time I try to change one setting to solve this the slicer makes a bad decision somewhere else. That is the full set of lines for the first layer of the print. By default, the slicer wants to do red lines (outer walls) first (ish) and then move towards the green lines (inner walls) and finally the yellow lines(interior fill). Tweaking various settings, I can get it to go green lines first, then red lines, followed by the yellow fill lines. But either of these settings results in it trying to print small unattached bits on to the build plate, and because of the large number of them... probably > 70% of these have some number of the holes mangled and require extra effort to clean up. Ideally... I feel like it should print the outer most red line (because longer, straighter lines generally have the best buildplate adhesion) and from there work it's way slowly inward always starting each line so that it's touching a previous line because filament sticks to itself extremely well and as long as you start adjacent to another already printed piece there's generally no problems. So for this print, I'm fairly confident that if it did the outermost red line, then moved to the green lines that are next to it, then the yellow lines, then the interior green lines, then the red outlines of the hole (starting each of those outlines so they're adjacent to the existing green lines), then the innermost green, and finally the innermost red lines. Given what I've seen with my issues with getting small features to attach to a buildplate... I'm surprised this isn't already an option but if it is I'm not able to find it. Is there a way to make this happen? Is there a way to force the line ordering such that it starts off with a line that is the least likely to have build plate adhesion issues, and slowly works from there to print lines that are attached to the ones that should already have good adhesion?
×
×
  • Create New...