kfsone

Guys - fuzzy skin has only one thing keeping it from kicking ass: there doesn't seem to be any way to restrict which surfaces get fuzzed. For example: it doesn't hurt, but you might not want to waste print time on fuzzing the never-to-be-seen underside of your model; or you might not want to fuzz joints/connections. Ironing likewise would be nice to have finer control - perhaps the option to paint which surfaces you want each applied to? Hats off to you on both of those features, btw, printed a set of steps for our 15yo cat to get in/out of the litter pan with a bit of dignity, and she'd have nothing to do with the test print, but the fuzzed skin version she liked so much I printed her several other steps and pieces 🙂 They also look spectacular with some materials. LayStone with fuzz keeps fooling people into thinking they're touching a chunk of limestone or pumice 🙂

I hadn't, but that looks interestingly close to what I was considering, except I'd want it all the way thru the height of the model. In Simplify3d I'd probably just have multiple processes and split the high-fidelity parts out to a separate process.

PS: - "def __init__(self) -> None:" init doesn't return None, it actually doesn't return anything, so at some point having the "-> None" will break your code. - if you make your function-entry comments into strings, python will automatically use them as the function's __doc__ property, so that they are documented by help(function_name, and will the life of anyone who looks at your code as well as your own a lot easier 🙂 > ipython Python 3.7.1 (default, Dec 10 2018, 22:54:23) [MSC v.1915 64 bit (AMD64)] Type 'copyright', 'credits' or 'license' for more information IPython 7.2.0 -- An enhanced Interactive Python. Type '?' for help. In [1]: def getSettingDataString(self): ...: """ You may either use the normal getSettingDataString function or the getSettingDataStringWithInfo ...: the latter will add a comment setting in which you can enter any relevant information ...: you want to insert at the beginning of the GCode file """ ...: pass ...: In [2]: help(getSettingDataString) Help on function getSettingDataString in module __main__: getSettingDataString(self) You may either use the normal getSettingDataString function or the getSettingDataStringWithInfo the latter will add a comment setting in which you can enter any relevant information you want to insert at the beginning of the GCode file In [3]: If you'd like to experiment with gcode without always having to remember the gcode names ... it's very preliminary, I've only been hacking at it for a few hours: https://github.com/kfsone/pymcode. If you have a UM3, there's a "ultimaker3.py" script you can run that drops you into an ipython repl with "um3" configured as a connection to your printer and "ops" having all of the command aliases. Or you can then type "repl()" and it will go into a mode where you can basically either type '"M104' to send raw gcode, or you can just use the command names: Cmd> "M105 Cmd> set_bedtemp 65 Cmd> "T0 Cmd> set_hotendtemp 200 Cmd> wait_hotendtemp 190 Cmd> go There's a "help" command to list the repl commands.

Have you looked at iPython/Jupyter? iPython is basically the original repl on steroids and the "console" versions of it are a great way to merge IDLE and the REPL in one shot. Jupyter, originally called IPython Notebook - takes it a step further and abstracts the backing interpreter so that it can be housed in a web-service, where a "notebook" is basically a webified version of a repl with "cells" containing blocks of code that you can tweak/re-execute, iterate on. The back-end abstraction they called "a kernel" and because of this they're able to actually service pretty much any programming language as a back-end, it's even possible to have different languages in different cells. It brings a lot else to the table, including "magics" - additional commands that start with "%", e.g. %time and %timeit for benchmarking, "?" and "??" for querying objects/modules etc, ? being an abbreviation for "help(...)" and "??" giving generally better info, There are various debugger features too, but for me the most convenient is "%load_ext autoreload" and "%autoreload 2" so that as I make source-file changes they get auto-reloaded in the running interpreter.

When you're printing a piece that is mostly solid but with delicate connectors or prongs/pins/etc, it'd be really nice to be able to have something like adaptive layers that works based on the size/circumference of the section of the piece it's printing, so if it's printing a section of a part with a very narrow radius, alter the speed? See the stands in the attached example SampleShell.stl

<< This was supposed to be an edit, not a quote

