[Arm-netbook] Existential 3D Printing Moments

[Neil Jansen]

On Thu, May 18, 2017 at 8:42 PM, Luke Kenneth Casson Leighton <lkcl at lkcl.net>
wrote:

>  btw apologise i should have said, the conversation with aleph objects
> was private and not to be announced, they haven't given permission to
> do that, as they are *considering* and we are *assessing* - privately
> - the feasibility.

My apologies, the phone was breaking up a bit during the first bit of all
that.  Feel free to delete my reply or any others that reference it.  This
is a pretty low-key mailing list so either way I don't think much will come
of it.  Mostly a miscommunication on my part, for which I apologize.


>  a couple of things i forgot to mention, one is to emphasise the
> "bang-per-buck" part.  [...]
> this kind of design assessment trick i've only ever heard being used
> by people who make beowulf clusters, the word "cluster" being the key
> word.

Those are fun problems to solve.  You're right that there are a lot of
variables, and many different approaches.  And if you've got a few
important criteria like cost or time, it's easy enough to weed out the bad
ones.

Speaking of Beowulf clusters .. Not to go too far off topic, but has anyone
given any thought to a Beowulf cluster of EOMA68's?  I only ask because if
Intel and AMD are including so much proprietary crap between you and the
processor, it's only a matter of time before other alternatives become
important.  The way I see it, the current Allwinner based EOMA68's are
great for doing what a tablet or netbook can do, but it's not going to
replace my workstation with 16GB of RAM (which I run out of probably weekly
before needing to restart, but that's another story .. Windows and Chrome,
I have no one to blame but myself there).  Anyway, assuming that the Linux
kernel could scale to maybe 8-16 of these little cores, and being that
they're all upgradeable, it actually seems like it could become a neat
alternative for workstation usage.  I don't even see where cost would be
that prohibitive, as workstations actually get pretty expensive often
surpassing $1000 USD.  Are there any hard realities that would prevent the
EOMA68 from working in this fashion?  Any bandwidth issues or technical
limitations?


>  unfortunately, most 3d printers are simply not designed in the west
> around "clustering".  they just aren't designed *and marketed* as
> "maximising the print output for the money".

They're designed and marketed to be a semi-hackable appliance that sits on
the corner of your bench or in an office environment.  They're certainly
not intended to be clustered.

Funny story though, our open source SMT pick and place was intended to do
3D printing, and we were intending for them to be clustered.  Too
complicated for our small team, but we were laying the ground work down
regardless.  Our team was so small that we had to throw out 3D printing
altogether and concentrate on the minimum viable product, which was SMT
pick and place, solder paste dispense, and reflow.  Even that kicked our
ass.  Our mentors wanted us to put a conveyor belt on it but we just
couldn't do it in the time allotted.  Robotics is hard with a small team,
regardless of how small or simple the machine is.

> in china that's probably
> a totally different matter, so i'll look up the wanhao duplicator
> later (lead appreciated, neil).

They run printer farms of Wanhao Duplicators in China, I've seen them.

How do they do it?

Labor is cheap.  Machines are cheap.  They make it work.  I think that's
all I need to say :)


>  * mendel90 - i've had mine running at 200mm/sec (yes, really,
> 200mm/sec *print* speed and a 250mm/sec travel speed).

I should have covered print speed in my last email.  You would be surprised
at how slowly we printed during our production run.  We ran them real nice
and slow, less than 100 mm/sec.  Going back to bang-for-buck, this was how
we approached the problem.  Lots of slow-ish machines, rather than a few
very expensive fast machines.  It worked out for us.

Here are a few pics of our farm in the early stages.  Don't laugh; they
worked well.  I'll see if I can dig up some more pictures later.

* http://i.imgur.com/56F2nYP.png
* http://i.imgur.com/8cXbl72.png

>  cost is around $500 so 2500 / 500 = 5.  5 x 200mm/sec = 1000 mm/sec

By that logic, our machines were comparable to that.  Slower, cheaper, but
the math works out.  And if I built them today (and in China/Taiwan),
they'd be cheaper and I could probably eek some more out of them.  Getting
bigger beds on them isn't impossible either .. we had an identical one at
our makerspace but with a 200mm x 400mm bed with longer rods.  Basically a
double-MK2B bed.



> what i am looking at therefore is parts which will get me sustainable
> speeds that the MendelFlex can reach, but without the pricetag of an
> Ultimaker-2, MendelFlex or Lulzbot Taz 6.

I still propose that you could do cheaper / slower machines and still hit
your speed requirement overall.  But if I go along with your thinking, why
can't you just build a bunch of MendelMax / MendelFlex /
whatever-you-call-them over there in Asia?  20mm x 20mm Extrusion like that
is RIDICULOUSLY cheap.  If you DIY over there period, you'll hopefully find
that the extrusion and hardware will be pleasantly cheap.


> now, neil, this is the kind of speed at which an arduino 2560 *cannot
> cope*, and, also, where the design flaws inherent in RAMPS - using
> prototyping Evaluation Boards (polulu-style drivers) - start to show
> up.

Yea but Arduino 2560's and RAMPS boards are MUCH cheaper than anything with
an ARM Cortex.  That was kinda what I was getting at.  There's a brick wall
that you hit when you want to go that fast.  You'll need a better motion
control system, more rigidity, better everything really.  All of that adds
up, especially when you're building so many of them.  What's great about
the RAMPS boards, the Arduino clones, and all that, is that they're
incredibly cheap.  You could probably buy a dozen for the price of a single
"bleeding edge" type ARM Cortex motion controller.  What I'm arguing is
that you shouldn't discount slow if it's cheap.  You'll have less jams,
less filament issues in general, because you're not pushing the hotend and
extruder as hard.  If something breaks, well shit, replace it and don't
sweat it.

As a car analogy, think of a Formula 1 car running in a Le Mans type race.
It would probably do OK for the first few laps, but the risk of it breaking
down over 24 hours is much higher.  Slow and steady and reliable wins
here.  Le Mans cars aren't pushed into the red like an F1 car is.  They're
cheaper too.  A team can race a fleet of Le Mans cars for the price of F1
cars.  If one makes to the end, they still win.  If that one F1 car breaks
down or crashes, they win nothing.  Not a perfect analogy, but you get the
idea hopefully.


>  it's no surprise.  makerbot was secretly patenting public domain
> discussions from forums and pissed *everybody* off.  the engineers
> know it, and it's not that uncommon for employees to subconsciously
> "self-sabotage".

One of our mentors was an early Makerbot employee that left.  Man, the
stories from that place.  I'm glad that it's going tits up.


>  i loove their colours :)

Me too, however I do wish that they (or someone else) would make a decent
Olive Drab Green.


>  i'm really really happy to hear of (and then test) known filaments
> that are of the same quality... particularly if they have the same
> kinds of eye-popping colours.

Our production runs used PushPlastic exclusively:
https://www.pushplastic.com/  USA made, virgin plastic, constant thickness
filament, yada yada .. They've got more experience than most and they're
finally getting decent non-primary colors.  Not faberdashery level or
anything .. but enough to keep me happy.  There are many others too.  That
was just who we happened to use (well, who I happen to use to this day).


>  welcome to the list neil.  really good talking with you.

Likewise.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.phcomp.co.uk/pipermail/arm-netbook/attachments/20170518/c6e46d33/attachment-0001.html>