new dimension of reprap electronic?

Hi all,

I thinking about new electronic for reprap.
My idea is have touchscreen lcd with 1GHz processor runs linux or androud. Simple it can be "black box" all you must to do
is plug yours motor connectors, temperature sensors atc at the bottom of board.
Start system, setup slic3r and print directly. All at one machine.
Hardware will be simple and you can easy write yours own applications for special devs like measuring filament atc...

Is it this interresting for reprap community?

Thanks for yours comment

Will it be cheaper than a cheap netbook?

...R

Will it be able to do all the stuff sprinter / marlin firmware does
and
be able to handle all the different print configurations?

First of all you need excellent realtime capabilities. Standard Linux doesn't provide this and even Realtime-Linux has its limtations. Consumer OSs can barely time videos at 30 pictures/second, a RepRap controller needs to handle more like 50.000 precisely timed events per second.

Current RepRap controllers are fine. If you want to enhance them for the user, join them with a secondary computer doing UI, networking and such stuff.

---

Generation 7 Electronics	Teacup Firmware	RepRap DIY

The best way to do what you're describing would be to use a Linux-capable board (most of them with Android support) like a BeagleBoard, Gumstix, etc. for the UI and use a USB connection to the Arduino controlling the actual device. As Traumflug points out, you need a dedicated processor to handle all the events, and what you're describing is basically a generalized computer. The Arduino-based designs like RAMPS are well suited to doing real-time control and it's a fairly common approach to pair a Linux-supported board for larger software stacks (web server, port-based network interface, capacitive touchscreen, LCD panel) with a dedicated processor (DSP, FPGA, Arduino) for hardware interfacing especially when real-time response is needed. Just about every ARM-based embedded Linux implementation out there can support the USB interface needed to communicate with the Arduino-based controller.

Yes, this is going to add USD $100-200 especially if you use a decent sized capacitive touchscreen but you can get the parts off the shelf. BeagleBoard seems like it's probably a good starting point (ARM based, can drive HDMI / DVI or LCD) and fairly well-supported. The key is to start with a board that is already available off-the-shelf and already has Linux driver support for the things you want to do (there are a lot of choices that meet those criteria).

The rest is just Linux software development (tongue in cheek). Pretty much all of the above applies to Android as well, at least for BeagleBoard and Gumstix. The software part is fairly complex. In particular there are a LOT of configurable values that need to be exposed.

Once you tally up all the stuff needed for a proper UI, it's getting in the cheap laptop price range. If the goal is to add network server, camera interface, web interface etc. without the UI you can probably use the same design (i.e. Beagleboard) without the UI components.

Compare this to mass-market 2D printers that have a little touchscreen on them. Many of them are using simpler specialized hardware for the UI that runs Java or some hardwired code to drive the UI, simply because it's cheaper from the mass production standpoint to spend more on embedded software development than to go for a broader platform like Linux. Besides, the big vendors don't really like to run open source on their core hardware... The comparison to 2D printers is limited because there a lot of low-level settings for 3D printing that are difficult to infer from the input...

there is the possibility of using a android tablet to do the external gui. there are issues all around, even if performing the graphics internally to the arduino controller. pauses in display updates are quite annoying to the user, and responsiveness of gui, especially with touch needs to be accurate and work flawlessly. On top of this a communication language to handle the objects placement and response to gui need to be agreed upon and added in the firmware. the end user is quite sensitive to costs as well.

java running hardware on reprap? maybe if compiled to native code.

Firstly thanks for yours comments.

I think that beaglebone black combinated with touchscreen lcd and motor drivers, temperature sensors all one board is best solution.
Im embedded programmer so write linux drivers, interrupt based for controlling motor, for me is not to hard work. And features same
as have marlin firmware is easy too.

Todays electronic is wery simple and if you are using arduino you must have arduino, ramps, drivers and PC or sdcard and lcd panet.
To much board I think. At this platform you havent usb memory and ethernet.

This is reasons that I think that small embedded device all at one board is better and price is not to much.
If you buy this device you dont flash firmware like into arduino. All parameters simple set throught lcd.

I say this is my reason, becouse I know that most people havent idea about electronic and working with arduino and ramps is big problem.