@gr5 Please see above: it refused to extrude the second head on 18 of my 21 attempts to print the calibration chart today. The pattern of behaviors I saw today was entirely consistent with the C/C++ concept of "Undefined Behavior". I was beginning to suspect this earlier today, so I sat and repeatedly power-cycled the printer, asked it to print a calibration chart, and observed the results. Multiple behaviors were random. And yes, a 100% fail rate *is* a legitimate random sequence, if taken from a large enough sample of samples. It's also why you have a smattering of users who can't get auto-level to work at all, a majority of users for whom it is presumably working N/M times and a bunch for whom it works every time. Undefined Behavior often "works in dev" - in my experience it often works in qa and staging, too. UB is frequently non-deterministic If you want - I can take a look at the change log on github of the commits that went into this firmware and see if I can spot anything that would introduce a UB issue? I'm happy to trawl the code, but I'd rather not have to find it in the first place 🙂 -Oliver

Here it is not-printing. I have no idea why, I primed it before starting this print, you can see the residue on the left nozzle. https://drive.google.com/open?id=1sHU1varPzn2ZhSmLYm0944waA3W3S2Rj It did, though, print the very last line of the y chart: https://drive.google.com/open?id=1pfEOWTcIpbX7_dKPMpPN_HNFPY5rrKcS And then the right filament also failed to be extruded. I've manually leveled the printer and printed a successful 1-layer test print, now I'm going to try printing a calibration print again.

I got down to my last spool of PLA for the left head, but I managed - after 3 days - to get a calibration chart printed. In the end, stopped adjusting anything and just kept rebooting the printer and starting a new calibration print. On the 9th run, it printed this: (I'd run out of the other PLA so I had to use black...) After I'd entered the values, without doing anything else, I asked it to print another calibration print: it did the entire print without extruding anything, when it was done I went straight into Material 1 and moved it, and it instantly extruded some material... *shrug*

No: I was diagnosing an unrelated issue when I updated the firmware and after that the auto-level affecting issue prevented me from diagnosing it until I switched to manual leveling. But having said that, I think the problem is not specific to auto-leveling. I think you have some Undefined Behavior in your firmware: I'm unable to print the calibration test because the printer randomly Does The Wrong Thing for me in terms of selecting print head and priming that print head. I've tried about 15 calibration prints just today and I get a random combination of it lowering the wrong print head, unpriming the right right head so much that it only prints the last few lines of the chart, and occasionally - even though I have active levelling set to off - occasionally it will do an "active leveling" at the start of the calibration print and then it fails to print because its trying to ram the print head into the bed. https://drive.google.com/open?id=1_IOhDMBvyE8HEV6LdnkMypM2NjZdwQD9 It also keeps trying to either print the calibration print with the wrong heads (e.g it has the right head lowered while trying to print the left chart) or it over-retracts t1 at some point (I tried to make sure the heads were primed before trying to print) and I only get the last few lines of the t1 chart.

Half the time I try to print a calibration sheet, my UM3 insists on first lowering the right head, and then totally failing to extrude anything during the print. Or, on the rare occasion I can get it to print the left head's chart, it will then attempt to *raise* the right head and end up doing this: https://drive.google.com/open?id=1KY-CuhyAt7FI4ShHEz7ieyVXQ3sM9yY3 A reboot of the machine often convinces it to stop doing this. Sometimes it will say it's doing an auto-level but immediately continue with the calibration; when this happens, the print head gets pushed hard against the bed and nothing prints unless I manually pull the bed down. About 1 time in 6 I get a successful print of the left-head's calibration, but then it fails for one of two reasons: a- About half the time so far, it actively tries to raise, instead of lower, the right head. So, of course, the right head doesn't print anything. b- There seems to be a retraction that occurs resulting in the right head not extruding any material until the last half of the upper scale. Could probably be fixed by having a G280 or skirt line before the calibration print. Anyone had similar problems and managed to overcome them?

For the most part, when I print brim, it's just so I have something to help me get the scraper under the model. So a full brim around the entire model is usually just waste. Proposal: Provide an option that takes the degrees of brim coverage. "180" means that the "front" right and left of the model will have brim but not the back; "360" means the entire model; "0" means - why did you choose brim? Disables the option to print brim on the interior.

@sandervg

@SandervG Auto-level issues: Had my UM3 since 3/21. Things first went wrong for 3 weeks in, after I'd flipped the glass bed over the wrong way not knowing the two sides were different. Eventually I got so frustrated I went a week or so without using the UM3 and when I started using it again, I applied the latest update. I *think* I had actually also applied a firmware update just before I took my break. So Q: Did any of the others with autolevel failure have another firmware update shortly before this latest one?

Not sure if it's just me or if Prime Blob behavior changed recently: Instead of a little bullet/drop it produces a small base and a taller tower, and then the print head apparently tries to wipe the nozzle on the tower *and* prevent stringing by moving downwards and towards the print as it goes. At lower temps and with extra adhesion, I can generally get away with this, but most of the time what happens is that this knocks the blob over, catches it on the base of the print head/silicone nozzle cover and then enters one of a number of not-good scenarios. Mostly it just drags the blob into the print, other times it drags the string far enough to overlap some part of the print, or if the head moves slowly enough, it doesn't quite break the string before reaching the print and the print manages to yank the cooling prime out of the nozzle. Here's an example where I got lucky, the blob just sticks to the bed, but the nozzle left a long string 1/3 of the way across the plate to the build. http://www.kfs.org/oliver/images/um3-blob.mp4 Why do the wipe *towards* the print? Wouldn't it be better to do the wipe out to/past the edge of the bed and then come back? Why is the prime thinner at the top now?

[Edit: After looking at the CuraEngine code I see this is not controlled by Cura but by g280, so never mind] As you finish the prime blob, I think you try to wipe the nozzle on the blob by lowering the head. I think you then also try to avoid stringing the wipe into the print by going all the way do to the print bed with it as it starts to move away. In practice, for me, what this does is routinely squash the blob onto the print head and drag it off into the print. The "cut" part only works with perfect leveling at the blob corner. http://www.kfs.org/oliver/images/um3-blob.mp4

Print Head: 1, Buildtak: 0

@SandervG Is there a way for QA to leverage volunteered end-users for final bake testing? Unless you have hitl fuzzers, you're just never going to get that release-to-wild feedback until you release-to-wild(*) Perhaps you might consider providing them (QA) a means to have some small number of customers sign an NDA in exchange for "T-1" access to release builds with, potentially, specific test prints. -Oliver (* c.f: Engineer I worked with so vigorously and thoroughly tested a build across hundreds of internal build configs that he ultimately had to rush the release. First customer it encountered happened to be installing on a brand new machine that had never had the software installed before, and when he rebooted his machine an hour later, it wouldn't boot back up. The installer had tried to remove the previous installation, but it only caught *that* scenario if there was a record of where the previous entry had been. After that, it went ahead and deleted everything in the current directory, which was by default C:\... Hundreds of users had trashed their C:\ folder before the release was pulled)

