Forum for core development team. (Current dev team discussion is not world-readable; the mailing list connection to this forum needs to be reactivated.) http://dev.forums.reprap.org/list.php?2 Sat, 21 Nov 2009 04:45:44 -0800 Phorum 5.2.11 http://dev.forums.reprap.org/read.php?2,28430,28430#msg-28430 http://dev.forums.reprap.org/read.php?2,28430,28430#msg-28430 Forrest Higgs Developers Fri, 09 Oct 2009 07:30:52 -0700 http://dev.forums.reprap.org/read.php?2,10551,10551#msg-10551 http://dev.forums.reprap.org/read.php?2,10551,10551#msg-10551
I think we should start by making this mirror the current twiki.

Then move to it as the main server, with Simon's server acting as the mirror.

The we need to migrate the forums.

In parallel I think we should have a Builder's wiki to go with the Builder's blog that is world writable; lots of people are a bit wistful that we don't let them edit the main wiki, and they deserve a voice.

Then (long term) we should think about moving to mediawiki. Though I like the clean appearance of twiki. And I understand the latest version has a wysiwyg editor, which would go a long way to making it pretty good, I reckon.

I think we should put capchas on everything from day one, too.]]> Adrian Bowyer Developers Wed, 26 Mar 2008 14:33:06 -0700 http://dev.forums.reprap.org/read.php?2,10548,10548#msg-10548 http://dev.forums.reprap.org/read.php?2,10548,10548#msg-10548
But there's a downside to having lots of ideas and lots of versions of things: the core team is dedicated, but also few in number. I want to keep it few, too, for the time being, as increasing numbers makes more administration than it supplies useful work.

So - what's the best way to square the circle of encouraging lots of variation for natural selection to work on, and actually knowing what _we're_ working on? :-)]]> Adrian Bowyer Developers Thu, 27 Mar 2008 02:06:49 -0700 http://dev.forums.reprap.org/read.php?2,7203,7203#msg-7203 http://dev.forums.reprap.org/read.php?2,7203,7203#msg-7203 Developers mailing list
Developers@reprap.org
[reprap.org]]]> ZachHoeken Developers Mon, 10 Dec 2007 17:17:44 -0800 http://dev.forums.reprap.org/read.php?2,7202,7202#msg-7202 http://dev.forums.reprap.org/read.php?2,7202,7202#msg-7202 Developers mailing list
Developers@reprap.org
[reprap.org]]]> ZachHoeken Developers Mon, 10 Dec 2007 14:23:26 -0800 http://dev.forums.reprap.org/read.php?2,7201,7201#msg-7201 http://dev.forums.reprap.org/read.php?2,7201,7201#msg-7201
> If we're going to improve the whole issue of handling debug and error
> output (which is definitely a good idea!), wouldn't it make more sense
> to use either log4j or the JDK Logger class from java.util.logging.* ?
> My suggestion would be log4j. That way, people can rotate log files,
> divert the messages to syslog or the Windows Event Viewer, or send them
> across the net to a remote machine, or do more or less whatever they
> want with the log output. We could make comms debug output and other
> debug output be different priorities, and then users can configure
> things to send one to syslog and another to the console, cause loud
> sirens and flashing lights if an error occurs, etc. etc. ... all without
> changing our code.

You're probably right; as usual it was quicker for me to write the code
than to find what else was out there...

I see log4j stores times to the ms. I suspect that the [t/delta-t]
thing that my code does will be quite useful (certainly to me ...). I
can't see how to get that out of jog4j, but maybe I haven't looked hard
enough.

--

Best wishes

Adrian

Dr Adrian Bowyer
[staff.bath.ac.uk]
[reprap.org]
_______________________________________________
Developers mailing list
Developers@reprap.org
[reprap.org]]]> Adrian Bowyer Developers Mon, 10 Dec 2007 14:14:36 -0800 http://dev.forums.reprap.org/read.php?2,7200,7200#msg-7200 http://dev.forums.reprap.org/read.php?2,7200,7200#msg-7200 Developers mailing list
Developers@reprap.org
[reprap.org]]]> ZachHoeken Developers Mon, 10 Dec 2007 12:59:35 -0800 http://dev.forums.reprap.org/read.php?2,7199,7199#msg-7199 http://dev.forums.reprap.org/read.php?2,7199,7199#msg-7199
I got asked "what our current status" was again.

