Jump to content
Ultimaker Community of 3D Printing Experts

selmo

Dormant
  • Content Count

    45
  • Joined

  • Last visited

Everything posted by selmo

  1. Cura 2.4 seems to be quite...uh...clumsy when it comes to prefs. It stomped on 2.3 prefs when installing. And it seems to nuke it's preferences & custom printer definition every time it freezes...which is very frequently. :( I've resorted to creating a zip of my cura prefs folder, and I've got a batch file to kill cura and restore settings. from the zip. I have to use the batch file a LOT some days.
  2. I don't think waiting would have mattered -- in this case, the glass chipped as the part cooled -- I heard unusually loud pops before I even touched it (much louder than the usual ABS pops). The glass chip remained fully bonded to the PETG part long after I removed it from the printer (and only popped off when I flexed the part). I was printing with a 50'C bed temp and it cooled to < 25'C before I attempted to remove it. Removing it was harder than PLA or ABS usually is, but that did not make any cracking noises or required a crow bar. It's possible there were some microscratches on the
  3. I'll look around and see if I have a good example. One thing I've found is that t-glase has a lot of pigment, such that the transparency is kinda lost when you have multiple perimeters (at least the red and blue, which is what I've got). I'm guessing they designed with single wall prints in mind.
  4. I haven't had it happen with MadeSolid's PET+ (yet)
  5. So this is a new one for me. I printed some parts in t-glase on my UM2, and they stuck to the glass really really well. TOO MUCH, in fact. It made some loud popping noises as it cooled, and even when fully cool, it was hard to get off. Sliding the thin metal blade spatula pried it off, gently and it sections. Once I got the part off, I was looking at the nice smooth bottom side and I saw some defects. Looking closer, it was a weird bump. When I flexed the part, the bump popped and flew away. RIGHT INTO MY EYE! GAH! Looking at the print bed, I now have divots. The t-glase stuck so we
  6. OK, I'm going to deviate from conventional wisdom here. I've gotten some nice clarity with t-glase, trans ABS, etc. by using thin layers. The lack of clarity comes from air bubbles breaking up the light's path through the material. Using thick layers with a single perimeter to get round extrusions of solid material is one way to avoid air gaps, although you get a side wall that's ribbed (the new 2-part epoxy Smooth-On coating or vapor smoothing addresses that issue). I've experimented and had some good results by using thin layers (below 0.1mm), increasing temperature, increasing extrusion
  7. The hex file in github is the latest version of the source in github, so you can just install that without compiling if you just want to try it out. It's been working great on my UM2 for the past couple months. It's a couple updates behind Daid's releases; I've been meaning to do a resync... one "risk" of this firmware is it's a "when I get the time" sorta thing. (I've also been holding off doing a resync so I could get some testing of my changes without brining in anything new.)
  8. The UM2 has a simple, streamlined look and I don't think an advanced control panel with lots of gizmos and blinky lights fits their aesthethic (more Evo than Wall-E). The nerd-fork display may overwhelm those who don't understand what those numbers mean. It may even invite people to tweak things they don't understand? It shouldn't be the default, but perhaps offered as an option for advanced users? It does make it easier to troubleshoot printing and UM customer service could use it when helping customers. Even without an advanced display panel, pulling in the nerd-fork's more informative use
  9. OK, thanks. I'll look into it more next time I have a moment. One issue I ran into with *some* LCD libraries is they are optimized for an 8 bit (ie: one byte) tall pixel height ( 5x7 font) and everything breaks if it's not 8 pixels tall. And they certainly had no provision for a variable width font, so I'm interested to see how well your stuff works and may port it into some other libraries. I also may change the numbers to be fixed width, as variable width numbers to make columns jump around.
  10. I think that's an interesting option. The small font looks readable -- how does it hold up at a distance of 1-2m? I want to keep everything clear and easy to understand at a glance, without my glasses on. I've tried playing with font sizes before, with mixed results. At the very least I might look at yours as a template for making a new font that's a bit smaller to gain an extra row. It looks like you can mix it with larger fonts as well? That would be nice so we could keep the most important information larger / more visible and shrink the less important stuff. What I've done in the
  11. Oh, I should add that if you do try this firmware, be sure to set your materials to defaults when you first run it -- the stored materials eeprom values between the official firmware and this firmware don't match. There is some sanity checking in there, but it's best to reset it (you won't see the additional "exotic" materials in the menu unless you reset to defaults as well). (likewise if you go from this firmware back to the official one)
  12. I've been running it the past month with no major issues. Curious to hear from anyone who tries it -- feedback is always welcome. :-P I can add current Z-height easily, if I can find a place to squeeze it in on that already cramped display area.
  13. OMG, that would take ages! I added a short delay in reading the file details (time, filament used, etc) when scrolling through the directory listing to make it more responsive -- I shudder at the idea of doing a list sort where it had to hit the SD card every time it did a comparison. :shock:
  14. The order on FAT devices, like our SD card, is the order in which the file was added to the directory structure. If you overwrite a file, it's sort position does not change. In order to sort the directory, you need to remove all the files and add them back in the order you wish them to be sorted. There are some utilities which can sort the SD card directory for you (usually used for MP3 players that play songs in the default sort order on the SD card). Here is a list someone compiled of the available options. http://www.murraymoffatt.com/software-problem-0010.html I looked at the firmwa
  15. That's #3 on Illuminarti's list of fixes. ^^^
  16. I was wrong on the multi-extruder thing -- it retracts, not primes, additional extruders in doStartPrint();
  17. Ah, I didn't realize that's what that conditional was for. I misinterpreted it to be a sanity check on the materials list. Checking the LCD display cache for the estimated material length !=0 to determine if it's UltiGCode or raw gcode... well... yah... I'll just say that macro manual struct construct in LCD display cache isn't the most lucid piece of code. Interesting ... that conditional is not applied to the AbortPrint() that does the end-of-print retraction. It uses card.sdprinting (not the same condition). Similarly, the AbortPrint retraction only retracts the active extruder but do
  18. Hrm. That's related to something suspicious I saw in doStartPrint()....which is why I asked about raw vs Ulti... From what I see, doStartPrint() is called in both UltiGCode and raw gcode printing, so the priming in lines 85-87 gets called for either filetype (right after raising the bed). But the difference is plan_set_e_position(-30.0 / volume_to_filament_length[e]); gives different priming amounts depending on if it's ulti-gcode vs raw gcode... Looking at where volume_to_filament_length is set, it's 1.0 for raw g-code and 1/(PI * R^2 ) for Ulticode.... which results in roughly x7
  19. Has anyone noticed if the behavior is different when using raw g-code files vs ultigcode?
  20. The issue is in the firmware and not Cura. Specifically, lines 87-89 of UltiLCD2_Menu_Print.cpp Daid made a change on May 28 to reduce the speed (from 25 to 10) but I think it needs to go down even more. I use 5 -- which has fixed the grinding on most, but not all, filaments. To be really safe, it might need to go down to something like 3 (but it will take a while longer to finish it's spew). Also note any additional extruders will spew at double that rate (not sure why that is) Here's his commit: https://github.com/Ultimaker/Ultimaker2Marlin/commit/c760f0dd4e8976d5f3abf75751cbdbf5f
  21. I find the smell varies by brand and color more than temperature. I print IC3D's ABS at 230-245'C with the bed at 100'C-110'C, 107% flow, and fan at 0-100% depending on how much overhang / thin walls / bulk the part has (usually stay in the 20-60% range). On the bed: just glue stick, no slurry Retraction at 3mm at 35mm/s. I can print at over 15mm^3/s without under-extrusion.
  22. Of course.... (ad naseum). But we should start a new thread and not derail this one any further.
  23. Yah, I would like that feature in Cura/UM2 (without going so far as to raw g-code)
  24. I noticed the "grind out" at the start too. I moved the initial extrusion distance and feedrate to #defines in configuration.h -- I suggest maybe they should be a user pref or an M? G-Code adjustable EEPROM settings (like acceleration, jerk, maxspeed, steprate, etc). I found a feedrate of one fifth to one tenth the original value would give me a good prime without grinding or skipping. I also disabled raising the bed, as it causes problems with resuming an interrupted print or single-extruder dual-color prints (the firmware makes an incorrect assumption that all prints will start at Z=0,
  25. I can also confirm my bed height lack-of-consistency problems are gone with 14.06 based firmware. I've done at least a dozen prints and every time the first layer height has been on-target. (previously, I would have to adjust the first layer height on the fly for just about every print, at least a little bit -- sometimes it would be off by nearly a mm)
×
×
  • Create New...