Last firmware update killed auto-leveling with me, but apparently manual leveling comes with its own risks. TL;DR: Z-screw fell off during a print, and ultimately the glass build plate was thrown a good 2-3 feet out of the printer and onto the floor. Check the tightness of your z-screw if you are manual levelling. Not sure when it came off, I'd printed two of the same print previously so I didn't give it as much scrutiny this time. First it destroyed the $100 buildtak plate I'd mounted 10 days ago to compensate for the loss of auto-levelling; flicked the build-plate off and then started scarring up the heated plate element.

That seems to be the default, and this explains why I always wind up with the skirt line dragged into the model (UM3 Fast PLA config attached)

INTERN, INTERN! BLAME HIM! BLAME THE INTERN! 🙂

Had my UM3 for 6 weeks or so, and it was fine until leveling went wrong about 2 weeks ago, and once it went wrong, it went all the way. - I had autolevel set to always, - After the firmware patch my print success started feeling inconsistent, - I'd added UHU to a print where the most important layer had to be printed on the bed and raft/brim messed with it, - Adhesion had gotten worse and UM3 provides a painful, slow, experimentation cycle, so I'd flipped the bed over unaware that the two sides are different, - A large build of Colorfabb nGen had slipped and covered the printheads in ngen residue, forcing me to open the print head to get the cores out, - After reassembly not even my unaffected print cores (bb .4 and aa .25) could level, - Printing the X/Y calibration was impossible because the head was either too close or was dragging drips/strands/the print into the print and turning to mush, - The manual leveling process is an awful user experience. You should grandmother it (get family members of staff to come in and attempt to correctly manually level a printer: I challenge you), how much "some resistance" is turns out to be absolutely criticial, - During the fight between manual and autolevel I think I over loosed some of the screws, - The turn around time on making leveling adjustments to finding out whether you are within +/-0.05mm of correct extrusion is INSANE, - It took me about 5 attempts after the buildtak addition to piece together what was going on. a) I thought I'd turned off auto-leveling but it was back on - maybe I had done that thing where pressing the wheel counts as turning the wheel too, b) I was feeling for "resistance" as in a sense that the card was being dragged at rather than aiming for the barest hint that the card wasn't utterly free to move, c) The card isn't perfectly flat, and its hard to get it to be flat, d) auto-levelling can't handle buildtak, and it definitely can't handle flex plate, e) in my case, the calibration card was too thin, a 0.35mm piece of card that came with the shipping of something worked a lot better, What I don't get is why this problem isn't generally solved in 3d printing using a simple obstruction sensor? Hang an emitter and a receiver from the same axis the print core is from until you sense the bed interrupting the bottom of the receiver? The sensors/emitters can probably be bought off the shelf and you just send the output to the extant board, with the mounting parts, probably sell for $50-150, and voila customers have a way to obtain factory-fresh perfect auto leveling in a single pass. Or for $250-$350 you could put strips along the sides of the bed up by the home position: in a single scan you can do both leveling and obstruction checking -- you can confirm that nothing is in the way of the current layer and, at the end of the layer, after moving the head, that the print hasn't failed to adhere. You could even check for droop, etc, by checking that end-of-layer occlusion matches expectations...