What would you guys say to a single line strip banner, ticker tape style, at
the top of our home page for immediate view...

E.g. STATUS: Currently preparing the first release. Tuning printing
parameters.

It would placate plenty of perusers (and perhaps look quite exciting).

eD

_______________________________________________
Developers mailing list
Developers@reprap.org
[reprap.org]]]> EdSells Developers Mon, 10 Dec 2007 12:57:23 -0800 http://dev.forums.reprap.org/read.php?2,4913,4913#msg-4913 http://dev.forums.reprap.org/read.php?2,4913,4913#msg-4913
If you want to help the project purely on the software side (all you need is one (1) computer...) and think you could do some of these conversions, please see that blog entry.]]> Adrian Bowyer Developers Sat, 08 Sep 2007 08:57:16 -0700 http://dev.forums.reprap.org/read.php?2,4620,4620#msg-4620 http://dev.forums.reprap.org/read.php?2,4620,4620#msg-4620 Developers mailing list
Developers@reprap.org
[reprap.org]]]> ZachHoeken Developers Tue, 28 Aug 2007 06:39:58 -0700 http://dev.forums.reprap.org/read.php?2,4557,4557#msg-4557 http://dev.forums.reprap.org/read.php?2,4557,4557#msg-4557 > change-one-thing-at-a-time theory - so could someone else put these
> threshold values right? (see attachment) This presumably means Andreas
> has progressed to extruding plastic...

The lower threshold is a workround for a bug. The extruder controller
returns a low temperature value if the temperature calculator gets an
interrupt as it's doing its count (I think). We really need to fix
this, then we could put the threshold back to a sensible value. But
more urgently we need to get all the firmware working with the latest
SDCC and put a buffer in for draw-a-line commands (in progress...).

The threshold problem doesn't manifest itself with polycaprolactone, as
that doesn't much care what temp it's at as long as it's warm. HDPE is
a different matter, of course. If you put the threshold back high,
then the temp bug causes the machine to return to it's heating-up spot
all the time unnecessarily.

A work round for the work round :-( would be to make the threshold
function take a majority vote amongst it's last three (or five, or
w.e.) temperatures.

Best wishes

Adrian

Dr Adrian Bowyer
[staff.bath.ac.uk]
[reprap.org]
_______________________________________________
Developers mailing list
Developers@reprap.org
[reprap.org]]]> Adrian Bowyer Developers Mon, 10 Dec 2007 10:03:51 -0800 http://dev.forums.reprap.org/read.php?2,4516,4516#msg-4516 http://dev.forums.reprap.org/read.php?2,4516,4516#msg-4516 Developers mailing list
Developers@reprap.org
[reprap.org]]]> ZachHoeken Developers Wed, 29 Aug 2007 16:36:52 -0700 http://dev.forums.reprap.org/read.php?2,4508,4508#msg-4508 http://dev.forums.reprap.org/read.php?2,4508,4508#msg-4508 hopper feed of granules? That was the next step that I wanted to take
with our filament extruder (details here:
[reprap.org]).

I'm impressed that you can get the torque needed from a stepper. Do you
also need the precision? (For a possible cheaper alternative, see here:
[reprap.org]). Or would just an ordinary DC
electric motor do?

If you are using EVA then you must try polycaprolactone - that melts at
about the same temperature, but has the mechanical properties of nylon
when it's solid. It's much more rigid. I have a small amount in
granular form. Let me know how many grams you'd need to try the
experiment and, if I have enough, I'll airmail it to you free of charge.

Best wishes

Adrian

Dr Adrian Bowyer
[staff.bath.ac.uk]
[reprap.org]

