No Computers Attached!!!

Ok, I was finally able to successfully slice and dice the model using Enrique's excellent script. The model (pictured below) is admittedly on the upper end of what one might expect RepRap to handle complexity wise.

The Gcode file size is larger than what some people have been expecting - 6.8MB. I tried to load up the same STL in the host software and use the "estimate build resources" feature to get an idea of how much print time this represents, but for some reason it kept throwing an exception. A very rough-and-dirty calculation based on the object's volume (147cm^3), the extrusion diameter (0.8mm) and extrusion speed (I used Enrique's default of 10mm/s, but I'm hoping we can get machines that operate at several multiples of that speed) makes this a 2 hour build.

We're only looking at about 15 minutes' worth of print instructions in a 512KB eeprom chip. That's enough to buffer instructions, but not really enough for practical computer-free printing. I'm sure there is a good solution, but I haven't thought of it yet.

Render of the file I tested with:


You may see this show up as part of a larger project in the "things to print" forum if I can get it done (and no, it doesn't have any >45

Edited 1 time(s). Last edit at 05/16/2008 08:35AM by Kyle Corbitt.

Kyle,
An interesting shape but I think you got the time calculation wrong. 0.8mm filament at 10mm/s is pi * 0.4^2 * 10 = 5mm3/s. 147000 / 5 / 3600 = 8 hours. I think that is pushing the current extruder. My machine would take 13 hours to make this.

The easiest way to store large amounts of data has to be a SD card on an I2C port. You only have to implement FAT if you want the files to be readable on a PC. Otherwise you can just read and write blocks of data. I have implemented FAT a couple of times and it is only about 1000 lines of C but you do need enough RAM for a sector buffer. If you only read files then it gets quite a bit simpler.

---

[www.hydraraptor.blogspot.com]

Hi Kyle,

... as i see the big problem with reprapping this part is the huge amount of very smal areas and the space between ...

The average slice represent some houndred not connected dots, so the extruding head is mostly on the way up and down from one area to the other and you will receive a mess of 'cob-webs' in the space between.

For this kind of fabbing there should be an optimization, which instead of simply slicing through the complete object should output every 'column' separately from the bottom to the next possible junction (in respect to the shape and outer diameter of the tool-tip).

Viktor

With the extruder valve mod there should be no cobwebbing, but yes the build time will be longer than predicted by the volume alone because of lots of head movement.

I don't think departing from building in layers is a good idea though. It would greatly complicate the s/w and not be a general solution. Much easier to make the head movement very fast to mitigate this extreme type of shape.

---

[www.hydraraptor.blogspot.com]

Mobile phones are continually gaining in CPU power, display/input capabilities, storage capacity, and market penetration. The downside is that it tends to be a pretty closed ecosystem, though that seems to be changing over time.

For $100, you could add one of these: [www.linuxdevices.com]

degroof Wrote:
-------------------------------------------------------
> For $100, you could add one of these:
> [www.linuxdevices.com]

Nifty. You could carry it in your jacket pocket. If it can plug into a TV set, I might buy one.

Quote

For this kind of fabbing there should be an optimization, which instead of simply slicing through the complete object should output every 'column' separately from the bottom to the next possible junction (in respect to the shape and outer diameter of the tool-tip).

This could prove exceedingly tricky to do correctly for the sort of space-frame Kyle as looking at. Completing one edge of a /\ shape would make it very difficult to join the second edge to the apex, for example, as the top of the first edge could be too close for the deposition head to move to the correct location.

You could potentially solve it with something exotic like a hexapod, or a tilting platform attached to the bed to give you an extra couple of degrees of freedom, but I for one do not want to consider the mathematics of FDM toolpaths in 5+ DOF!

Vertical pillars, (or at least isolated pillars) on the other hand could benefit from this though. The cats-cradle part that nophead printed out last week springs to mind, for example. But then you have the problem that when you've completed one pillar and start on the next, the base of the part may have cooled quite a lot which could result in very poor inter-layer adhesion.

I think layers will be the least painful way to do FDM for some time to come

... what could be done about columns is a middle-way - for small column-areas to output process not a single slice, but for example 8 slices, so you get a part of the column.

Then ignore it, until you reach the height again and so on.

So the fabbing is sort of optimized for this sort of geometry but didn't mess too much around with the joints ...

Viktor

This wouldn't be right for everybody; it would be more suited to those who are not averse to designing their own circuitry. Parallax (parallax.com) puts out a very powerful (in terms of processing) microcontroller called the Propeller. It's got 32 general-purpose IOs. It can't supply much current, so MOSFETs would have to be substituted for normal transistors in many places. It has EIGHT PROCESSORS!!! True multitasking, woohoo! As far as the USB drive thing goes, the Prop chip has been used many times to interface with USB devices, so that could be one possible solution.

Quote

It has EIGHT PROCESSORS

And making use of them all might prove tricky It would require a serious re-engineering of the firmware design, and significantly increase the number of ways stuff could go wrong, without any significant gain that I can see.

The reprap doesn't seem to need to do lots of complicated things simultaneously. What it lacks is storage space, (we're hitting the limits with the current arduino gcode firmware, I believe... but the atmega328 is allegedly on the way soon, and should be a drop in replacemnt?) and to a much lesser extent the raw processing speed to do various linedrawing things.

