Raspberry Pi RepRap and python

Actually, the original FiveD firmware has the concept of calculating ramping and look-ahead on the PC side already. This concept was abandoned by later firmwares like Sprinter. Doesn anybody know why? Is anybody still running FiveD?

---

Generation 7 Electronics	Teacup Firmware	RepRap DIY

Traumflug Wrote:
-------------------------------------------------------
> Actually, the original FiveD firmware has the
> concept of calculating ramping and look-ahead on
> the PC side already. This concept was abandoned by
> later firmwares like Sprinter. Doesn anybody know
> why? Is anybody still running FiveD?

I have not heard of any of the popular slicers supporting that, and without it FiveD is so amazingly clunky compared to the accelerating firmwares.

Plus, it would require the slicer to be very aware of the machine characteristics. It would have to know the acceleration characteristics and the serial link behaviour. Consider the printer with path planning on the host side printing a large circle with small segments so fast that it saturates the serial link and the printer arrives at the end of the data too fast and doesn't have the next commands received and decoded yet. It would have to do some sort of an emergency stop. The firmware path planner only plans as far as it has received data, so it will always be in a safe state even if it's running out of commands. It will just stop and continue when it has more.

Quote

without it FiveD is so amazingly clunky compared to the accelerating firmwares.

That's true. Using a firmware made for acceleration calculation on the PC side with G-code calculated for acceleration on the controller side (or no acceleration at all) gives a mess. One of the things where this famous majority of the community didn't get the idea and an accordingly, an idea with a good principle was abandoned.

I think the bottleneck of the implementation was, FiveD didn't do movement buffering at all, so after the acceleration ramp the controller had to wait for the plateau movement to be sent through the serial line and this takes longer than a step time, especially at 19200 baud. So you had always a pause between acceleration ramp and plateau movement, rendering the implementation useless.

A missing movement buffer can be added, of course. Modern firmwares show examples. My broken record says, "Teacup has both, ACCELERATION_REPRAP and a decent movement buffer".

Quote

The firmware path planner only plans as far as it has received data, so it will always be in a safe state even if it's running out of commands. It will just stop and continue when it has more.

Is the GRBL/Marlin path planner safe in this regard? Also for the case where the path planner updates a movement junction at the same time the earlier movement becomes the current movement, so one of both ends can no longer be changed? So far I didn't read about how robust this planner is regarding buffer underflows and I didn't find time to test this myself, yet.

---

Generation 7 Electronics	Teacup Firmware	RepRap DIY

Just to add that the biggest hurdle to overcome with using the RPi as a host for pronterface/slic3r/sf/etc is that its video core supports OpenGL ES 2.0 and not fixed-pipeline OpenGL. Not only that, but currently, there is no way to get an OpenGL context through X11 to render with but that will change in time I hope.

IMO Anything that requires Sun Java + Java3D looks like it will have the most issues to overcome to port. Pronterface and slic3r should work almost OOTB.

richrap Wrote:
-------------------------------------------------------
> 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?

You could try 230400, it's the closest that might be supported. I think in Linux baud rates must be on the defined list, and 250000 is not one of them. There is no standard way to specify arbitrary baud rates. The termios.h definitions for baud rates will be in one of the files under /usr/include.

Unfortunately there is no way to find what the list of baud rates supported by a particular driver is from application code, they need to be hard coded. So all the supporting software, stty, the kernel driver, possibly run time library code etc also needs to know and allow the baud rate setting.

I would guess 230400 should work with FTDI drivers.

Traumflug Wrote:
-------------------------------------------------------
> Is the GRBL/Marlin path planner safe in this
> regard?

Yes, path planning is done on all commands received to date, so that the last move in the buffer will decelerate to zero. A new command received will cause the path to be replanned accordingly.

> Also for the case where the path planner
> updates a movement junction at the same time the
> earlier movement becomes the current movement, so
> one of both ends can no longer be changed?

There is actually a bug in grbl here, it will recalculate the current move while it is in use. A lot of the time this will not be noticed because accel/decel is computed on the fly, occasionally I think it caues a glitch in movement. In my port of grbl, I precalculate the accel and this bug causes a major problem. I think the obvious answer is just to not replan the current move, but I haven't implemented a fix yet. grbl uses a queue which is backwards to the normal convention so does not help clarity (ie. the meanings of head and tail are swapped). I am trying to resist re-writing that code!

Quote

I think the obvious answer is just to not replan the current move

Not the current move and not a few later ones, as movements can be too short to give the time to re-precalculate everything. Some movements are one step or even zero steps, one never knows what's coming in. pcb2gcode, for example, does one movement for every 0.04mm (600 dpi), a stress test for every path planner. EMC2 apparently manages this fine, though.