Quote
Traumflug
First of all you need excellent realtime capabilities. Standard Linux doesn't provide this and even Realtime-Linux has its limtations. Consumer OSs can barely time videos at 30 pictures/second, a RepRap controller needs to handle more like 50.000 precisely timed events per second.

Current RepRap controllers are fine. If you want to enhance them for the user, join them with a secondary computer doing UI, networking and such stuff.

I think realtime linux could definitely be used to control a printer. LinuxCNC has been based on the RTAI kernel for many years and is capable of controlling machines with a large number of axes. However, realtime linux on embedded ARM processors is still fairly new and may have some additional challenges. For the beaglebone, I know that the Xenomai kernel is available and the maintainers of the code have been active in adding functionality for ARM. I've read that the latency is actually quite reasonable, around 20us. I've also read that people have had problems getting the RT-PREEMPT kernel patches to work correctly... which is unfortunate, because it's the simplest to implement.

With Xenomai, there is currently a route to a full-blown OS on an embedded device that could be used on a BBB for 3d printing. While I agree that current reprap controllers are fine, realtime embedded linux is better, offering loads of features at no additional expense.

For a low cost (and good community support) option,consider the Raspberry PI
700Mhz (or higher) ARM device with Composite Video or HDMI (no VGA). 512Mb Ram, USB & Ethernet, running Debian.

Good support for Python and lots of hacking...

I'd not recommend it for natively running a printer, that task is better suited to a Microcontroller.
But with SPI/UART interface from the PI, it can be a good front-end interface.
Add the Pi Camera (HD Camera) and you've got a remote camera on the system to view progress, it'll run apache (or lighter) Web server and FTP/Samba etc for file sharing.

I've seen a realtime Xenomai kernel for the pi, but it really lacks in IO. You might be able to multiplex the IO, but it's kind of limited. I also haven't seen any numbers on the kernel jitter to know if it's actually useable.

Quote
Traumflug
a RepRap controller needs to handle more like 50.000 precisely timed events per second.

I suspect a Linux PC with a 1.6GHz CPU could very easily manage 50,000 per second.

On my netbook interpreted JRuby will do 50,000 loops in about half a second.

...R

Quote
Forrest
you must have arduino, ramps, drivers and PC or sdcard and lcd panet.

"Must" is relative. There are many boards which work just fine without Arduino, without drivers, SD-card or LCD.

Quote
iquizzle
I've read that the latency is actually quite reasonable, around 20us.

If you allow 30% mis-timing of steps (which a lot), that's about 16'000 steps/second. Commodity ATmegas can achieve this easily, OS-less ARMs probably even better.

I mean, I have no doubt this can be done. I just think a dedicated controller is simpler and more reliable.

---

Generation 7 Electronics	Teacup Firmware	RepRap DIY

Quote
Traumflug

I mean, I have no doubt this can be done. I just think a dedicated controller is simpler and more reliable.

and cheaper.

...R

OS-less ARM? Like this one? Apologies for the self promotion, so two links provided:

(About halfway down the page) [www.reprappro.com]
[blog.think3dprint3d.com]

Ian
---
RepRapPro tech support

Yes, Raspberry Pi sounds like a good option, just not one of the ones I've worked with in embedded programming.

The latency for the UI is not an issue since you're making the dedicated processor (Arduino) do all the real-time work, and you basically just need a single process or thread on the ARM Linux CPU that interacts with the USB connection to the Arduino (which is basically a serial connection)

I only mentioned Java as a common UI vehicle for non-Linux graphics. I've used Java and Flash (used to maintain a flash lite engine) and Qt and vastly prefer Qt Embedded for graphics interaction on embedded Linux.