I'd be more in favour of a cheap ARM7 microcontroller. There are a lot of them about, and the toolchains are quite mature. I quite fancied the look of the toys from [www.at91shop.com] but they're a little beyond me right now, skill-wise!

Its funny someone would actually mention the Rabbit and even more funny that I have overlooked it for 2 months+

There is not so much secrecy in the Rabbit world when it comes to the hardware, circuit diagrams can be downloaded from the site itself.

I also know for a fact that you can buy these thingies one-at-time.

What is a secret though, is the software. That is also the reason for the development kit costs.

On the other hand the proprietary "Dynamic-C" compiler that is offered is quite horrible.

There is actually now a free alternative. Check out www.z88dk.org. A retro compiler project that from release 1.8 has a minimal but working support for the Rabbit processor.

What is missing in the z88dk though is all the drivers. But since we are writing directly to memory there would be no enormous usb stacks to implement.

Final question would then be: How far does 1 MByte of memory take you anyway?

BTW I think I have somewhere a 128MB flash stick that emulates an IDE harddrive. Jumpering it differently, I think, would implement an old-fashined A0-AXX and D0-D15 memory with a few select lines. If these things are still a go, maybe they would give us the boost we need?

Quote

BTW I think I have somewhere a 128MB flash stick that emulates an IDE harddrive. Jumpering it differently, I think, would implement an old-fashined A0-AXX and D0-D15 memory with a few select lines. If these things are still a go, maybe they would give us the boost we need?

This would require some hardware that spoke IDE, and then a microprocessor that would do memory mapped IO for you. Its far easier trying to find kit to let you speak to a USB mass storage device.

Quote

What is missing in the z88dk though is all the drivers

Has anyone actually built an application for this processor, using this compiler? Having to do a whole load of assembly programming to get even the slightest thing to work correctly sounds... less than fun.

Without a widely available and widely used compiler that demonstrably worked well, I'd very extremely unkeen on even thinking about this particular platform.

But then, that's cos I prefer different sorts of challenges. As always, YMMV

Actually you don't need an IDE interface for that one. You only need address lines and data lines. put the address lines out and then do an I/O strobe and read in the result. You would be done in like 20 lines of assembler, even when resorting to bit-banging.

It must be easier than reading a flash through USB.

I'll look around and see if I can that darn chip somewhere

Here is a link to a MAKE:HOWTO for attaching an SD card to an arduino.


[blog.makezine.com]

---

Bob Teeter
"What Box?"

I found it!

It was even better than I thought. The Compact Flash cards (available
everywhere) have a memory mapped mode.


Here is a description of how to interface it to a pic

[www.archive.chipcenter.com]

There is an example in pic-assembeler how to access memory!

Hmm 10+3+6 = 19 pins I guess the SD wins on the pincount :-)

mimarob Wrote:
-------------------------------------------------------
> Hmm 10+3+6 = 19 pins I guess the SD wins on the
> pincount :-)

Wowzie! That's almost half the pins of a 40 pin PIC!