Maybe the answer is to re-precalculate on a copy first, then swap the values as quickly as possible with interrupts disabled. Still not for the current move, of course.

Is your port of GRBL available public somewhere?

---

Generation 7 Electronics	Teacup Firmware	RepRap DIY

Traumflug Wrote:
-------------------------------------------------------
> Not the current move and not a few later ones, as
> movements can be too short to give the time to
> re-precalculate everything. Some movements are one
> step or even zero steps, one never knows what's
> coming in. pcb2gcode, for example, does one
> movement for every 0.04mm (600 dpi), a stress test
> for every path planner. EMC2 apparently manages
> this fine, though.

That is a very good point, I will have to think more on that.

> Is your port of GRBL available public somewhere?

Sure, it is in the firmware for the R2C2 controller [github.com]

On Pi faq says "with arm and newer ubuntu releases .... "
But how about older ubuntu releases like 6.06, could use emc2 with that?
There are lots of sources for current or older emc2 releases. Anybody tried anything around that area?

Having Ubuntu running on a platform doesn't mean there's a realtime-kernel on this platform, too. Without realtime kernel, trying to drive a stepper directly is pointless. When driving non-direct, there's no need for EMC2.

---

Generation 7 Electronics	Teacup Firmware	RepRap DIY

[wiki.linuxcnc.org]
[wiki.linuxcnc.org]
[wiki.linuxcnc.org]

From my limited understanding can compile it all from source, and historically could be possible at least on older fedora and also debian (Pi), although the livecd currently comes on ubuntu. On the long shot since Pi is basically the exact hardware all around, i am just thinking that it might be worth even making a precompiled emc2 distro, dedicated to run on Pi.

Well at least the thought of this is nice. Although its beyond my abilities, and i cant evaluate the potential issues, hence i am asking this around. I think it is worth taking a shot at, if someone with a board is willing.

Edited 1 time(s). Last edit at 06/13/2012 09:40PM by NoobMan.

@RichRap I love how you sneak monumental, precedent setting work into a three sentence post between printing cups for a little girl birthday party and a puzzle ball. So you are successfully using a Rasberry Pi as your PC interface to Pronterface!? I sure hope you make a nifty how-to/lessons learned post!

My head rushes with ideas of touch screens and fully self-contained fully-featured RepRap printers! Keep up the great work!

Edited 1 time(s). Last edit at 06/24/2012 05:08AM by Idolcrasher.

my 2 cents:
If you have heard of EMC2Linux - an OOS CNC controlling software. Basically it's very similar to what being discussed here (acceleration calculation in PC, realtime in uC). The point I am trying to make is - it's definitely doable, and if accomplished would be very powerful, but I expect it's no easy job.

Doable
EMC2Linux - it distributed as a Ubuntu package, which will install realtime kernel to Linux. Steppers could be controlled by old-day Parallel port bitbang (realtime kernel!), or offloaded to "dumb" controller that expects speed command on each axis.
The acceleration and motor profile calculation (including feedback calculation if Servo is used instead) is done in PC with a real time thread running at 1000Hz. Another thread of bitbang running at ~50us if parallel port is used to command the stepper driver. The resolution of the bitbang thread limits the CNC speed.

Powerful: RPi is just yet another PC...or Smartphone, it just runs Linux AFAIK. If we could get such a dumb IO controller (in the sense of accepting speed command, but not doing GCode stuff), we could actually hook that up with ordinary PC/Windows. Or we could every port it to EMC2Linux to leverage its logic controller, UI, acceleration profile calculator, etc. A lot of fancy logic and operation could be implemented on the software side. Hell, we could even free ourself with GCode.

No Easy Job
Recalled that EMC2Linux uses 1kHz thread for acceleration profile calculation, it actually also has a very hard limit on the latency and jitter (smooth transmission).
For ordinary kernel/PC, USB/Serial interface transmission is not real time. The resolution of USB is just 1ms at most (max interrupt frequency)! If speed command can't be updated smoothly every 1ms, I expected print quality or print speed would suffer.
Either someone need to sort this out (Realtime kernel on RPi?...ouch).
Or maybe the controller actually a little bit smarter that could calculate acceleration and hence update could be less frequent? After all, all these calculations are implemented in the current firmware. (IMHO this is where the split should be)
At any case, the split (which needed to be done on which platform) needed to be carefully made - and experimented.

Kudos to anyone who is getting his hands dirty on this =)

Thanks, That made me smile

