Raspberry Pi RepRap and python

I'm sure many of you are aware of Raspberry Pi, I wanted to ask if anyone has any plans to work on a RepRap hardware/software platform using it.

It's a powerful platform, low cost and as it's 'official' programming language is Python it could be a more easier route as we already have slicers and host software based on Python.

It has a video output, Ethernet, USB, SD card slot but unfortunately only minimal I/O, so if directly used as the main control 'PC' then an I/O expander could be fitted onto a RAMPS style motor driver board (shield) to allow for that.

It could be a good project to work on as both PC software developers for the user interface / host and slicing software could be working on one side with also the real-time software and hardware developers looking at how best to expand the I/O and produce a RAMPS like RepRap control board.

It needs a little more thought, anyone interested?

FAQ - [www.raspberrypi.org]
Wiki - [elinux.org]
Forum - [www.raspberrypi.org]
Broadcom SoC Datasheet for ARM11 - [dmkenr5gtnd8f.cloudfront.net]

The boards are being released for sale before the end of this month.

Rich.

---

[richrap.blogspot.com]

I think the IO would be adequate considering you wouldn't need a serial connection, or an SD card header. The hard work in my mind is all the coding to go from Host-Slave based electronics to Host only electronics. And you might need to do a real time version of the OS to get good reliability controlling directly from the host OS. Maybe an intermediate step would be to run an on board host with the PI and still use USB-serial and a full electronics for control. With a pico projector and that setup you'd have a great traveling machine.

Yes, I may make sense to keep a microcontroller for the Real-time element as we still need 3 x ADC inputs, endstop inputs and 5 x clock,data,enable lines for the motors.
but connect it via one of the RPi's serial ports, no point going USB - to - serial.

Chicken and Egg - we could easily make the electronics work with the Pi, but unless someone wants to start porting something like Pronterface there is not much point in doing it.
The Pi has a comp video output - 7" video screens are low-cost, with a simple user interface and mouse/keyboard you could have a nice setup always mounted on your machine. Even if we still slice on a PC, we could download files to the target RepRap via Ethernet on the Pi.

---

[richrap.blogspot.com]

Imagine if you your smartphone could do it,?????????

---

Random Precision

This project, of which I am a part, is in the process of designing an I/O board for the PI. Quick2Wire

Cheers
Geoff

---

---

How often I found where I should be going only by setting out for somewhere else. - R. Buckminster Fuller

[apapageek.com]

Does the Host Software work raspberry?

When a usb-rs232 converter also works on it it would be a good replacement for a notebook.

Hi all,

Pls correct me if I'm wrong...

what we need for reprap

