Jump to content

selmo

Dormant
  • Posts

    45
  • Joined

  • Last visited

Posts posted by selmo

  1. Hi @nallath well I have been running 2.4Beta 2 for the past week and very pleased with it - although at least once and I think twice, it has lost my custom printer definition.

     

    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 glass that the PETG locked into as it extruded, and the size changes while cooling was enough to wedge open the scratches to full-blown cracks. Kinda like how ice will split rock. Maybe something about the extra strength of t-glase PETG combined with printing a large flat area on the part bottom.? Usually borosilicate glass doesn't have as much trouble with expansion / contraction.

    The resulting divots were pretty clean "scoops" -- no cracks or partial chips around them They were in the center of the glass (where the most wear / scratching would be). Maybe printing in a less-worn corner would be better, but I'm a little hesitant to experiment, at least until I can easily and affordable get a new glass bed in the US. ;)

    I'm usually pretty good about safety glasses, but I had no clue there was any danger....I wouldn't have flexed the part while looking so closely if I had any inkling that bump was part of the print bed glass! I've only seen this (so far) with t-glase (not ABS, PLA, Nylon, PET+, ninja, flex PLA, etc)

     

  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. 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 well to the glass that it pulled the glass up with it, leaving behind craters. It's hard to photograph, but here's a try.

    t-glase chipped glass

    I was able to get the glass chip out of my eye without a trip to the emergency room, and I've flipped the glass bed over. (and avoided printing with t-glase for the short term). I guess I need a replacement bed at some point.

    Never had that happen with any other filament stock, and I didn't do anything too unusual in terms of temperatures, etc. Other parts I've done in t-glase without this issue, although these were he first parts I've printed in it with a large flat bottom area.

     

  5. 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 flow, and printing slowly (without a fan, if the material doesn't droop). By smashing down heavy layers of hotter-than-usual plastic, it flows and conforms better, minimizing air gaps. I've gotten some clear parts with multiple perimeters that way. It's not perfect, but I think it looks better than the recommended 0.3+ single wall results. YMMV.

     

    I have this sticker on my machine, under the bed. printing clear reminder

     

  6. 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.)

     

  7. 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 of the RGB led, encoder ring, speaker and lighting LEDs would not complicate the experience. I'm sure Daid has nothing but time to for that. :)

    A spiffy display is a pandora's box -- everyone has different ideas about what's most important. Screen space is tight.

    I've thought about implementing some sort of simple configuration script to let users decide what info to put into a fixed grid of "slots." But how to let users tweak that? Requiring users to re-compile is not very friendly, but a UI/menu based configuration tool sounds like more work than it's worth. Maybe read a text file from the SD card and store the config in EEPROM?

     

  8. 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.

     

  9. 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 past was to "time slice" the less dynamic values -- so something like head temperature would switch to bed temperature every 2 seconds or so, time-remaining switches with filename, etc.

     

  10. 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)

     

  11. 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.

     

  12. 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:

     

  13. 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 firmware to see if there was an easy way to sort the directly list for user display, but reading the entire directory list at once in order to resorting it would take a lot of precious RAM.

     

  14. 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 doStartPrint primes all extruders (I saw no retraction during a tool change). Seems like the end-of-print retraction is not balanced against the start-of-print prime in all cases.

     

    Printing raw gcode could come from any slicer, and therefore the material length header would not be there. Cura does not use the same header format as in UltiGCode, but instead puts this header in raw gcode:

    ;Sliced at: Wed 11-06-2014 21:40:22

    ;Basic settings: Layer height: 0.1 Walls: 0.5 Fill: 20

    ;Print time: #P_TIME#

    ;Filament used: #F_AMNT#m #F_WGHT#g

    ;Filament cost: #F_COST#

    which is in a different format, different units, and is not properly filled in....so the conditional would skip the prime (as you said)

     

  15. Yes, the priming doesn't happening using raw gcodes, so it's less of an issue.

     

    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 the prime length for Ulticode vs raw gcode....

    So raw gcode does prime, just by 1/7th the amount.... I'm not sure that's difference in behavior is 100% intentional...

    I changed the feedrate (2 lines down) from 10 to 5 and no longer have grinding. Unless you're talking about some priming that's happening elsewhere?

     

     

  16. 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/c760f0dd4e8976d5f3abf75751cbdbf5f3eec1c2#diff-41dee0ad5d891d59fab5c856765b9c1e

    There is an open issue, started by illuminarti, on github, so hopefully Daid will be able to change it soon.

    https://github.com/Ultimaker/Ultimaker2Marlin/issues/25

     

  17. 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.

     

  18. 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, and therefore can smash the head into previously extruded material over 20mm)

     

  19. 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...