[Arm-netbook] Existential 3D Printing Moments

On Thu, 18 May 2017 22:02:03 -0400

On Thu, May 18, 2017 at 8:42 PM, Luke Kenneth Casson Leighton

<snip>

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?

<snip>

I was just researching browser memory usage for myself.
The best one is opera, which is rather shocking (chromium does not open
all the files, this seems to be due to an internal load limiter or
timeout.):
482 local html pages with JS disabled:
Opera 12
1024MiB
Chromium
~2000MiB

The story gets worse with FF, way worse (and the time it takes FF to
render, OMG!)

David

_______________________________________________
arm-netbook mailing list arm-***@lists.phcomp.co.uk
http://lists.phcomp.co.uk/mailman/listinfo/arm-netbook
Send large attachments to arm-***@files.phc

Luke Kenneth Casson Leighton

2017-05-30 02:51:01 UTC

---
crowd-funded eco-conscious hardware: https://www.crowdsupply.com/eoma68

Post by d***@mail.com
On Fri, 19 May 2017 01:42:52 +0100
<snip>

Could you be more specific? Why can't the arduino cope?

there are more experienced people who know the precise details.
bottom line: an 8-bit 16 mhz processor is simply not fast enough to be
able to send the data to the stepper motors in a way that they will
remain properly synchronised.

example: X axis gets changed direction/speed, and Y needs to be
changed at the exact same time. but because it takes e.g. 50uS (0.05
ms) to get round the "compute" loop, the print head has moved on (say)
0.2mm in that time, it's going so fast, so X and Y are no longer
properly synchronised.

only by going to a 32-bit processor running at say 100mhz can you get
the timing synchronisation back.

Link?

google it please.

Torque for what?
Again, maybe a link would help us stay on the same page.

google them, please. i have a lot else to take care of.

none of this stuff i knew about, the 18 months before i began
designing the laptop's parts. oh well.

well, if you are only looking to print a few trinkets at below 50 mm
/ sec then whatever you have is perfectly fine.

if on the other hand you're looking for something that you intend to
take seriously, then yes you have been through an important learning
experience.

actually after looking at the design of TMC2100 postage-stamp-sized
driver boards, i believe these may actually be okay. in these
particular boards they've put the TMC2100 *ON THE OTHER SIDE OF THE
PCB*. what that means is that you can put a heatsink on the TOP of
the PCB, where it will actually be effective at taking heat away.

l.

_______________________________________________
arm-netbook mailing list arm-***@lists.phcomp.co.uk
http://lists.phcomp.co.uk/mailman/listinfo/arm-netbook
Send large attachments to arm-

David Niklas

2017-05-30 20:02:05 UTC

On Tue, 30 May 2017 03:51:01 +0100

Post by Luke Kenneth Casson Leighton
---
crowd-funded eco-conscious hardware: https://www.crowdsupply.com/eoma68

Post by d***@mail.com
On Fri, 19 May 2017 01:42:52 +0100
<snip>

Could you be more specific? Why can't the arduino cope?

there are more experienced people who know the precise details.
bottom line: an 8-bit 16 mhz processor is simply not fast enough to be
able to send the data to the stepper motors in a way that they will
remain properly synchronised.
example: X axis gets changed direction/speed, and Y needs to be
changed at the exact same time. but because it takes e.g. 50uS (0.05
ms) to get round the "compute" loop, the print head has moved on (say)
0.2mm in that time, it's going so fast, so X and Y are no longer
properly synchronised.
only by going to a 32-bit processor running at say 100mhz can you get
the timing synchronisation back.

I understand now. I thought that the arduino was faster...

david crocket (dc42) has specifically designed the duet series so
that you can consider exceeding PWM rates of 150 khz, which is what
you need if you want to sustain 500mm/sec for example (and do not
want problems to occur at speeds well below that).

Link?

google it please.

This looks like it:
http://forums.reprap.org/read.php?147,33082,471483

also i forgot to mention that i've been using the E3Dv6 "volcano"
which, when you use a 0.5 to 0.8mm nozzle can easily do flow rates of
something mad like.... 200c^3/min - particularly when combined with
the huge 40:1 gearing of the flex3drive which can *accurately*
deliver the kinds of torque needed. the volcano basically turns the
heat chamber round, so that the heat area is 20mm long instead of
the usual 10mm.

Torque for what?
Again, maybe a link would help us stay on the same page.

google them, please. i have a lot else to take care of.

<snip>

I thought you were waiting for the PCBs to get done (which was going to
take another week I think), and had nothing better to do than play with
that oh-so-giggly-and-fun little girl in the youtube vids?

Thanks,
David

_______________________________________________
arm-netbook mailing list arm-***@lists.phcomp.co.uk
http://lists.phcomp.co.uk/mailman/listinfo/arm-netbook
Send large attachments

Luke Kenneth Casson Leighton

2017-05-31 04:45:18 UTC

Post by David Niklas

Post by Luke Kenneth Casson Leighton
only by going to a 32-bit processor running at say 100mhz can you get
the timing synchronisation back.

I understand now. I thought that the arduino was faster...

neeeh. they're.... well... not very good, basically. also the
arduino base code.... *sigh* it does timing loops to get accuracy by
hand-coding them in assembler with NOOPs (no operation).

as a programmer, you know what that means... :)

Post by David Niklas

david crocket (dc42) has specifically designed the duet series so
that you can consider exceeding PWM rates of 150 khz, which is what
you need if you want to sustain 500mm/sec for example (and do not
want problems to occur at speeds well below that).

Link?

google it please.

http://forums.reprap.org/read.php?147,33082,471483

yehhh that'd be about right - a good example, and really highly
technically informative and insightful. good find.

Post by David Niklas