Evan Malone wrote:
> Tim,
> Great news - I'm very happy to hear that you have had success! By the way,
> Dr. Adrian Bowyer of the RepRap project in the UK (www.reprap.org) has
> been interested in seeing a RepRap screw extruder integrated with a
> Fab@Home chassis. Your work is very much along these lines. I've cc'd
> him here. Perhaps you can explain your experiences integrating your screw
> extrusion tool with him?
> Also, may I impose upon you, when you have time, to contribute to the
> Fab@Home wiki? It would be wonderful if you would create a page
> describing your tool design and integration linked from the "Deposition
> Tools" pages. Also, if you have any information you could contribute to
> the user manuals, we could really use the assistance.
>
> Best wishes, and I very much look forward to the photos (and video, if you
> can provide it)!
>
> Evan
>
>
>> Evan,
>>
>> We will update you with photos of our machine on the Fab@Home website ASAP
>> but
>> just to let you know we have successfully built our first few models.
>>
>> Using EVA copolymer (hot melt glue) in the heated cylinder being deposited
>> using the screw extruder driven by a stepper motor had great results. Due
>> to
>> the 0sec layer wait and the speed at which this material was able to be
>> deposited, we were able to make the pyramid at 3x scale in approximately
>> 25mins with excellent accuracy for an uncalibrated machine initial trials.
>> The
>> hard finish is great.
>>
>> Over the next few days we will further calibrate the machine and hopefully
>> construct some impressive models to be posted.
>>
>> As using this screw extruder is a continuous process we have no need to
>> stop
>> the machine for pauses and with our added hopper can make large models
>> unattended however should we still insert pauses in the fabrication
>> process so
>> the x and y motors dont overheat or simply add small computer cooling fans
>> to
>> them as we have with the deposition motor or should we not require any
>> pausing
>> for the x,y motors at all?
>>
>> Thanks for your time,
>>
>> I look forward to posting the initial pictures.
>>
>>
>> Regards,
>>
>> Tim Nixon
>>
>
>


--


_______________________________________________
Developers mailing list
Developers@reprap.org
[reprap.org]]]> Adrian Bowyer Developers Fri, 24 Aug 2007 02:08:09 -0700 http://dev.forums.reprap.org/read.php?2,4369,4369#msg-4369 http://dev.forums.reprap.org/read.php?2,4369,4369#msg-4369
[reprap.org]

They are all linked from the 'Documentation' page. I'll try and get the rest up soon.]]> ZachHoeken Developers Tue, 21 Aug 2007 07:48:40 -0700 http://dev.forums.reprap.org/read.php?2,4364,4364#msg-4364 http://dev.forums.reprap.org/read.php?2,4364,4364#msg-4364 Developers mailing list
Developers@reprap.org
[reprap.org]]]> ZachHoeken Developers Wed, 15 Aug 2007 14:07:00 -0700 http://dev.forums.reprap.org/read.php?2,4240,4240#msg-4240 http://dev.forums.reprap.org/read.php?2,4240,4240#msg-4240 > This is probably a stupid question, but wouldn't it be more efficient to use a star network instead of a ring? That way the message would go directly to the pic in question and back instead of doing the rounds of all the other pics on the ring. It would seem, anyway.
>

The most efficient way to do it would probably be a bus, which might be
what you're suggesting. For a long time now there has been a plan to
migrate to an i2c bus. We ended up using serial as an interim
get-up-and-running-quickly approach. Not only will i2c be faster that
the async serial in terms of bits per second, there is no propagation
delays that depend on the number of nodes in the network.

_______________________________________________
Developers mailing list
Developers@reprap.org
[reprap.org]]]> sai Developers Mon, 06 Aug 2007 06:27:45 -0700 http://dev.forums.reprap.org/read.php?2,4177,4177#msg-4177 http://dev.forums.reprap.org/read.php?2,4177,4177#msg-4177 :