A Stepper driver needs 2 signals to operate,for direction and step. (http://www.probotix.com/downloads/step_and_direction_drives.pdf). A reprap has 3 stepper motors for each axis and another one for extruder (4 motors). So we need at least 7 outputs (2 each for 3 axis and none for extruder, as only one direction for extruder motor trurns) for motors, 3 inputs for limit sensors and another 1 output for heated bed signal. (did i miss any????) 2 analog signals for therm couple.
8 - outputs (digital)
3 - inputs (digital)
2 - inputs (analog)


what we have in Raspberry Pi

There are 17 GP i/o s in Rpi.((http://elinux.org/RPi_Low-level_peripherals). With some soldering we can have some analog pins too. I guess we have what we need.

So i guess with Raspberry Pi and 4 stepper driver ICs should be enough to drive a Reprap. According to this (http://pypi.python.org/pypi/RPi.GPIO) it seems, not so hard to do that with some Python.

example code

import RPi.GPIO as GPIO
# set up the GPIO channels - one input and one output
GPIO.setup(0, GPIO.IN)
GPIO.setup(1, GPIO.OUT)
# input from channel 0
input_value = GPIO.input(0)
# output to channel 1
GPIO.output(1, True)

You need step and dir for the extruder too!

---

Bob Morrison
Wörth am Rhein, Germany
"Luke, use the source!"
BLOG - PHOTOS - Thingiverse

Also, an output for the extruder heater!

---

www.Fablicator.com

The first thing almost all RPi project will need is an I/O expander, not that hard, you can save most of the direct I/O for Inputs and use a shift register or two to get a whole bank of 8 or 16 outputs, they will be plenty fast enough for sending stepper data.

---

[richrap.blogspot.com]

hi guys..
Thanx guys.. this is gonna exciting.. Still waiting for my Rpi..

I know I'm a grumpy old man, but isn't this project taking a big step backward by bringing in closed-source proprietary electronics?

It's especially poor choice after the Raspberry Pi people got so much good will out of their claim it would all be for charity, then turned around and sold the rights to Farnell (A well-known charity... not).

The Raspberry Pi is an interesting board (i.e. very cheap), but it's trying to fit a solution to a problem. Extending the IO of the R.Pi is straightforward with an extender board.

The big problem I see is getting the necessary real time performance from Linux. It can be done, but not with an off the shelf distro. "Real time" linux often means 5kHz events, I think to drive steppers requires an order of magnitude higher than this. Interrupt latency/context switching with Linux may be in the order of ms not us, not much good for machine control. It will need one of the real-time extensions, then you are probably into building your own kernel.

It's a very big leap from bare metal coding on the Arduino, to a full OS like Linux. There are many OSes that attempt to fill the gap, but nothing like as well supported or widely available.

I've been working on the R2C2 platform, the dilemma is whether to extend the capabiity to ethernet, USB host etc, or whether to start with a Linux and make it able to drive steppers. If I was designing from scratch, I would probably use the R.Pi as the application front end, and use a small AVR connected via serial as a stepper/IO driver. GCode would be processed on the host, and the AVR handles the high rate real time stuff. Neither the EMC method nor the Reprap method have really made any sense to me, they don't make appropriate use of the platform that the software runs on.

Anyone else have a RPi yet?

I have pronterface installed and working on it, next step is to get the printer working and then get it to be command driven via the Ethernet interface - I'm going to need some help with that bit.

Anyone else working on the RPi and RepRap?

---

[richrap.blogspot.com]

richrap Wrote:
-------------------------------------------------------
> Anyone else have a RPi yet?

Still waiting for RPi to be delivered.
>
> I have pronterface installed and working on it,
> next step is to get the printer working and then
> get it to be command driven via the Ethernet
> interface - I'm going to need some help with that
> bit.

>> "get the printer working"

That sounds like the hard bit. Do you mean control directly from the Pi, via an Arduino or via some expansion hardware?

The first thing I would do is see if I can get a reliable stream of step pulses on a GPIO pin, and at what rate.

I don't know that it's a solution looking for a problem. I think it's just a different problem. Lots of people are looking for a good way to take their printer with them to demo without having to lug a laptop around to do control. Or a way to setup permanently in a shop area without needing a dedicated computer. This might be a good solution. SD card add-ons and control panels help but only if you already have everything sliced and loaded to the SD card. I see this as a step up from the SD+control panel. Probably not a replacement for the electronics/driver yet but maybe a good OS hacker could get it to work with a brainless driver board. I think it fits in nicely on a deluxe travel electronics solution next to the reprap electronics of your choice. It might even help with comms issues many seem to have with the usb to serial cable, as you should be able to direct wire the serial ports together without any usb to serial or level shifting circuits.

Re: charity grumbling. Yes, ScribbleJ you are a grumpy old man but we like you anyway. Considering that the board is still the same price I doubt that the licensed distributors are making much money. I haven't seen anything to convince me that the decision to use distributors rather than self source the boards was anything but a supply issue. They have more capitol to make larger orders. The raspi group is still a charity, still holding the line on price and getting the boards out quicker than otherwise would have been possible considering that they refused to take pre-orders. (There's a novel idea

bobc Wrote:
-------------------------------------------------------

> >> "get the printer working"
>
> That sounds like the hard bit. Do you mean control
> directly from the Pi, via an Arduino or via some
> expansion hardware?
>
> The first thing I would do is see if I can get a
> reliable stream of step pulses on a GPIO pin, and
> at what rate.

Only had it 3 days, so Just using it as a Linux box at the moment, so still using Arduino MEGA+RAMPS and Pronterface, I just wondered if anyone else had it up and running that way.

As the GPIO on the Pi is very limited I see it as a step up from the 4 line LCD and rotary knob at the moment.
I would like to make use of the Ethernet connection to remote select/start/print and send new Gcode files to the Pi's SD card or memory stick as the next step.

---

[richrap.blogspot.com]

why the need to port it ?
Rasbery pi understands python, like basic was once part of dos.

I have a beaglebone which is a similar though more expensive SOC with better GPIO support.
My intent was to provide an all in one solution, including the motion controller, slicer, touch screen interface etc etc.
The issue I am having is being pretty much forced to use Linux, though TI supply a none OS option there is no documentation or software available outside of Linux for the GPU.
So I'm stuck with either linux or no GPU.
Generating a pulse train in Linux is certainly possible, but it's less than ideal as an RTOS on a single threaded CPU, it would be much easier to do consistently with the no OS option.
I assume Pi's are much the same in this regard.

Polygonhell Wrote:
-------------------------------------------------------
> Generating a pulse train in Linux is certainly
> possible, but it's less than ideal as an RTOS on a
> single threaded CPU, it would be much easier to do
> consistently with the no OS option.
> I assume Pi's are much the same in this regard.

Yes, and with the Pi, you need to expand and buffer the I/O, so really, why not stick to a second Micro to do all the Real-time stuff, talking to it via USB is fine for Linux, and you get around most of the hardware issues you would still need to do on the RPi.

I'm really not sure how well any slicer is going to work on a RPi, but no doubt we'll soon find out.

---

[richrap.blogspot.com]

I had an idea for a slicer using the GPU to rasterise layers then GPGPU to extract the edges and relax them.
I haven't tried this yet, but my back of the envelope calculations say it should be pretty fast even on the SOC.
Putting thr slicer on the pulse generator also potentially gives the option of printing while slicing,in which case you have plenty of time to slice and the relaxation step may not even be necessary.

The beaglebone has a couple of very simple IO processors in the SOC which might be enought to work around the Linux issue, I need to find some time to look at it properly.

I have the Raspberry Pi Talking to the printer now (MEGA+RAMPS) - with Marlin and Pronterface. the main problem now is that I can't get 250000 baud rate working, it connects and runs at 115k2, but I would really like 250k baud working, anyone have any ideas.

I'm setting up ttyUSB1 in the terminal window using stty and it does not like 250000 as an argument but fine with 115200

Looking at this page stty does not seem to like 250000 baud? is that correct?

Anyone else have Pronterface running in Linux at 250000 baud? Do I need new FTDI drivers?

Treat me gently, I only have a basic grasp of Linux.

---

[richrap.blogspot.com]

Hi!

I've been working on a RBPI 3D printer controller board, based on Ramps/Teensylu/Printerboard boards. It will communicate with RBPI via SPI or I2C, still finishing up the board. the BOM should be lower because Im using the TI DRV8821 dual stepper driver IC (2 stepper motor controllers in one). Also a DAC has been added to control the motor reference voltage, that way you can set the motor current thru software without adjusting pots.

here is a rendering:



once I get the boards back and working will create a page on the wiki. I've also attached a schematic (its untested at the moment)

Edited 1 time(s). Last edit at 05/27/2012 09:57PM by joshnuss.

Have you guys considered, once you manage to get this system to work, to make a 'dedicated' distro with a 'market app'? For example browsing, choosing, downloading, and printing off ThingVerse? With just a direct connection to the web, it would be like browsing android or iOS markets for apps. Hell it could even be done like a vending machine, put coins in, choose an object, and out comes your item. (Though you would need to measure the time taken, so you can charge appropiately, can that be done?)

Edited 1 time(s). Last edit at 05/29/2012 01:20AM by mofosyne.

Hey Mofosyne,

Thats a pretty good idea, maybe it could be integrated with pronterface. havent given much though to higher level features yer, For now, I'm focused on testing this thing and building a gcode parser that will run on RBPI and be compatible with pronterface,etc.

No probs. But it wouldn't hurt to at least shoot an email to thingverse and other 3d file repository about if they have any API that you can tap into in the future? Just ask if they have an API, and if not, if they can develop and publish it?

Once you got the info, post it here! I'm sure a few budding coders would be more than happy to make an app for all platforms, not just the raspberry pi.

joshnuss Wrote:
-------------------------------------------------------
> Hi!
>
> I've been working on a RBPI 3D printer controller
> board, based on Ramps/Teensylu/Printerboard

Hi Josh,

Nice rendering and It's great to see someone else working on a RPi for 3D printing.

Are you planning to have a standard style firmware on the ATMEGA164 interpreting the GCODE sent by SPI/I2c from the RPi.
Or are you planning to do all the processing on the RPi and just send motor control commands down via the SPI/I2c

Either way you may well still be better off doing it as a USB peripheral rather than a SPI/I2c device on the RPi.

I have the RPi working as a printer controller, but still have issues with serial port speed, not a problem if using an SD card, but the RPi needs to be doing some more work to justify itself, that's why I ask the question above.

How good are you at Linux then? I'm using this as an excuse to learn a lot more about it, but I'm getting a little frustrated.

Cheers,

Rich.

---

[richrap.blogspot.com]

Hey Rich,

The idea is to do the Gcode parsing on the RBPI and issue I2C or SPI commands to the firmware on the atmega. The firmware will be very dumb, it will just accept commands like how many steps to move the motor, or to check the adc value of the thermistor. the real meat of the software will be on the RBPI

Initially considered not using a microcontroller at all (just I/O expanders and I2C enabled stuff) but it will be easier to implement time critical stuff in a firmware.

some a of reasons that justify using an RBPI:

- Ethernet capable device (print over the network)
- Gcode parser/printer controller can be writting in a higher level language (opens it to more contributions)
- Video output can be handy i.e. display toolpath and other information

Cheers,
Josh

Hi Josh,

That sounds like a good plan, it's always good to have some intelligence on an I/O board, I'm sure it will help take some load off the RPi and make future expansion easier. Make sure whatever protocol you decide on the GCODE interpreter from the Rpi to the micro has the capability to do multiple extruder's (more motors, thermistors and outputs), GCODE commands keep on expanding all the time, so as long as your I/O hardware is scalable it should be a good way to do this as a next gen platform.
If there is an Arduino emulator for Linux you could even have an interim step that uses current firmwares, instead of writing another GCODE interpreter.

Let me know if I can help out at all, I'm an electronics engineer, not a PC programmer, but I'm more than happy to learn and assist any way I can.

Cheers,

Rich.

---

[richrap.blogspot.com]

joshnuss Wrote:
-------------------------------------------------------
> The idea is to do the Gcode parsing on the RBPI
> and issue I2C or SPI commands to the firmware on
> the atmega. The firmware will be very dumb, it
> will just accept commands like how many steps to
> move the motor, or to check the adc value of the
> thermistor. the real meat of the software will be
> on the RBPI

Which side will do the path planning and acceleration ramping calculations? That's the real meat of getting the printer move quickly and accurately. Hmm, I guess you could do that on the non-realtime side and then send accelerating/decelerating pulse schedule commands to the realtime side. The realtime side can then output the pulses using simple constant acceleration from start frequency to destination frequency (=speed, but the driver doesn't need to know that). It can do that and still be pretty dumb.