RepRap part 3: Ethernet connection

With the X and Z gears propperly glued, all axes moved. But it didn’t take long for the Z axis gear to break again. The gear that came with the kit was multilayered wood glued together and laser cut. The place where the belt is, is off the axle of the stepper motor. That’s obviously not a good combination. So I ordered an alloy gear from maedler. That came without a hole in the center. I didn’t have anything else then my hand drill available. Well it’s a bit more off center then I had hoped, but nut much worse than the laser cut wooden gears. And still, it works. So, all three axes work now. The ammount by what they move doesn’t seem right, so I’ll have to adjust some parameters still.

Also the Extruder works kind of. I extruded the first few centimeters of PLA. But one thing that’s strange is, that every second, it makes a short pause where the extruder wheel slips back a bit and then continues. The same pause also happens sometimes when I do a G0 on one of the axes.

In the meantime I found a blog post on the internet where someone wrote, that SD card support is a very important feature for him for the RepRap electronics and firmware. For the Gen7 I saw some advices about how to connect an SD card, and I also saw it on the ToDo list for the next revision. Additionally, at the moment I had to extend the USB cable twice to reach the RepRap.

So I added a bifferboard which runs debian to the RepRap. It runs from an SD card with some 2GB spare space, and connects an USB to the FTDI. If I should need the USB port or the FTDI for something else one day, I could also connect the bifferboard’s internal serial pins to the Gen7 electronic. The procedure to use the internal serial pins for this kind of stuff is described in an earlier post. I grabbed the power for the bifferboard from the SPI pins on the Gen7 board. That was the easiest place to get from the standby power of the ATX PSU. Obviously, when I want to use the SPI interface to flash the AtMega, I’ll have to power the bifferboard from somewhere else. The eathernet connection is onboard, so just plug in an ethernet cable, and off you go.

Now I can ssh into the bifferboard an run minicom to send some G code commands. I can do this from my smartphone from anywhere on the internet. The commandline version of printrun is also installed on the bifferboard. For this I created deban packages for printrun. The code to that is on : https://github.com/ulrichard/Printrun and the packages that are automatically updated by jenkins are at http://apt.ulrichard.ch

To use pronterface, the GUI of printrun fromanywhere, I share the serial connection over ethernet with socat as described here:

On the bifferboard :

$socat tcp-l:54321,reuseaddr,fork file:/dev/ttyUSB0,nonblock,waitlock=/var/run/ttyUSB0.lock

On the client computer:

$ sudo socat pty,link=/dev/ttyBIFF0,waitslave tcp:192.168.1.20:54321
or
$ socat pty,link=/home/richi/ttyBIFF0,waitslave tcp:192.168.1.20:54321

Now connect pronterface.py to the virtual ttyBIFF0. With this, I don’t need a double extended USB cable anymore, and in the future, I might run the RepRap in the basement without a computer nearby.

 


Posted

in

,

by

Comments

2 responses to “RepRap part 3: Ethernet connection”

  1. Marki Avatar
    Marki

    Hi Richi,

    interesting post, although admitedly I only understand a fraction of what your saying. I am a hardcore newbie to all engineering and computer related aspects, nonethless I am commencing in a project with a professor to build a reprap 3D printer. We were thinking of using a raspberry pi to connect the printer to the internet and to enable sending files via email to the printer, which would relieve us from having to use any cables or SD cards. As I am highly underqualified for what I set out to do, perhaps you could enlighten me to wether or not this is a possibility?

    kind regards,

    Marki

  2. ulrichard Avatar
    ulrichard

    Hi Marki,

    my raspberry has yet to arrive, so I have no experience with that.
    But I see no reason why your idea should not work. Just write a cron script that polls an email address, and starts a build when a suitable file is received. Depending on how many people know the address, you will have to add some sort of locking and a queue in order to start a build only after the last one was removed from the printer. You might also want to add some physical buttons to the GPIO lines to enable some immediate control. E.g. a big red emmergency stop. Another button to indicate that you removed the part.
    I for my part prefer the direct control I have when ssh’ing to the device, while your email solution is more asynchronous. Tools like tmux or screen are really handy for such ssh connections.

    Rgds
    Richard

Leave a Reply

Your email address will not be published. Required fields are marked *