Raspberry Pi RepRap and python

A web interface might be a little overkill, but it's a cool idea though. The benefits i can think of are that it's probably more lightweight than an X-tunnel/VNC and it would be quite nice for remote control over the internet.

This got me thinking which of VNC or X is better for system load? I have a hunch X is, since it doesn't have to render or compress anything on the Pi. And there's no need for a WM on the Pi either.

I havent' finished my reprap yet, so i couldn't tell you what kind of load average you'd get mid print, but I suspect it should be workable. With pronterface sitting idle with an X-tunnel i get about 2-3 % load from python. There are peaks when i do stuff like connect to the board, worst i've seen was about 70%, but usually around 15-20%. Sshd also uses a bit more when active, about 5%. The load average is barely changing though (0,02-0,05), so they are quite fast peaks.

If performance is a problem it could probably be dealt with.
With a soft RT kernel we could prioritize interrupts/threads so USB/Pronterface/Wifi gets preference over less important stuff. Also a slimmed down environment could be beneficial (no logging, cron etc.).

But now i'm rambling, i need to build more and forum less .

With VNC you also don't need to start the window manager, I just start up Pronterface and one instance of xTerm behind it (to start Prontface again if I have to quit).
VNC has the advantage of the persistent session, you can disconnect, and it stays alive. X will terminate pronterface if you get disconnected.

One more tidbit regarding the Pi is I've found it hanging when uploading firmware to the controller board via the Arduino IDE. When I've tried this, Iv'e been powering the Pi/RAMPS/USB Hub with a 24V/5V 2010 mA car plug adapter running off my 24V supply.

I suspect that may be the cause, it's been rock solid when runing otherwise, but the Pi is very sensitive when it comes to power source. Maybe the upload draws extra current in the flashing stage. I'm gonna try it again and compare with powering the hub (and hence the Pi and Ramps) off an AC adapter, checking the voltage during flash and see what gives.

Inspired by RichRap's progress, I installed Pronterface on my RPi tonight. I have the new Raspbian distro running. Took a while to obtain all of the dependencies needed, mostly because Linux is relatively new to me. But it is up and running. My only issue is the speed. It seems like there is a 15 to 30 second delay on most commands. Haven't printed with it yet but will try it out tomorrow. If I have time, I will try and put up a semi tutorial on my blog.

What baud rate are you using, 250kBaud?

I'm running at 115200. 250K wouldn't connect (even on the new Raspbian distro). I think my issue was a power supply problem. My RPi was running on a 700mA PS and I think I needed more. I have a 2A one to try today.

I noticed when I was using my wired keyboard, mouse, and printer that the lights on my keyboard (caps lock num lock etc) would go on and off. Although I'm using a powered USB hub, I think my PS was not enough between USB, the Pi itself, and the ethernet connection.

I will try again tonight.

Slic3r did not want to run for me using the precompiled linux version. I am going to try and install it the long way, including each of the dependencies seperately and see if that makes a difference. Haven't looked at Skeinforge though. I am also considering putting together a quick python script to run Prusa's reprap calculator equations. I saw that mentioned by someone else on the forum. But one thing at a time. I first need to get everything running reliably and put together a tutorial on how to install everything.

15-30 seconds seems like a lot. I do get delays, but most of the time only about a second or so.
Check that you don't have packet loss on the network link to the Pi, that might cause those issues.

I tried running skeinforge a few times, but since I'm a reprap noob, the config seemed quite daunting, and i couldn't get it extruding properly. It's also painfully slow slicing, so I'm now installing slic3r as i'm typing this.

A thought popped into my head that may be worth investigating...
One could theoretically use the Pi as a networked USB server using "usbip".
If it works, it could help with the lag, since all the control software would be running on a remote (more powerful) machine.
Although, i'm not sure how this will affect the quality of the USB connection, it may not be practical at all...

Unfortunately usbip requires building a kernel module which was not too straightforward (lack of kernel headers for the running kernel). I tried installing the new alpha 3.2.0-3 kernel which has a nice headers-package, but that gave me some mysterious errors so i've given that up for the moment.

Once i get to the stage where i can actually print, I'll do an interim solution so i can slice on my desktop and output to a network share on the pi, then run pronterface on the pi just for gcode pushing.

I will eventually try this usbip thing, if nothing else for the sheer nerdiness, but for now I'm too eager to get ready printing my first print.

I think the delays were due to faulty power on my USB hub. I've got it running good now, without the delays. Sometimes it has trouble connecting, but it eventually gets there.

