My name is Ally Hubbell and I’m head of PR for a new startup called Photon Elephant. We just launched our Kickstarter campaign to release our Raspberry Pi based 3d printer electronics kit.
This may seem similar to octoprint, but our approach is drastically different. We are running the printer effectively without any arduino between the pi and the motors/sensors.
This lets us do a bunch of cool stuff that you have come to expect (onboard slicing, Wifi, Web Hosting etc), but unlike octoprint, we can also have things like Pause/Resume functionality.
My personal favorite part of the platform is the SDK (HUGE time saver here.) We want to empower the hacker community to make changes to the underling print process without having to dig through source code to find the exact things you need to modify.
Instead we have created an SDK which makes it easy to incorporate feedback and add new functionality like extra motors or other electrical utilities.
My concern with the “no Arduino” approach is that you have a microcomputer running a real-time operation (printer control). A hiccup in the operating system could result in a short pause in the printing or, worse, missed steps.
I’ve always trusted microcontrollers to handle real-time operations. No OS to get in the way.
Also, closed-source kills it for me.
Anyone spot the elephant in the room? (Sorry, couldn’t resist!) Being able to split functions into multiple processes running at different priorities would be nice, e.g. temperature monitoring independent to moving the head and extruding. Owning a couple of Pi I can see a lot of plus points to this, but as Carlton says you’d want to be sure that stepper control isn’t compromised, ever. “You uploaded an STL via WiFi and wrecked my print” would kill its use. Maybe have stepper control as a kernel module rather than user space code? But closed source and an unfinished SDK? Still worth a punt for experimenting at the price. You should get a unit to @Thomas_Sanladerer for review ASAP.
Having a separate arduino doesn’t prevent pausing and resuming. I’m not sure about OctoPrint, but BotQueue already has it implemented in the drivers. I’d be surprised if OctoPrint didn’t.
W don’t guarantee time, we guarantee coordination of movement, which in practice doesn’t impact print quality. We’ve spent some time pulling more information together on our FAQ on the kickstarter-It’s at the bottom :)
“As a result, instructions getting interrupted for microseconds at a time is no barrier to a quality print” Get enough user space code running and stepper control could go out the window if not a kernel function or “niced” over everything else. I’ve seen enough systems fall apart under heavy load, and a Pi doesn’t have the resources of big systems. Got some real world data to prove otherwise? I still like the idea, just wonder how user/idiot proof it will be.
The pi is our starter point and we are planning on expanding to faster chips. Our goal truly is to make 3D printing more accessible, and to open up the industry to more and more innovation.
Although we aren’t able to idiot proof quite yet (see’is it turned on?’ ‘is it plugged in?’)
We are creating a framework with which allow more and more people to collaborate, (language and printer agnostic) and hopefully begin to open up the channel that puts 3D printers in everyone’s home.
I’m not sure about slicing on the RPi. I’ve had models take a long time to slice on a quad core i5. I can’t imagine how long it would take to slice on a RPi!
The premise for the rest of the project is pretty neat though. I’ve added it to my watch list
Even better, could you actually post a picture of a completed print that came off of this thing? There’s already some wonkiness in your videos where the extruder doesn’t seem to sync up with the rest of the machine. It just stops, goes, stops, goes, stops, goes.
It’s going to result in some fantastically ugly prints.
If you want a solid example of what these guys are talking about with the step interruption from operation head over to the machinekit googlegroup and talk to the devs over there working with LinuxCNC. Its being built on the beagle Bone black (about twice as fast as the pi with more RAM and a dedicated PRU to handle the hardware stepping) but we are still running into head room issues running nonstandard kinematics (delta, coreXY-hbot). I haven’t tried to slice on mine yet but I’m not going to either.
Its a very cool project but things to consider, from the people who live it
I think a better approach would be with something like smoothieware’s network/web interface combined with slic3r’s ‘upload to octoprint’ option. Do all the slicing/layout on the desktop/tablet/laptop/whatever where you have the processing power/interface and unload the printer’s firmware to let it handle the mechanical driving details/pausing/etc.
(see’is it turned on?’ ‘is it plugged in?’)