>> We'd also have to change that so that the host still tells X it's
>> the master,
>> but then _X_ tells Y it's the slave (the ring should make that
>> trivial to do).
>
> It's doable, but it might be simpler if X tells the host "I'm done
> being master" (in the same packet it tells the host that move is
> completed?) , and then the host tells Y to be master? That way the
> host is in some sense more "in control" of the action, and
> (significantly!) CommDebug will show all that action for
> troubleshooting. If we have PICs talking among themselves, as you
> propose, we'll need a "network monitor" board that sniffs every TX
> output at high impedance, or something, just so we can get a network
> traffic capture of all traffic...

The problem with that is this situation: X is master and is drawing
line 1. It also has line 2 buffered internally waiting to go. X has
told Y that Y is the slave. X finishes line 1. It queues up a
"finished line 1" packet to the host and immediately starts drawing
line 2 with Y still the slave as before. No traffic at all has to go
round the ring between the end of line 1 and the start of line 2, and
that is the ideal we want to achieve.

The "finished line 1" signal ambles round the ring in a leisurely
fashion as line 2 is being drawn, and the host then sends a "draw line
3" packet to X, the transmission speed of which is equally
non-time-critical.

The alternative (and this is probably even better) would be that when
the machine is initialised the host tells X it's the master and Y it's
the slave until further notice. I think in practice, though any PIC
could become master in principle, the host would always tell X to be
master for an entire run. That way there is no inter-PIC comms (which,
as you quite rightly say, would be a real pain to debug).

> BTW, this change will probably make Eric M. very happy, since it
> appears that the delays between segments are a major issue for his
> machine at the moment!

Yes - Ed's stalled too on refining the parameters for Darwin, as fixing
this problem will make all lines a lot smoother, and - until that
happens - there's no point in trying to find maximum reliable plotting
speeds and the like.

Best wishes

Adrian

Dr Adrian Bowyer
[staff.bath.ac.uk]
[reprap.org]
_______________________________________________
Developers mailing list
Developers@reprap.org
[reprap.org]]]> Adrian Bowyer Developers Sun, 05 Aug 2007 13:51:19 -0700 http://dev.forums.reprap.org/read.php?2,4152,4152#msg-4152 http://dev.forums.reprap.org/read.php?2,4152,4152#msg-4152
One problem is that Simon's code is wonderfully and elegantly symmetrical: if dx > dy for a move, the X controller is master and the Y is slave; contra contra. But this gives a problem when one move is finished and the master needs to stop being X and become Y - the buffer has somehow to switch between the two.

Proposal: any controller can be the master for any move. So, if X (say) is master and dx > dy, then X steps x a few times, then sends a slave pulse to Y to step y once, and so on. But if dy > dx X still sends out the sync signals - it just sends more to Y than it does "to itself". At the moment, I think the host tells X it's the master and Y it's the slave (or vice versa). We'd also have to change that so that the host still tells X it's the master, but then _X_ tells Y it's the slave (the ring should make that trivial to do). That way, X (or Y, but not both) can just pull things to do off its buffer and do them ad infinitum.

I don't think this'll be a big code change at all, and all the programs for all the axes will still be identical. But the host will be able to make many moves just by talking to one controller repeatedly, so that controller can buffer them up.

Is now the moment to add the extra sync line and have complete symmetry between X, Y and Z so the machine can move in any straight line in 3D?]]> Adrian Bowyer Developers Fri, 03 Aug 2007 19:42:49 -0700 http://dev.forums.reprap.org/read.php?2,3861,3861#msg-3861 http://dev.forums.reprap.org/read.php?2,3861,3861#msg-3861 new versions of sdcc and for the 16f648a.

It is in subversion at
/reprap/branches/autoconf-firmware

In order to build this, you need to have a very recent version of
gputils. To determine if you have a recent enough version, run the
command "gpasm -v". You should see "gpasm-0.13.4 beta" or higher
(actually there is currently nothing higher, but no doubt there could be
soon).

To build an appropriate version of gputils, you need to check it out
from CVS.

You should also build sdcc from subversion.

When you install sdcc, make sure it's pointing to your newly compiled
gpasm and gplink, not some old copies. You can verify which instance of
gpasm sdcc is using by compiling something with -V. Or, if you're
unsure how to do that, do something like this to print the gpasm path
that sdcc is using (all one line):