I think the big challenge is in the embedded software because the good news is there is a lot of Python code for slicing and controlling the Arduino, but the bad news is that 3D manipulations tend to be very memory-hungry. Somewhat counterintuitively the resident state set of memory (RSS) from running a Qt Embedded GUI will be relatively low (as long as you don't fire up an embedded web browser instance) but is likely to run high for the code slicing STL. Swapping may be required.

Another issue is the number of cases where I need to repair STL using Netfabb (which is free but not open source) so there would need to be the capability to process a queue and define behavior for things that need to be rejected.

Having even a simple GUI that could offer network sharing and queue management would be useful, with slicing preview of items in the queue, so you could just send STL files to a network device with options for slicing. Another alternative would be to have a web-based GUI served up by the embedded Linux processor for doing the same thing, and trade the additional dedicated LCD / touchscreen for some slower rendering of previews. The web-based GUI is also interesting in that it's also a multi-user GUI, and of course either approach can be printer-agnostic (or could control multiple printers).

It's an interesting idea.

Quote

OS-less ARM? Like this one?

Yes, like this, like 4pi, like SmoothieBoard, like Gen7-ARM, like Teensy3.

---

Generation 7 Electronics	Teacup Firmware	RepRap DIY

Quote
Robin2

Quote
Traumflug

I mean, I have no doubt this can be done. I just think a dedicated controller is simpler and more reliable.

and cheaper.

...R

Not always cheaper. I can buy a BBB for $10 less than the cost of the arduino mega that my RAMPS sits on. And for that, I get a system that doesn't require an additional computer to operate AND has ethernet capabilities -- which opens up a huge new world of connectivity. The code gains portability, as it can be run on any linux platform. It can be written in a high-level language like python that better encourages community involvement, and simplifies the code by abstracting the hardware level. Furthermore, it enables more complex calculations in runtime, which may not be important for cartesian bots, but would certainly be an improvement for delta robots.

A dedicated controller is simpler for simple operations. If you want to add a touch screen, not having driver availability instantly makes it more complicated. If the reprap community doesn't develop at a higher level, makerbot/stratasys certainly will, and we'll seem stale by comparison. It would be better to show people that we have this capability as well, before they steal the show and make us look like dinosaurs.

There are any number of people who would want to connect to their printers via wifi, using a browser that is served by apache running on the controller itself. There's no reason this isn't possible -- other than that development hasn't been done. There's no reason to discourage people who want to do this development.

Edited 1 time(s). Last edit at 12/02/2013 06:52PM by iquizzle.

@ iquizzle

I like your ideas
Any mods or product additions that can make the user experience less painful, or adds another way of doing something is a plus.

@iquizzle, I agree with all you say about higher level languages.

However as I see it everybody already owns "an additional computer to operate [with] ethernet capabilities ".

And the development of software for a Beagle Bone Black doesn't come for free - the developer could do something else with his/her time.

My concept is to simplify the code on an Arduino (Uno should be enough) and shift as much as possible of the programming and calculation to a PC which already has a screen, keyboard, lots of RAM, a hard disk etc etc.

In my world view I don't see a place for Raspberry PIs, Beagle BOnes etc unless one needs a Linux PC in a very small package for space reasons or because one is producing hundreds of machines with embedded PCs so that the cost saving is significant.

...R

Quote

There are any number of people who would want to connect to their printers via wifi

This will perfectly work when setting a tiny PC aside to the stepper controller.

---

Generation 7 Electronics	Teacup Firmware	RepRap DIY

(looks at last post by self... realizes there is already Octoprint available which does all that... d'oh!)

So I rather like the idea of the web-based GUI the more I think about it, and it turns out Octoprint runs on a Raspberry Pi, has webcam support, and is capable of controlling multiple printers.

Adding the ability to control / monitor via a tablet should also be possible (if someone hasn't already done that)...

Clearly there are two schools of thought regarding the division between feature rich application and real-time part. With sufficient effort you can make one platform do both, depends on where you like to solve problems. Personally I would go for a loosely coupled "big-little" approach, an off the shelf Linux board with a AVR or ARM based shield to handle real time. This gets the advantage of reusing cheap modules without a lot of bespoke effort which becomes obsolete in a year or two.

The key thing there is finding a good match of baseboard to shield.

I think the Beagle Bone Black is currently the best value for money in terms of small Linux platforms, has some good realtime capability with the PRUSS, and easy to add a shield to. You can already run Linux CNC with a RAMPS shield using Bart Dring's adapter board. I am planning on doing a version of RAMPS-FD for the BBB as well.

Another easy one is UDOO, although that is more expensive, but has an Arduino Due on board which can run real-time stuff. RAMPS-FD should work ok without modification, I've yet to try it.

---

What is Open Source?
What is Open Source Hardware?
Open Source in a nutshell: the Four Freedoms
CC BY-NC is not an Open Source license