I got it all up-and-running on the RPi, but the only HDMI screen I have is in the living-room, so it's a bit of a pain to get it all setup again, and you need a powered Hub for the Arduino as the RPi USB ports are really bad at power delivery so it starts to look a bit manic with a screen, mouse, keyboard, hub, PSU and second PSU for the RPi and a 3D printer on the floor. Other than that I will do a guide on the Blog as soon as I get a little time to set it up again.
The RPi is nice, but it's a bit like using a Pentium II most of the time.

What would be much nicer and easier is Pronterface on an Android Tablet with a Blue-tooth link to the Arduino.

And the birthday party went very well

Rich.

Idolcrasher Wrote:
-------------------------------------------------------
> @RichRap I love how you sneak monumental,
> precedent setting work into a three sentence post
> between printing cups for a little girl birthday
> party and a puzzle ball. So you are successfully
> using a Rasberry Pi as your PC interface to
> Pronterface!? I sure hope you make a nifty
> how-to/lessons learned post!
>
> My head rushes with ideas of touch screens and
> fully self-contained fully-featured RepRap
> printers! Keep up the great work!

---

[richrap.blogspot.com]

Has anyone tried wiring directly to the RPi serial port on the GPIO header? Just wondering if that might be simpler than USB-to-serial cables.

A quick search on RPi forums reveals that people got SPI and I2C. ATMega supports both too.
Which is more superior than UART/Serial because clock signal are also sent along and hence could run at much higher speed. IIRC could run at ~1Mbps, compare to 115200 on UART.
And these bus support multi-slave devices too.

Edited 2 time(s). Last edit at 07/06/2012 01:41AM by sam0737.

Sure, I just figured a straight serial connection might be the easiest. And a short serial connection might be more reliable than a USB to serial converter cable. That cable is kind of a hack anyway due to the waning availability of serial ports on modern computers. But since RPi has one it seems more efficient to just use it. I guess the programming would be fairly simple to change to I2C or SPI but many people won't have the experience to do that kind of firmware hacking.

richrap Wrote:
-------------------------------------------------------
> 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?


Same Problem here - I think it's a problem of Debian, not of the Raspberry PI.
I tried on several PCs, running Ubuntu it's fine with Pronterface and 250kBaud, using Debian on the same Hardware doesn't connect.
230kBaud might cause Problems, because the Controllers don't use a Baud rate Oscillator. With 8/16MHZ you cannot generate clean 250kBaud.
The FTDI-Chip will translate this without Problems, but the CPU might have Problems. That's why they choosed 250kBaud instead of the usual 230kBaud, it simply matches better with the 8 or 16MHZ clock rate.
Pity, I would really love to use one of my Raspberry PIs as a WLAN Printserver for my Reprap.

Why it works with Ubuntu, and not with Debian? The OSes are quite similar, what might be the difference?

-Michael-

Hi joshnuss,

Great idea .... have you commissioned your new board using TI DRV8810 drivers ??? How was the performance?? Possible to get the Eagle / gerber files

@WDZaphod & Richrap:

I'm running Debian on my desktop and just tried yesterday connecting Pronterface to my Arduino/Ramps, and it worked at 250k out of the box. It was just a quick connection test though, but it worked well, got warnings about the thermistors (which weren't connected). So your problem is probably not Debian specific, or maybe a specific combination of hardware and Debian.

What version and kernel are you on? I'm on testing/unstable with an 3.2.0-2-rt-amd64 kernel (i'm using it for some sound recording, hence the RT kernel).

I'm gonna try updating my Raspbian install on the Pi tonight, install Pronterface, connect the Ramps and see how that works out. I may try to get X11 over the LAN running too, or just haul the whole mess into the living room and hook it up to the TV, haven't decided yet...

This weekend I'll give building an RT kernel on the Pi a go. Shouldn't be too hard, just flick some switches in the config and recompile, and wait for a very long time . I guess i'll find out soon enough...

I guess that will be a soft RT kernel though, I doubt any hard RT patches are in the mainline/debian kernel right? Custom patching is probably needed for that, a bit much at this stage. So it won't be much use for directly controlling motors and what not, but should at least help with not getting xruns mid print.

Thanks, I have it working at 115k2, but would still like 250k if possible.
Just spotted the new build 'wheezy' so that's worth a try at some point.

---

[richrap.blogspot.com]

Just a quick update, just tried pronterface over the lan on the Pi @250k, seems to work ok, i get the same feedback from the firmware (marlin) as when connected to the desktop. This is on Raspbian (kernel uname is 3.1.9+ #138), the new image may not be identical to my install, but should be close enough. Could be that the old (non hard-float) Debian image doesn't work the same way.

Haven't tried wiggling any motors yet (at all actually, my printer build is still in progress), but i'm sure that should work too.

PS I forgot how easy X over ssh is to setup, you just need to make sure x-forwarding is enabled on the ssh server and client and thats it. (assumes *nix client, can also be done via cygwin on windows, but is slightly more complicated). Theoretically this should allow for wireless control of the Pi/Ramps combo over wifi. Will try wifi stick this weekend.

Okay, I will give a try to the new RasPI Debian Image - might work better :-)
On the "normal" hardware I use a standard install of Debian 6.04 without any mods. Board was a Atom 800MHZ single core Mini-ITX Board.