echo "void main(){}" > tmp.c && sdcc -V -c tmp.c | grep gpasm | sed
's/^\+ "\([^"]*\)".*$/\1/' && rm tmp.c

The firmware is configured with autoconf, so to build it you do the
normal gnuey thing:
./configure
make

Here's a complete command-by-command walkthrough for building everything
current. This can be executed by a normal user (no root privileges
required).

1. Build gputils
mkdir $HOME/reprap-tools
cd $HOME/reprap-tools
cvs -d:pserver:anonymous@gputils.cvs.sourceforge.net:/cvsroot/gputils login
(just press enter when prompted for a password)
cvs -z3
-d:pserver:anonymous@gputils.cvs.sourceforge.net:/cvsroot/gputils co -P
gputils
cd gputils
./configure --prefix=$HOME/reprap-tools
make
make install

2. Build sdcc
cd $HOME/reprap-tools
svn co [sdcc.svn.sourceforge.net]
cd sdcc
./configure --prefix=$HOME/reprap-tools --disable-mcs51-port
--disable-gbz80-port --disable-z80-port --disable-avr-port
--disable-ds390-port --disable-ds400-port --disable-xa51-port
--disable-hc08-port --disable-ucsim
make
make install

3. Build reprap firmware
mkdir $HOME/reprap
cd $HOME/reprap
svn co
[reprap.svn.sourceforge.net]
cd autoconf-firmware
PATH=$HOME/reprap-tools/bin:$PATH
./configure
make

The output files will be located in
~/reprap/autoconf-firmware/devices/stepmotor/stepmotorx.hex
~/reprap/autoconf-firmware/devices/stepmotor/stepmotory.hex
~/reprap/autoconf-firmware/devices/stepmotor/stepmotorz.hex
~/reprap/autoconf-firmware/devices/extruder_0/extruder0.hex
~/reprap/autoconf-firmware/devices/extruder_1/extruder1.hex
etc...

_______________________________________________
Developers mailing list
Developers@reprap.org
[reprap.org]]]> sai Developers Wed, 19 Dec 2007 12:16:20 -0800 http://dev.forums.reprap.org/read.php?2,3784,3784#msg-3784 http://dev.forums.reprap.org/read.php?2,3784,3784#msg-3784
i just released the Cartesian Bot, as well as the Thermoplast Extruder at v1.0 on sourceforge. they contain the STL files, as well as any accumulated extra stuff like the instructions Joost has created or drawing files, etc.

if anyone has extra stuff they would like to see in the downloads, please let me know.]]> ZachHoeken Developers Tue, 24 Jul 2007 03:53:14 -0700 http://dev.forums.reprap.org/read.php?2,3773,3773#msg-3773 http://dev.forums.reprap.org/read.php?2,3773,3773#msg-3773
But it does mean a design change at this late stage. What do people think?]]> Adrian Bowyer Developers Mon, 23 Jul 2007 06:26:49 -0700 http://dev.forums.reprap.org/read.php?2,3742,3742#msg-3742 http://dev.forums.reprap.org/read.php?2,3742,3742#msg-3742
Adrian and I have completed a page on the wiki with documentation for all
the parameters used in the code. We've included the values we're currently
using for Darwin, and it'd be pretty fascinating to compare the values we're
all using... so if you wanna add your own columns up there that'd be cool:

How to build a RepRap -> Tweaking.

OK,

eD

_______________________________________________
Developers mailing list
Developers@reprap.org
[reprap.org]]]> EdSells Developers Mon, 10 Sep 2007 07:36:57 -0700 http://dev.forums.reprap.org/read.php?2,3614,3614#msg-3614 http://dev.forums.reprap.org/read.php?2,3614,3614#msg-3614
> I'm getting a new bug in OSX when i load files. It used to work, and
> I've traced it to the new materials selector. Here's the sourceforge entry:
>
> [sourceforge.net]
> [sourceforge.net]

I've just done an update that may (or may not...) have fixed this. Can
you try it on OSX (certainly works under Linux) and let me know, then
I'll do the appropriate thing with the bug report.