I put together a blog post real quick, (I'll update more tomorrow) but this explains the process I went through to get it working. Relatively straight forward if you're a previous Linux user, but might be a little more challenging to someone brand new.

Here is the link to my blog: Entropy Projects Blogspot

I'll go into more detail and put links on there tomorrow. Let me know if you get Slic3r running. I didn't get a chance to mess around tonight.

I at least managed to build Slic3r, but i haven't got time to test it right now, i'll update later.
There were some dependency problems, make sure you have gcc-4.7, g++-4.7 and pkg-config installed, as well as the other packages mentioned for "ubuntu users" at the bottom of the Slic3r homepage. Maybe extutils-cbuilder-perl too.There might have been one or two more, keep an eye on the build log to see if something seems to be missing and cause build errors.

I will mess around when I get home tonight. Are all of those dependencies available from the repository? Or do I need to find them else where?

Yes you should be ok with the standard raspbian repository.
The Slic3r install will auto install a lot of Perl modules from CPAN.

(I'm actually not a big fan of this aproach in general, it makes the system messier to admin since you can't track the modules via debian packages, but i was eager to print, lazy and tired, so what the heck For those with admin OCD try dh-make-perl)

One dependency i may have missed in my previous post is Math::Libm.
"sudo cpan -i Math::Libm" to install.
(actually sudo is probably not setup in a standard raspbian install, try "su -c command" if it's not working)

Possibly the installer will install Math::Libm for you at a later stage, it's quite smart, but I saw a *lot* of references to it and installed it before i figured out gcc/g++ was missing.

I have now tried Slic3r standalone, and wow, it's orders of magnitude faster than skeinforge!
I sliced [www.thingiverse.com] in a few minutes on the Pi, it took something like 30-45 minutes with skeinforge. Slic3r makes slicing on the Pi quite viable, I wouldn't have considered it an option at the speed Skeinforge was going.

Now I'm off to set up slic3r with pronterface, should be straightforward...

Oh yeah, Slic3r is loads faster than Skeinforge. Even on a fast computer Skeinforge takes forever. Slic3r never takes more than a minute or two at most. (Usually a few seconds) I'm sure it'll be slower on the Pi but atleast it's feasible.

I will try and install Slic3r tonight. I will put together another quick "tutorial" on the steps for anyone interested in the future.

I'd love to get a RepRap specific Distro for the Pi. Include all programs and dependencies. Would make it a ton easier, just write the image to the SD card and print. (theoretically)

Be aware that the current state of slic3r (which you'll get building from git) seems to have slightly illogical configuration file handling. It seems to save config files in four different folders, but with nearly identical contents. I couldn't figure out how this was supposed to work, so I hand edited the file i call from pronterface (otherwise it would try to wait for my nonexistent bed to heat up before printing).

Ahh, nearly there now, i forgot to correct my extruder steps per mm in marlin, it had an old, way off value so my first print had about one tenth of the extrusion it was supposed to. Just a compile and upload away...

From my previous experiences with Slic3r, it will save the config file (if done from the slic3r GUI) to which every folder you last sliced from. Or atleast thats the ways it's working on my windows and mac computers. If you are slicing from Pronterface GUI then it has it's own config settings. I am always tinkering with my settings so I always use the slic3r GUI to do my slicing.

Take note of the acceleration settings on Marlin too, they are set pretty high by default. It'll lead to some crap printing if you don't adjust them, depending on your printer.

I haven't installed Slic3r yet, I was messing around getting my Pi to run off an old portable DVD player screen. I plan on integrating it all into my current MendelMax1.5 build.

Here is a quick tutorial on Slic3r installation. Thanks to anwe79 for the help with the extra dependencies needed. This should get your RPi slicing.

ANWE79:

Were you able to figure out the "USB/IP" solution for the Pi? I've been beating my head on this for the last couple days.

No not yet, I've been redoing some work on my printer's mechanics so i haven't really had time to mess with the software.
I think i'll have to postpone the USBIP stuff until i get my printer printing reliably.

An unrelated note: I have found one small annoyance with running directly off the Pi;
Pronterface get's quite laggy and unresponsive during print. It may not be a real issue if you are printing reliably, but trying to stop quickly mid print get's aggrevating .

This was with a display directly connected to the Pi, so maybe the extra load of the X environment plays a part (running the extremely lightweight dwm). I was doing this at my dad's due to a lack of linux box there, I'll retry tomorrow over ssh and see how it compares.

I setup the pi from these instructions Thingiverse pi setup.

I could only connect at 115k. I also noticed extreme lag from interface buttons to the action occurring on the printer (Printrbot with printrboard). Pronterface on my Mac is almost instantaneous. I also noticed the power problem so I reconfigured all devices to the powered hub in the monitor which eliminated the power issues (mouse erratic or keyboard erratic).

When I tried to print from the pi it was extremely slow. The print head would move a few centimeters, pause for seconds, then move some more. It probably took 10 mins to do what was seconds on the Mac. I shut it all down. I'm picking up another couple of sd cards tomorrow to try different setup's such as the one outlined by entropy for overclocking.

Is there a way to spin up the web pronterface without starting 'x'? The x window manager is sucking all the performance. I tried different ways, but it always whined. Will dig into doc's tomorrow. Unless I can get the speed to improve, it's unusable. Hate to do it, but it seems like it's better to dig out a windows clunker box (meaning old system from the junk pile) and vnc it as a 3d print server.

On the plus side, I did get netatalk running quite easily.

Bob

Quick update. I've printed several times from my RPi. The one strange issue I have is my USB keyboard. I'm using a Legitech K120 (all the list of verified hardware). If I unplug my keyboard, I connect to my RAMPS 1.4 through pronterface instantly. If my keyboard is plugged in, connecting becomes an issue. Sometimes there will be not issue and it will connect. Other times I have to start up Pronterface multiple times. Not sure why the keyboard is screwing up the RAMPS port. It doesn't effect any other hardware I have plugged in. I'm going to try another keyboard and see if it makes any difference.

i have (for now) given up on this, looking at the 'elephant thread' on the raspberry forums every once in a while if there is a final solution to the usb woes...

[www.raspberrypi.org]

working on a tplink wr703 with openwrt now to get it to feed the printer.

grtx

Another update:

Turns out it was my keyboard that was the problem. Swapped it out and have no issues now. I did set up a VNC connection between my RPi and Desktop. This allows me to remotely view my RPi's desktop. No monitor needed.

So everything is all ready to go. The RPi is a full printing machine.

Entropy Wrote:
-------------------------------------------------------
> Another update:
>
> Turns out it was my keyboard that was the problem.
> Swapped it out and have no issues now. I did set
> up a VNC connection between my RPi and Desktop.
> This allows me to remotely view my RPi's desktop.
> No monitor needed.
>
> So everything is all ready to go. The RPi is a
> full printing machine.


So how is the speed? I have acquired a faster DS card and put the image on it. Was waiting for a better USB power source that just arrived so will be playing with mine over the weekend.

Bob

> So how is the speed? I have acquired a faster DS
> card and put the image on it. Was waiting for a
> better USB power source that just arrived so will
> be playing with mine over the weekend.
>
> Bob

The speed is fine. When directly connected to the RPi the printer is controlled like normal. When through then VNC connection, there is a slight like, half a second or so, but that's because of the connection. When using the VNC, Ive had the RAMPS hooked up directly to the RPI with no other USB connections and it worked fine. The main issue now is downloading thingiverse files. The web browser is so slow. And Slic3r slows down the RPi but that's expected.

TightVNC for Linux doesn't allow file transfers. If it did, I could slice on my desktop and transfer to the Pi.

I have also connected via VNC to the Pi thru my android tablet. That was pretty cool too.

I configured netatalk and dropping a file to it was fast. I just put a shortcut on the desktop. for pc,samba.

Of course printing the file was extremely slow, but that may have been flaky power etc.

On a different note, I have never been able to print from sdcard on the printrboard even if i inserted the card and copied directly then reinsert, power up the printrboard.
it allways stops at some point. Yet the same file prints fine from pronterface.

Bob

seems like the work can go on, the latest kernel patch seems to solve the usb speed issues.
the driver uses something called 'fiq' now, which is a higher level interrupt (as I meanwhile learned).

the advice is at [www.raspberrypi.org]

had my rostock printer moving at normal speeds today ;-)
my firmware spit a lot of positioning info back to the raspberry which made pronsole.py use 50% CPU time. after I disabled that, it went down to 20%

grtx

Yeah, 250kBaud works now!
My PI boots up with VNC started, Pronterface running inside. Samba installed, sharing the gcode-Folder.
Nearly perfect, just the screen could be slightly bigger

hm, have you connected your setup to an actual printer ?
i have pronterface running now, but it chews up 95% CPU while serial transmission prints a few steps, then pauses, then prints and so on. the only task that could make pronterface use that much cpu while printing is the redraw of the traces on the screen, so maybe one should look into disabling this feature...

grtx

i just disabled the graphic object viewer, now pronterface runs happily with 20% CPU load ;-)

42loop Wrote:
-------------------------------------------------------
> i just disabled the graphic object viewer, now
> pronterface runs happily with 20% CPU load ;-)


I'm having exactly the same problem when printing from my RPi on my Orca. Can you describe how you have disbaled the graphic object viewer?
Tnx!

i don't have the raspi here right now, but just open pronterface.py in a text editor, look for the import line around line 17 and remove the 'gviz' import.
then try running pronterface from the command line, and it will throw some errors concerning gviz not defined. go ahead and comment out all lines referencing gviz and gwindow, mostly these are in the popwindow() function.
ugly hack, could be done nicer, maybe we should request a 'nographics' feature - or I should learn how to properly file a pull request on github...

grtx