X over SSH is nice, but it kills the session when you disconnect (of course). That's why I used VNC with autostart session after bootup. This stays alive.

Sure *nix client, my house is 100% Win-Free, and 99% M$-Free :-)
The 1% is a Kinect, connected to my Macbook for 3D-Scanning...

I ordered a RAMPS 1.4 plus an Arduino Mega - does this work fine with 230kBaud?
Thanks for testing!

Yep, Ramps 1.4 and "Arduino" Mega 1280 is what i'm using.
Come to think of it, my "Arduino" is not genuine Arduino, but one of those fully equivalent knock-offs. I would think they'd use the same USB-serial chip though, so it shouldn't matter. I'll have a look at "lsusb" when i get home this afternoon to see what chip it reports.

Just to confirm, my usb-serial chip is an FTDI 232RL (device id 0403:6001), i think this is the same as in the official Arduino, no? Modules loaded are ftdi_sio and usbserial.

Yes, but the FTDI is not the problem in my Setup - it works fine with all PCs I tested under Ubuntu and 250kBaud.
My current Reprap had a Melzi Board.
When I'm back home from holidays, I will check how the new RAMPS behaves, and also the newest Rasperry Image!

Yes, it's probably just some subtle difference in the FTDI kernel driver between squeeze and wheezy. I was just confirming that my board does have a "standard" usb-serial chip.

I've now tried connecting through wifi, and it works fine.
Configuring the wifi on the Pi is the same as any other Debian config, no surprises.

The exact procedure varies slightly with what stick/driver you're using, in my case (carl9170) one has to install the firmware manually. Otherwise it's just standard wpa_supplicant/iwconfig stuff, plenty of info for that on the web.

Regarding RTAI and EMC2/LinuxCNC I't looks like that may take quite a bit of work to get going on a Pi: See forum thread over at raspberrypi.org

I'll try my hand at recompiling the raspbian kernel with soft RT support first, unless there's something tricky in the Raspberry Pi drivers/patches that shouldn't be too complicated.

I realize I am a bit late to the party but I only recently received my Pi...

First off: I think using linux for real-time tasks is a poor mans solution if we have ATmegas that do a bang up job controlling everything. I've been playing around with the current debian kernel and I managed to hang things like the USB controller and HDMI output way to easily: the CPU is not up for this multimedia violence. Add realtime control in the mix and I doubt it will even work (reliably). Just my 2 cents.

Currently, all HDMI output is done via the propietary drivers from Broadcom. The upside is that they do seem to support DirectFB, which means one could ditch X and its overhead and render straight into an accelerated frame buffer. I found performance tests of people using DFB over Xorg and if you really need the CPU cycles for other stuff (like running a 3D printer), its probably the way to go. On a side note: I saw something about Java running on X. Last I heard this was painfully slow, as in 100% CPU for stuttering 2D interfaces slow.

I'd love to have some LCD (over HDMI) panel near my printer connected to the Pi to show progress and stats, but currently I don't see that happening on my set up. So instead, I am opting for the networked printer approach. I want to have a web-based panel (hosted on the Pi) showing progress and allowing me to control the printer.

The details are currently fuzzy but I started on an Android based host program and abandoned that because the Android 2.1 and 2.2 kernels refuse to play with my FTDI 232RL board for the RepRap. Of course I found out about this after I completed the G-code parser. As such I'll probably start out with a Java based host program for the Raspberry Pi. As an added bonus, such a system would of course also run fine on an old laptop with a broken screen or similar...

Edit: I just realised that I did not explain that I based my view on the assumption that the RPi will end up with a stack of Java/Python/Xorg which looks like a performance train wreck. If it gets optimized with DFB and perhaps some parts of the host in native code, perhaps it becomes a more realistic work load for a 700MHz ARM...

Edited 1 time(s). Last edit at 07/22/2012 03:29PM by Cyberwizzard.

Of course it would be nice, but I think web based it not a need if u have a screen connected to your PI.
Just start X, open Pronterface, and you'll see all you need.
IF it works with 250kBaud.
The ATMega runs with 16MHZ, this is not a baud rate frequency. So 230kBaud will cause jitter probs, beause it simply doesn't match. And (at least my) RasPI / Debian seems to not support 250kBaud, hopefully this changes with the new Image.