--

Best wishes

Adrian

Dr Adrian Bowyer
[staff.bath.ac.uk]
[reprap.org]
_______________________________________________
Developers mailing list
Developers@reprap.org
[reprap.org]]]> Adrian Bowyer Developers Mon, 16 Jul 2007 02:34:35 -0700 http://dev.forums.reprap.org/read.php?2,3576,3576#msg-3576 http://dev.forums.reprap.org/read.php?2,3576,3576#msg-3576
I did some tidying and maintenance on the RepRap subversion repository. Heres a list of changes that were made:

1. remove my old electronics stuff from my user directory
2. removed STL files from mechanics stuff
3. created tag folders and tags for all current releases.

the tag stuff was the most major. basically the way tags are supposed to work is that you take a snapshop of that portion of the repository at that release and put it into the tags directory. for host and firmware, there is only one part that gets released, so those directories will contain the tags directly (eg. tags/host/0.8.1). for mechanics and electronics, each module has its own versions, so the module directory itself contains the tags. (eg. tags/electronics/universal-controller/1.2.1)

since its pretty insane to try and go back and tag previous releases, i just started with our most current versions. if anyone has any issues with the revision numbers i chose, please let me know. electronics and host software are already chosen, but i went with 1.0 for firmware, 1.0 for thermoplast extruder, and 0.9 for cartesian bot (although theres nothing there!!!)

creating a tag is very easy, you simply copy the directory there with subversion:

svn cp trunk/reprap/host/ tags/host/0.8.1
svn cp trunk/reprap/mechanics/polymer-extruder/ tags/mechanics/polymer-extruder/1.0
svn cp trunk/reprap/electronics/opto-endstop/ tags/electronics/opto-endstop/1.0.1

in the future, either create the tag yourself when you make a release (real release, not test release) or ping me and i can create it. thanks!]]> ZachHoeken Developers Sat, 14 Jul 2007 14:57:51 -0700 http://dev.forums.reprap.org/read.php?2,3534,3534#msg-3534 http://dev.forums.reprap.org/read.php?2,3534,3534#msg-3534
svn: PROPFIND request failed on '/svnroot/reprap/!svn/bc/723/trunk/reprap/firmware'
svn: Processing PROPFIND request response failed: required string: "lp1:version-controlled-configuration" (/svnroot/reprap/!svn/bc/723/trunk/reprap/firmware)]]> Adrian Bowyer Developers Sat, 14 Jul 2007 04:48:30 -0700 http://dev.forums.reprap.org/read.php?2,3513,3513#msg-3513 http://dev.forums.reprap.org/read.php?2,3513,3513#msg-3513
> > for the orientation stuff, i'm thinking that its a count of how many
> > times you rotate over that axis (as you currently do when you load an
> > object) we'd have to keep track of that in the software so that when
> > you load a STL, you manipulate it and then can save the setup as a
> > reprap build file.
>
> Rotation about each axis measured in degrees would make for a far more
> readable file format, IMO. Normally we'd only expect to see values of ,
> 90, 180 or 270, but there could be times when other angles between 0
> and
> 360 degrees are useful.
>
>
> heh, you probably could've stopped here. another good suggestion.

We need to be able to store the rigid body transforms of translation and
rotation in their most general and unambiguous form. This essentially
means recording a Java3d transform matrix, I think. Not wonderfully
human-readable, but simple to read, to manipulate, and to output.

> I would also like to see the file format handle URL pointers to STL
> files, rather than always including the files locally; this could allow
> very small metafiles that allow one to print from an online or (local
> network accessible) library or set of libraries, rather than always
> moving copies of (large) STL files around and storing them locally. If
> we expect to one day be creating "integrated" networked RepRaps that
> need no associated host PC, and have no rotating storage, this sort of
> thing becomes necessary, not just nice to have. So instead of
>
>
> another good suggestion. this is a dream we both share =) changing the
> attribute to 'location' or something like that would be a good idea as
> well.
>
> the filetype could probably be optional, as the host software could
> probably figure it out based on extension, although you'd be free to
> specify it yourself.
>
> anyway, heres my revised example html file:
> [bom.reprap.org]

