Stream of I3V 12" Build Consciousness

[lakester]

(first: thx Dan..., will definitely check them out!)

I'm really happy with the way a recent project has turned out (and more than a little surprised that it actually worked out). This was the thing for which I've held up any additional modifications to the printer. It's also one of the things that served as "justification" (aka rationalization) for getting a 3d printer in the first place.

https://plus.google.com/118417197410...ts/R1uWe5RrFhk

Next up for the printer: some mods, and then on to some things related to the art aspect of my pottery work.

[Bredmond]

That is awesome! Great work, especially love the carpet sliders.

Bill

[lakester]

Thx Bill. It was a really satisfying project, made all the more so because it seemed so unlikely a month ago.

Getting the sliders to print was really the turning point, since it put doing something "real" with ABS within reach. And of the slider pics, totally unexpectedly, the one of the double foot slider is almost, for lack of a better word, touching. Strange how that happens.

That is awesome! Great work, especially love the carpet sliders.

Bill

[Renfro]

I had the same issue.

These M3 nuts are still driving me crazy (pun avoided)!

Last night I found out that my biggest problem with the prints was caused by the Y Idler not being secured. The nuts where all but impossible to remove or tighten! After 40 mins and almost breaking the wood parts we (four hands) where able to remove the nuts and replace with locally bought (good) nuts.

Didn't expect the lack of QC on this kit.

[lakester]

Sounds like you got past the problem. I agree with everyone else regarding the quality of certain components of the kit. The M3 nuts seem to be a significant "dis-satisfier"..., and if Colin fixed only that one problem (sure..., there are others), I think it would result in a useful improvement of folks' impression of product quality.

I dealt with the nuts by being VERY picky about whether I used them or not. If there was ANY indication that there was a potential for cross-threading (which is what I think bit you), I threw out the nut. The nut had to spin on easily, or it was discarded.

In the end, my attitude toward the MakerFarm kit is very definitely on the glass-half-full side of things. I would still recommend the kit to certain people, with the caveat that they have some appropriate mechanical skills and patience. In a weird way, I feel like some of the problems I had assembling the kit, that related to weaknesses in the kit, actually contributed to the final outcome of the printer working on the first try, because it forced me to slow down and think things through.

Just the same, for Colin and MakerFarm's sake, I hope that some modest product improvement is on their roadmap.

These M3 nuts are still driving me crazy (pun avoided)!

Last night I found out that my biggest problem with the prints was caused by the Y Idler not being secured. The nuts where all but impossible to remove or tighten! After 40 mins and almost breaking the wood parts we (four hands) where able to remove the nuts and replace with locally bought (good) nuts.

Didn't expect the lack of QC on this kit.

[lakester]

..., one step the other way.

Weird. I posted problems I was having with side-to-side adherence on the first layer with ABS.

Fiddled with first layer extrusion width settings, to no avail.

Should mention that apart from the first layer, print quality was pretty good.

THEN I decided to double check the condition of "things" with the printer. Yikes..., really loose x-carriage and HE/bed gap that had gone way way wide.

So this was a good time to make some other fixes and small upgrades. When the dust settled, I had:

• Tightened the x-carriage..., pretty dang tight. Seems to roll OK.
• Fixed a bogosity with the y-min stop related to MF switching to a roller type microswitch that didn't really properly engage with the standoff on the bed.
• Added a y belt tensioner: http://www.thingiverse.com/thing:612584
• Re-leveled the bed and got HE/bed clearance back to the draggy-sheet-of-paper state.

I then re-printed a problem part. "Banjo" problem fixed. Hurray! Post-cooling warping fixed. Hurray!

New printing artifacts introduced. BOOOO!!!

The harmonic wavvies are somewhat worsened.
Blobbing has appeared, possibly near retract points..., not sure yet.

It's really odd. In some ways, the overall geometry is sharper and better controlled, but at the cost of localized printing artifacts.

So now gonna spend some time researching problems with things when they're too tight. Except I don't think they're too tight. Grr.

Will probably try printing some test articles to see if they bird-dog anything useful.

[lakester]

Haven't had any time to look into the problems introduced by the most recent "improvements". No biggie.

FINALLY had a chance to use one of the dies (aka cookie cutters) I've created for use with pottery.

It sorta worked..., but didn't produce the time savings I was hoping for. I think there are some additional refinements to the tool design that will help, so we shall see. But along the way...

I've spent a lot of quality time with OpenSCAD.

