RepRap on an OLPC

Just wondering if anyone has given thought to making RepRap work on an OLPC (One Laptop Per Child) device?

Java isn't going to run, so skeinforge looks like the only contender for gcode generation - unless anyone knows better; I'm not particularly a python nut.

Not sure how to get the gcode into the reprap though. In theory we might even be able to do that with a simple copy command, but we'd need some kind of rudimentary interface that can allow a reprap builder to test out motors and extruders on, even if it's minicom.

First step, I guess, is to first use the OLPC's Linux console to send a gcode file to the reprap. Anyone done this manually before?

Vik :v)

It's not clear just how viable the OLPC project is these days. Many of their staff are gone and most of the Open Source components are no longer being developed internally. The OS part of the software has been completely spun off to the community and Microsoft is providing a stripped down version of XP. I'm not sure there is much value in putting a lot of effort into specifically targeting the platform.

I'm not actually after something OLPC-specific, just something small and simple. An OLPC happens to be a good benchmark - and they are out in the developing world in some numbers.

It's not clear why Microsoft produced a stripped-down version of XP for the OLPC. It's too stripped down to be useful and the developing world can't afford any more applications for it.

I know some of the people in the project, and rumours of its demise have been greatly exaggerated. But what is important is that we get something together that will run on low-spec devices of the kind that charitable institutions will deign to hand out to the needy. It's looking increasingly like these will be ARM/Linux based which, if we get this right, won't matter.

Vik :v)

The current trend in controlling repraps seems to be storing the build instructions on an sd card. This has the huge advantage that all object -> instruction processing can be done at whatever pace - there is no need for any real time processing on the computer end. I have yet to try, but I think there is a simple python program floating around to send gcode to a reprap if you want to try now. I'm not sure what the current reprap-host requirements are, but it runs perfectly on the old 1.2ghz celeron laptop I use.

Yeah, producing gcode to a file has the same buffering effect. I've started doing this in the last month or so and notice a distinct improvement in build quality.

Vik :v)

Hey Vik, I spent some time trying to get my Eeepc 401 (a cheap, low end laptop, not far from the OLPC) to run builds on my Darwin; I was using Gcodes, and I tried using send.py (Python) and an old version of replicatorG to send Gcodes, but everything seemed to cause a lot of noticeable pausing at 16 mm/s head speed, resulting in a lot of blobs during the build. I even tried booting different flavors of linux (Xandros and Ubuntu), but neither seemed to help. The exact same software and gcode files ran fine from my faster, dual core laptop, so I just used that instead. I don't think it was a raw horsepower problem, more of a scheduling problem - something on the Eeepc was regularly interrupting the java host just long enough to cause a problem.

That was last November though; I think the buffering works a bit better in the later ReplicatorG versions, and I'm looking forward to trying out the new java host software with acceleration and all that. My Darwin is in a crate at the moment, as I'm busy moving across Canada, so it'll be a while before I get to test it, but here's hoping.

I think an SD card is the way to go though - way cheaper than an extra laptop, especially if you've got more than one RepRap to run, and it should eliminate the problem of various PC processes interrupting the build.

Wade

I suspect Java might be the problem here. Something small & sweet to poke gcodes at a RepRap would be nice. Seeing as skeinforge is in python, a python gcode dispenser would make sense.

Vik :v)

I got two OLPCs a while ago as part of G1G1, but the kids were not very interested in them. I use one to take serial data from a USB drive and send it to my repstrap. At first I did it with a simple python program (run from the linux command line), but there were random delays that caused very frustrating blobbing. I cured this by adding some lines to the arduino code for the repstrap to implement XON/XOFF software flow control. I used the linux 'copy' command (set up with XON/XOFF flow control) in a shell script. This fixed the blobs made by the pyserial delays. I can post more details if anyone is interested.

I have made feeble and unsuccessful attempts to use skeinforge (my slicer of choice) on the OLPC. I have also not been able to use Art Of Illusion on it, but have not tried all that hard.

Frank Davies

Yes, interested in the XON/XOFF code.

Not sure how well AoI is going to work on an OLPC - it needs quite a lot of memory what with being java based etc.

Vik :v)

There is send.py and RepRapArduinoSerialSender.py in the fabricate folder in the miscellaneous folder in skeinforge. I haven't tried them because I don't have a reprap, but apparently they work. I believe they use pyserial, so would probably suffer from pyserial delays or problems. More info about em is at:
[reprap.org]

fdavies,

If you post your code, I'll add it to the fabricate folder in skeinforge. An easy to install program to send gcode to the Arduino, without pyserial delays, would be great.

Enrique

This could be a busy weekend...

Vik :v)

I have been able to use the arduino software quite well on my XO (OLPC) laptop. I used it to program an arduino with the GCode_Interpreter v1.3 as part of putting together my repstrap as well as for other arduino projects.

I figured that I could put together a little python program on the XO to take gcode files and feed them to the arduino by using the "ok" reply as flow control. I did this, but discovered that pyserial would sometimes insert delays that caused blobs on the article that I was printing.

After much going back and forth, I set up a shell file (t.sh) to send the gcode file directly to the USB serial port with the 'ascii-xfr' command, after setting up the serial port to use XON/XOFF flow control. After all, the 'ok' text that the GCode_Interpreter sends after a command is executed is very similar to XON/XOFF flow control, just easier to monitor with a terminal emulator.

I implemented the XON/XOFF flow control in the GCode_interpreter by adding a line that outputs XOFF just before the 'process_string' subroutine called in 'get_and_do_command' in process_string.pde (part of GCode_Interpreter v1.3). I added a line the outputs XON just after 'init_process_string'. This results in the arduino sending XOFF (0x19) just before a command is interpreted. If the command takes a long time, (e.g. a long move command) then the XO laptop waits for the XON character (0x17) which it receives after the command is finished.

One problem that I encountered is that the shell resets the arduino just before it starts to send the file. It takes the arduino longer to get ready to interpret the first command than it does for the XO to send it. This meant that the first few commands (like the one that turns on the heater) were not executed. I cured this by adding about 100 lines of 'G90' command at the beginning of the gcode file with the linux 'cat' command in the shell file. 'G90' acts like a no-op, and by the time the XO laptop has finished sending them, the arduino is ready to receive and interpret commands.

I also have a simple python program (bring_to_temp.py) that starts the extruder heating and reads the extruder temperature with the 'M105' command. Once the extruder is good and hot, it hands control back to the shell script that then uses 'ascii-xfr' to transfer the file to the repstrap.

The whole process is kicked off from the command line thus:
./t.sh /media/YOUR_USB_STICK/your_ubject_export.gcode

Doing this completely cleaned up the blobbing problem. I love that I could tweak the arduino code like that. Open source is wonderful!

One day I will get around to loading the latest GCode_Interpreter program (and adding the XON/XOFF flow control, I suppose), but I am too busy printing improvements to my Sarrus Linkage to do it right now.

Frank Davies