The I2C compatable EEPROMS I'm using need just 2 to handle half a megabyte.

Yes but with SD and three or four lines you get can get several GB and you can swap SD cards in and out.

That is big enough to store complete projects, like a Darwin.

---

[www.hydraraptor.blogspot.com]

Go with the SD card solution, the cost verses capacity of this media makes it a very strong candidate, couple that with the easy interface using only a few pins and for my money was the only way to go.

I have a vested interest in the SD solution as I have used this with my project, what I can say is it works, it has plenty of space for files and the speed is quick enough to serve up data without any significant segment pausing. I am sure you can get this media working with the Arduino, but I do not have any experience with the chip and am not sure if there is a FAT system out there to make it compatible with a PC.

I would recommend you have a look at Microchip paper AN1045, this is a complete (Free) implementation of SD Card (& Compact Flash) with FAT 16. The library contains a comprehensive set of functions for file management. As much of the information contained in the paper is platform independent I am sure it will be useful to anybody wanting to go down this route. You should be able to get a good idea of the resource required for SD interface and FAT16 implementation, you can then decide if SD Media is a suitable option for the Arduino.

The AN1045 Library runs well on the PIC24, with this installed you can read, write, navigate directories etc. In my project using an LCD and a couple of buttons on the joystick, I have it scrolling through the files on the card so you can select the one you want to run.

Tony

Edited 1 time(s). Last edit at 07/02/2008 08:42AM by tofletcher.

hmm your saying the implementation is free, does that mean there is full source?

Would be interesting to read, a friend of mine actually asked for help reading/writing SD's the other day.

How large is the maximum of a FAT16 file system?

Looks like 2GB with 512 byte sectors.

Not sure what the sector size of SD cards is.

[en.wikipedia.org]

-Mark

mimarob,

Yes, I downloaded full source code in C ready to compile. You are right to question the freedom of what can be done with the source, again I refer you to the document AN1045 and read the terms.

Tony

It just struck me that it might be silly to spend to much effort discussing which cpu or memory card solution is the best, lets leave that to darwinism ;-)

But.. I read a little on the S.N.A.P. protocol this morning and the question that arose was: Is it possible to "eat away" the character stream coming from the host, happily ack:ing away all messages and store into a large enough memory of some kind, pretty much the same way as the infamous printer "spoolers" of the 80's.

Can all this be achivied transparently without changing the reprap host software?

I guess the "spooler" would need to be intelligent enough to handle retransmissions and different error conditions like restarts that may occur in the actual printing process?

Forrest, I know you have done some heroic deeds with an eeprom, do you just tap off the character stream from the host or do you use modified software?

mimarob Wrote:
-------------------------------------------------------
> It just struck me that it might be silly to spend
> to much effort discussing which cpu or memory card
> solution is the best, lets leave that to darwinism
> ;-)

There's no harm in discussing the possibilities - a little intelligent design goes a long way in this business, which is why we got RepRap in 4 years instead of 4 million ;-)

> But.. I read a little on the S.N.A.P. protocol
> this morning and the question that arose was: Is
> it possible to "eat away" the character stream
> coming from the host, happily ack:ing away all
> messages and store into a large enough memory of
> some kind, pretty much the same way as the
> infamous printer "spoolers" of the 80's.
>
> Can all this be achivied transparently without
> changing the reprap host software?
>
> I guess the "spooler" would need to be intelligent
> enough to handle retransmissions and different
> error conditions like restarts that may occur in
> the actual printing process?
>
> Forrest, I know you have done some heroic deeds
> with an eeprom, do you just tap off the character
> stream from the host or do you use modified
> software?


Forrest uses a completely custom toolchain. He can give you the details about how it all works, but you might want to check out his blog at [www.3dreplicators.com] to get an idea of how it works, and what he's got working so far.

mimarob Wrote:
-------------------------------------------------------
>
> Forrest, I know you have done some heroic deeds
> with an eeprom, do you just tap off the character
> stream from the host or do you use modified
> software?

I'm not sure that I quite understand what you are asking. I've set up Tommelise's firmware to where it operates in two modes; print data transmission and printing.