I like that a lot (possibly with the transform bit I mentioned). I'll
carry on modifying the internals of the program (which are obviously
independent of the file format). I particularly like the
filetype="application/sla" bit which allows us to have more sensible 3d
formats than just stl.

So - just to get things clear as I'm dim as usual - we have a zip file
(possible extensions: .rr .rep .rap - how does one go about "reserving"
one of these?) that contains files:

Zach's XML
STL-file1
STL-file2

etc.

Java must have something already in for packing and unpacking these.
Anyone know where I should look?

Best wishes

Adrian

Dr Adrian Bowyer
[staff.bath.ac.uk]
[reprap.org]
_______________________________________________
Developers mailing list
Developers@reprap.org
[reprap.org]]]> Adrian Bowyer Developers Sat, 14 Jul 2007 12:27:52 -0700 http://dev.forums.reprap.org/read.php?2,3477,3477#msg-3477 http://dev.forums.reprap.org/read.php?2,3477,3477#msg-3477
I'm not sure but I think that this means that Tommelise is the secondRepRap machine after Zaphod to print a part of itself which can replace a part or parts on itself.

_______________________________________________
Developers mailing list
Developers@reprap.org
[reprap.org]]]> Forrest Higgs Developers Wed, 11 Jul 2007 08:31:15 -0700 http://dev.forums.reprap.org/read.php?2,3398,3398#msg-3398 http://dev.forums.reprap.org/read.php?2,3398,3398#msg-3398
So far I have:

1. Materials are defined by their name as a String, not extruder-number. That name is the one for the material in the preferences file. String.equals is used to find the extruder number for the material when it's needed.

2. Each material has its own nominated support material for overhangs. These can all be the same, of course, but it also allows you to do clever things like having A support B and B support A. This is never ambiguous: there is always only one material immediately above you at any (X, Y, Z) point in air under an overhang.

3. Each material has a colour in the preferences file, and that allows them to be distinguished in the load and simulation windows.

4. To make a solid from two (or more) materials we have two (or more) independent but interlocking STL descriptions. We need to decide a (compressed) file format for multiple objects, their relative positions, and the materials each uses (we should also, perhaps, find out how others do this....). I had originally thought of using a tree of objects with materials and/or transformations at the nodes that apply to everything underneath. But I now actually think that's too general. I think what we need is:

a) Each STL has a material.
b) A group of STLs can be linked so that they all undergo rigid-body transforms together.
c) We then have a list of (b)s, each of which can be moved about ad lib. in the build space.

The (b)s are multi-material objects, and we can have a number of them being built at once.

We can put this file together any way we like. But one thing we can obviously do is to use it to save the configuration of objects in the build volume, and to re-load that again.

We could use the interlocking descriptions to describe the support too (that is to say, we could pre-compute the support). But I think that this is geometrically more difficult than doing it when we have the layering information during construction, so for the moment I propose to continue developing the code to do it that way. But at least we would have the choice.]]> Adrian Bowyer Developers Sun, 08 Jul 2007 03:54:06 -0700 http://dev.forums.reprap.org/read.php?2,3262,3262#msg-3262 http://dev.forums.reprap.org/read.php?2,3262,3262#msg-3262
But if anyone was fond of them, now is the time to speak :-)]]> Adrian Bowyer Developers Wed, 04 Jul 2007 08:12:17 -0700 http://dev.forums.reprap.org/read.php?2,3258,3258#msg-3258 http://dev.forums.reprap.org/read.php?2,3258,3258#msg-3258
remember, if they arent available on the internet, they basically dont
exist.

Ontologically questionable, but practically sound...

--

Best wishes

Adrian

Dr Adrian Bowyer
[staff.bath.ac.uk]
[reprap.org]
_______________________________________________
Developers mailing list
Developers@reprap.org
[reprap.org]]]> Adrian Bowyer Developers Wed, 04 Jul 2007 02:38:44 -0700