From my experience thus far, what it is good at it is really good at. But..., if you get anywhere near anything that it isn't good at, you hit the wall hard.

Most telling are the various tech discussions on various OpenSCAD related topics..., and the thing they seem to struggle with: can a functional language effectively solve the problem being discussed. Often times, regardless of whether or not A solution is POSSIBLE, in any practical sense, the answer is "no" (at least with OpenSCAD). Some significant problems can't be naturally/comfortably solved within the confines of the language without either significant alteration to the language or the implementation of a black box module that ya just don't wanna know how it works.

The discussion regarding the means by which one can compute a bounding box is an excellent example of the problem. Sorta ironically, one common workaround is to use some other language to generic canonic OpenSCAD. I'm still conflicted as to whether to consider that an "insight" or "damnation".

So..., despite my previous rants, and with a little trepidation, I guess I'm gonna spend some time with FreeCAD scripting to explore other ways of processing various bits of art related design.

If FreeCAD's "bug density" turns out to nix that avenue of exploration, then I'm gonna finally bite the bullet and begin the long long long long long long (are we to Pluto yet?) journey with Blender.

[lakester]

I've been working on a fast path from outline drawing to die tool or cookie-cutter suitable for use with clay pottery.

Inkscape is the tool I use to create the original outlines.

I finally had reason to generate some vector/outline shapes that originated in image data.

The process of line detection or vectorization is imperfect. Depending how one has tuned what are primarily image filters, shapes may be included in the initial vector product that ya don't want in the final product.

Inkscape primarily implements the SVG drawing model.

This means that when you want to crop/clip something out of a drawing..., you effectively create a stored clipping operation.

This does not modify the underlying drawing..., but merely manipulates your view of it.

Part of my "process" involves exporting the drawing to DXF format. Unfortunately, there is no analogous operation that Inkscape understands to produce the "clipping" effect..., so..., Inkscape just simply dumps all vector data to the DXF.

Which means the thing ya didn't want..., ya get anyway.

So..., "word": before you run the "Trace Bitmap" operation in Inkscape..., and if you plan to export it to DXF, then:

• Either be ready to do "edit nodes" prior to the DXF export, or...,
• Try to make sure the image you're vectorizing is as clean as possible.

Heh..., but once you've done that, remember: 3d printing is still pretty dang cool.

[lakester]

So there I was, sitting in the next room, and I hear a soft <snap-tinkle-tinkle> from the direction of the 3d printer sitting in the other room.

I check it out, and, just sitting there, not having done anything for around 48 hours, the PLA filament between the spool and extruder had snapped.

The machine had been in the home position.

I was aware that the PLA had started to become brittle..., but it had been printing OK, so I shrugged and went about business.

What's odd is that the separation point was at a position I would have considered to have the least tension or stress on it of the entire arc of filament between the two end points.

This may be my cue to try one of the hokey re-conditioning methods I've read about, and possibly to get in the habit of zip bagging my PLA spool w/ dessicant during even fairly short periods of non-use.

---

In other news..., I keep hitting what seems to be a recurring theme: incompatibilities between various 3d/drafting/drawing/processing systems at the file interchange level.

Every time I find a way I like to do something with software module "A", and want to pass it along for additional processing by module "B", using some file format or another e.g., DXF or STL, nagging problems arise that shoot down the entire effort.

In this case, it would be nice to use FreeCAD's 2D drafting abilities, and perform some additional operations upon the results using OpenSCAD. FreeCAD's OpenSCAD integration isn't really what I'm looking for, or at least it doesn't seem to be (to be honest, I'm not quite sure I get the point of that integration as it now stands..., so maybe I need to give it a harder look to make sure I'm not missing something). I'd much rather treat the two as independent steps in a pipeline rather than try to grok whatever it is that FreeCAD thinks it's trying to accomplish with its OpenSCAD integration.

Sigh..., oh look..., there's a road sign up ahead. "Next Exit: Blender"

Yeah..., I know..., I've said that before. But one of these days Alice..., one of these days...

[lakester]

Not much new to "report"...

Have been playing around w/ Slic3r 1.2.9 a bit. Unfortunately, it's a little prone to seg faults with things that work with 1.1.7.

OTOH..., significant performance work appears to have been done, which puts it more in line with other slicers.

FWIW..., Using 1.2.9's "Repair STL" operation does seem to take a seg-fault-causing STL and successfully turn it into a useable OBJ file.