In print data transmission, Tommelise isn't printing and I simply transmit a long character string from the PC to Tommelise that can contain upwards of 11 hours of print instructions in under 10 minutes. The firmware receives the stream and writes it off onto the EEPROM buffer. I also do a verification cycle to make sure that what got written into the EEPROM buffer is exactly what I transmitted.

Once that's done I can shift Tommelise into print mode and start the print. In print mode the USB link is free for transmissions between Tommelise and my PC and vice-versa to monitor the progress of the print job. For my primitive programming skills trying to send a print data stream across the USB link AND keep track of what Tommelise was doing was just too much to handle. Windows multi-tasking, while good, tends to at times create pauses for USB comms with peripherals which without a good buffer could mess up a print job. I have to use my PC to do a lot of other CPU intensive things besides running Tommelise so I wanted there to be as little regular traffic on that USB link as possible. I also wanted that light traffic to not be time critical since Windows isn't really a real-time operating system. From what I've seen Linux really isn't a real-time operating system either. That scares me a little for Darwin's sake since it seems to depend on just-in-time transmission of print data, largely.

I also wanted Tommelise to be able to print even with the PC shut down since the PC uses a LOT more power than Tommelise does and electricity runs $0.225/kwhr here in California. The way I've got it set up now, I can start a print job when I go to bed and shut down my PC and Tommelise will print it out, in theory at least, by itself.

Edited 6 time(s). Last edit at 07/16/2008 12:18PM by Forrest Higgs.

Kyle Corbitt Wrote:
-------------------------------------------------------
>
> Forrest uses a completely custom toolchain.
>
It is that. Long ago, I observed the drama that Reprappers were having with Java and Linux and decided to write my own software on Windows and using Visual Basic .NET for the PC side and the Oshonsoft Basic IDE on the firmware side. While I wouldn't recommend that as a model for emulation (I've been writing software since the mid 1960's) I haven't regretted it as a personal choice for a even a moment.

I can't swear, since I'm still using Visual Studio .NET 2005, but I'm pretty sure that my PC side software will run successfully under Visual Basic .NET 2008 Express which you can download for free at...

[www.microsoft.com]

On the Tommelise microcontroller side you can get a license to program the Microchip Pic microcontrollers (I use the native USB comms 18F44550) for about $120 from Oshonsoft.

While my development tools are neither open source or completely free, the cost isn't crippling.

Edited 2 time(s). Last edit at 07/16/2008 12:27PM by Forrest Higgs.

Hello again!

I do some java and linux for a living, but it still took me a day or two to completely fail and then resort to the Live-CD so I guess there are a few things need simplifying.

OK, now I caught up on my reading, you are using your own slice-and-dice program, that must require at least some talent ;-)

Being a former software engineer I do almost anything to avoid serious programming since I know how time consuming it is :-)

But, going back to the S.N.A.P. protocol, anyone knows if that could be buffered in some embedded device and then paced out to the reprap? Preferably without modifications? Would it be useful if I looked into that?

I found some decent documentation on the protocol, but are there any pointers to the content data, apart from the Arduino/PIC code?

[www.reprap.org]
RepRap SNAP Command Documentation

[www.reprap.org]
Stepper Motor Controller SNAP Protocol Version 0

[www.reprap.org]
Extruder Controller SNAP Protocol Version 0

Looks like you will at least have to emulate the hardware to identify the type and version of each addressable device.

Thats great :-)

If industri at large where anywhere near this project in the way of working, we'd all have weekend retreats on Mars by now !

Yeah, one has to emulate the devices, just like the arduino does!

Stuff like "feedstock empty" of course has to be faked in a batch printer solution, but I don't think it is in use today anyway?

I just hooked up a serial port listener to the reprap software.

I found some strange results.

I choose the tester-exerciser program from the reprap 0.4 Live-CD

Even so, I get the following hex string over and over again:

54 51 31 08 00 00 BA

I interpret this as:

54 sync
51 HDB2
31 HDB1
08 dst address Extruder (!!!)
00 src address PC
00 version command
BA crc


The strange thing is, dst address is the address for the extruder, still the circuit and Java program work when I connect only a Stepper board to the host.

Any idea what is going on?