I promised myself I wouldn't get into gcode or writing 3d printing tools, but then I always promise myself I won't get carried away writing "little" tools for games... After several days trying to get the print bed low enough that material *would* come out of the nozzle, a thought occurred to me: Is there a good reason to print a blob on the plate instead of purging the nozzle off the edge of the bed and wiping it? I realize you don't want to smack the delicate nozzle on the something hard and potentially sharp, especially not while it's hot. But isn't there a way to access the auto-level sensor through g-code so that a plugin could look for the edge of the bed and thus carefully move past it, purge, and then wipe the nozzle on the edge of the build pate?

OH. MY. GOD. I want to cry 😞 I was literally in the process of putting my UM 3 back in the box earlier this week after feeling so utterly betrayed when the printer started behaving like any-old $140 printer. But the real issue was I'd gotten *so* delighted with it, that to speed up my printing cycle, I had flipped the glass over to start a print on the other side. The first print had gone fine, and I forgot. But after that the printer went to absolute crap. The next print failed to adhere Colorfabb nGen, but not on the first few layers like you'd like. The result was a huge nasty blob of ngen which utterly covered both printcores(*). I couldn't get Printcore 1 off so I followed a guide to strip down the print head. I got most of the ngen off both heads, I survived re-assembly of the printhead with only stupid derps (I put all the power connectors back in r-to-l instead of l-to-r). But then I couldn't get any adhesion. I couldn't print the x/y calibration because either the head was too close and nothing came out, or the calibration just wouldn't stick and wound up wrapped around the print core (causing those little white pad things on the bottom of the print head to get sucked into a ball of filament while I was waiting for it to calibrate). I spent literal days messing with settings. When I did find settings that worked on the first layer, things went back to crap the instant I tried a real print - I think cura tries to wipe the nozzle on the prime blob, which used to work with the same temp/ultimaker filament but now routinely just drags the blob into the print; brim and raft are welded so tightly to the model I have to try and design them into the print because they're not coming off... The only thing I didn't think to try was to flip the god damn bed over. Fortunately, buildtak seems to have come to my rescue. But ... this is something you need to get to your users! Is there a way to permanently stain the bed? My sticker came off as I was inserting it into the printer the first time and then permanently the first time I cleaned the bed. (* They *touch wood* seem to be working now ... but there's definitely some evidence of deterioration :()

See my reply here: - Make sure you check the print core, under those soft-white tabs ... and on the back of the heating element, make sure you don't have gunk; - Don't mix manual and auto; - "Some resistance" is a really terrible description of what you are looking for 😞