Jump to content
Ultimaker Community of 3D Printing Experts
Daid

Upgrade idea: Exit the Arduino, insert BeagleBone?

Recommended Posts

The current motor controller is the Arduino Mega 2650, priced at 48,50 euro. Which works, but has it's challenges. Buffering being one of the issues, CPU power is another.

For 69,00 euro you can soon buy a BeagleBone. For only 20.50 euro more you get:

 

  • [*:7gxtue7r]An ethernet interface VS USB interface
    [*:7gxtue7r]32bit 720 MHz ARM Cortex-A8 VS 8bit 16MHz AVR.
    [*:7gxtue7r]256MB ram VS 8KB ram
    [*:7gxtue7r]2GB disk space VS 248 KB flash for code
    [*:7gxtue7r]Linux VS bare metal

 

So compared to the Arduino, you get limitless power and storage!

So, marketing speech done.

There are disadvantages. To name a few:

 

  • [*:7gxtue7r]Ethernet is awesome, but not as plug&play as USB. But the BeagleBone might have "USB On The Go" which could solve this.
    [*:7gxtue7r]The arduino firmware has to move to a Linux driver. Which is not as accessible as the Arduino software. Driver development might sound as scary magic to some people, but I do so in my day job from time to time, so no problem for me personally. Linux can be big and scary, but with a few tricks you get the realtime timing you need.
    [*:7gxtue7r]The IO pins are 3.3V instead of 5V, this causes problems with the current electronics. The Pololu drivers require VCC * 0.7 volt for a 'high', which is 3.4V at 5V, but the 5V might be drawn from the Arduino. All parts of the electronics need to be checked, as the temperature sensor also uses 5V, but I wouldn't be surprised if it al ran at 3.3V.

 

So, why go trough all this trouble?

Well, with the BeagleBone we can get even more fine grade control over the motors. How about a curve for acceleration, instead of the linear acceleration used right now?

"Instant realtime control", no more waiting for the buffer to be empty after changing the flow/feed rates.

Buffering problems will be a thing of the past. With 256MB ram, even the largest GCode file will fit in memory. PC crashing during print? No problem. Want to use/shutdown the PC during a print? No problem.

Much better diagnostics. If something goes wrong in the firmware, you're plain out of luck trying to figure out what went wrong. With linux and a proper driver, you can just telnet to your Ultimaker, read out some values, and be happy.

I'm planning to get one of these BeagleBones soon, my first step will be to put it in between the PC and the Arduino. To solve the PC crashing problem, because that's currently a huge issue for me.

Share this post


Link to post
Share on other sites

This sounds amazing - but it sounds like it'll end up being a complete electronics replacement for the Ultimaker (although you'll be able to reuse elements of the design). Uploading your design to the printer and letting it print is much more the way packaged printers work, and would (IMHO) be a significant selling point for the Ultimaker if it could do it. If you do end up redesigning boards and the like, how about adding in some sort of "expansion port" that hackers could attach devices to (stuff like LCD displays, control buttons or whatever) - it sounds like you'd have enough power available to be able to handle the gcode and some out of band communications like that sort of thing.

Either way, this sounds like a great idea - although could take some time to do, I guess. Good luck!

Share this post


Link to post
Share on other sites

I might be able to design an "upgrade shield" something you plug into the board instead of the Arduino and then you can plug the Beaglebone into that. Which would be cheaper then a full board replacement.

Electrical wise I can make it work. How much components will be needed depends on the temperature sensor, and if it will work on 3.3V.

Share this post


Link to post
Share on other sites
I might be able to design an "upgrade shield" something you plug into the board instead of the Arduino and then you can plug the Beaglebone into that. Which would be cheaper then a full board replacement.

Electrical wise I can make it work. How much components will be needed depends on the temperature sensor, and if it will work on 3.3V.

I couldn't find an answer on the beagle board site, but the board runs Arduino sketches, or does the FW needs to be rewritten?

Share this post


Link to post
Share on other sites
The firmware will need a complete rewrite. The board runs linux, so it will need to be done in a linux driver. Which might scare some people, but isn't really that different from being in a micro-controller environment really. It's something that doesn't scare me at all :mrgreen:

While the beagle board certainly has very attractive specs, the prospect of having to rewrite the firmware to a new platform is a gigantic no-go in my opinion:

  • - the UM firmware is derived from other machines (reprap) and does not exist in a vacuum. moving to a completely different platform will put it into said vacuum, and making cross-polination from other related projects impossible.
    - the UM has many contributors and a shared code base. moving to a new platform will force all contributors to learn that new platform, rewrite and break all existing code, and potentially alienating core members (I would hate to loose Bernhard's contributions to the UM firmware)
    - a new HW platform would require a complete redesign of the electronics, breaking support for all older machines
    - the beagle board runs some form of linux, which piles huge amounts of complex layers of classes and code onto the code, using libraries that come from somewhere, and that may or may not be well documented. the code base for the UM is comparably simple and easy to understand, and can be compiled/uploaded from almost any computer (linux, win and mac), while the beagle board may require installing linux just to code for linux or upload code to the board (this would be a gigantic hurdle). while arduino is a very simplistic thing, this simplicity is very approachable, and has contributed to the huge success of the platform. "linux" on the other hand is still something far more complex, and certainly not easy to understand, nor approachable.

changing to a new platform like beagle is fine for large cooperations that have enough resources to code software for the new product, making it more a closed hardware (similar to any other inkjet printer, which are more or less unhackable), rather then the open source spirit of reprap/UM.

I'd rather like to see the UM arduino core upgraded to a code-base compatible board with better communication than something completely different.

Share this post


Link to post
Share on other sites

I understand your fears.

However the RepRap firmware and the Ultimaker firmware are vastly different. The RepRap firmware doesn't talk GCode, but some other protocol, which RepG talks. I've actually seen a complain from someone using a RepRap that the Ultimaker firmware was so different and no help for RepRap.

I cannot, and will not, force anyone to switch platforms. I'm not here to shatter development, it shattered already really. Which is fine, more options.

"A complete redesign of electronics", well, the board just has a feel Pololu drivers and a few power fets connected to an arduino. It's not that fancy, and those parts can stay.

- the beagle board runs some form of linux, which piles huge amounts of complex layers of classes and code onto the code, using libraries that come from somewhere, and that may or may not be well documented. the code base for the UM is comparably simple and easy to understand, and can be compiled/uploaded from almost any computer (linux, win and mac), while the beagle board may require installing linux just to code for linux or upload code to the board (this would be a gigantic hurdle). while arduino is a very simplistic thing, this simplicity is very approachable, and has contributed to the huge success of the platform. "linux" on the other hand is still something far more complex, and certainly not easy to understand, nor approachable.
Nope it won't. Maybe I should put it like this: I do this for my day job, we (20+ people) program for ARM linux boards every day, under windows, without issues. (We use a lot of C) I'm actually the maintainer of the build environment and linux drivers. So I might know what I'm doing.

And saying that "linux is complex!" you might as well say "windows is complex!" which is silly, there are more linux/windows programmers out there then there are microcontroller programmers out there.

You could, if you want, run Skeinforge on the ARM board. It won't be the fastest thing, but it's possible.

Most code that won't have realtime requirements (so everything that doesn't control the motors) and can be done in a high level language. Something like python, php, java. The only thing timing critical is controlling the motors. Which is something for a driver, but not insanely difficult. Right now one of the main problems in the firmware is the speed of the data channel, the difficulty to debug problems, and the speed of the code.

I really only have to say one thing. Trust me. Which is hard, I know.

  • Like 1

Share this post


Link to post
Share on other sites
However the RepRap firmware and the Ultimaker firmware are vastly different. The RepRap firmware doesn't talk GCode, but some other protocol, which RepG talks. I've actually seen a complain from someone using a RepRap that the Ultimaker firmware was so different and no help for RepRap.

I may have missed some of the intricacies of the firmware development, actually I do not know how the different firmwares are intererlated. I assumed that they are derivative works.

- the beagle board runs some form of linux, which piles huge amounts of complex layers of classes and code onto the code, using libraries that come from somewhere, and that may or may not be well documented. the code base for the UM is comparably simple and easy to understand, and can be compiled/uploaded from almost any computer (linux, win and mac), while the beagle board may require installing linux just to code for linux or upload code to the board (this would be a gigantic hurdle). while arduino is a very simplistic thing, this simplicity is very approachable, and has contributed to the huge success of the platform. "linux" on the other hand is still something far more complex, and certainly not easy to understand, nor approachable.
Nope it won't. Maybe I should put it like this: I do this for my day job, we (20+ people) program for ARM linux boards every day, under windows, without issues. (We use a lot of C) I'm actually the maintainer of the build environment and linux drivers. So I might know what I'm doing.

And saying that "linux is complex!" you might as well say "windows is complex!" which is silly, there are more linux/windows programmers out there then there are microcontroller programmers out there.

I am sorry, but the following may sound harsh, but not every one has a CS degree, nor do I run a software company with 20 people. I am a photographer and artist, who is capable of using software, not making it. there are people like me who can't write a C++ program, neither under windows, linux or mac. I can't even get a makefile to compile, under whatever environment. so, yes, making/compiling linux and windows and mac applications is f'ing complex, far from as easy as you make it sound, and none of that is silly. saying that everyone can do it is so far removed from reality.

On the other hand, taking a little bit of interest in the subject, I can get an arduino sketch to blink a LED to work in relatively little time... this is the level of approachability I am talking about. because despite the fact that I wouldn't be able to code marlin, I am able to read and understand the code that goes into marlin, and make changes if necessary. that would be a no-go for me with the linux environment you are suggesting.

You could, if you want, run Skeinforge on the ARM board. It won't be the fastest thing, but it's possible.

yes, that would be a possibility, indeed, only it would take even longer than the glacial speed it currently has. and it would have the even "better" advantage to even less understand/see what's going on. as I said, this might be interesting when Epson makes a 3D printer that takes STL as input.

Most code that won't have realtime requirements (so everything that doesn't control the motors) and can be done in a high level language. Something like python, php, java. The only thing timing critical is controlling the motors. Which is something for a driver, but not insanely difficult. Right now one of the main problems in the firmware is the speed of the data channel, the difficulty to debug problems, and the speed of the code.

As I said before, this is just piling on complexities that would be removing the transparency we currently have, and more and more become an island solution, coded by one person, who when abandoning the project, would leave the project in ruins (slight exaggeration here).

end_of_rant

I really only have to say one thing. Trust me. Which is hard, I know.

sorry, I don't follow/understand...

Share this post


Link to post
Share on other sites
I understand your fears.

It has not much to do with fears, as I do not have much of them. It had more to do with what is practical. and what abilities the average enduser has.

yes, the beagle board would be a great replacement for the UM, if there would be a shred of compatibility/similarities between them and having a 10in DVI touch screen mounted to the UM to control it would be awesome. but there seem to be non. plus the beagle board doesn't come with an instant CS degree in the box :-)

Another (technically inferior in this context) alternative that would be closer to become reality would be the Arduino Due:

https://groups.google.com/forum/#!searc ... CXlhWatLIJ

but even that isn't a simple rip&replace.

Share this post


Link to post
Share on other sites

I have looked a bit about the "should we go to ARM" stuff on the net. Which in principle I am very keen on (in theory),

have always been a massive fan of ARM CPUs apart from anything else.

However before I had an ARM Ultimaker I would much rather have first:

1) Upgraded CURA with new slice engine in background

2) Really good dual extruder support

So there you go, or to put it another way, #1 and #2 there have actually stopped me from being able to

do what I need to...and the ARM board would not fix either #1 or #2.

However I am sure its something (or similar) that will need to happen in the next couple of years, as

the complexity of the control logic increases.

 

Share this post


Link to post
Share on other sites

I agree with the above, although Arm would be great there are other more pressing priorities... The current Arduino Mega solution with the Ultracontroller works quite well.

I originally bought the BeagleBone to drive a resin DLP printer that I was working on. Still haven't gotten far on that project as I drift around between things that I'm working... but I had started to develop my firmware on the BeagleBone in c++ using WT (http://www.webtoolkit.eu/wt) to provide all of the interface as a website over Ethernet. The idea was to allow you to set the machine parameters and upload your sliced file to the machine (in that either case a multi-layer SVG of each layer or a series of BMP images for each layer). It could then be started, stopped, and monitored from a web browser anywhere in the house on my phone or tablet. I intended to also include a slicer right in on the unit to allow you to upload an STL and have it sliced right there. Slicing for a DLP resin printer is much, much simpler than for an FDM machine.

Cheers,

Troy.

 

Share this post


Link to post
Share on other sites

Would moving to a TI Stellaris or STM32 (ARM Cortex M4 based boards) or Renesas RX (not quite BeagleBone power but considerably more powerful than the AVR) make sense? I have not looked at the firmware yet but I wonder if coding the firmware in C/C++ and using an RTOS would help in terms of real-time control priorities, for example, managing the temperature controller and four axes of stepper control without other items (such as LCD display or control input) affecting real time operation?

I think embedded Linux may be overkill, but certainly an RTOS like Micrium MicroCOS III would be useful, though there are some modest fees. As for embedded Linux on a platform such as a Raspberry Pi or Beaglebone, it makes sense to use real time extensions such as Xenomai.

The one place where I see Arduino shining is the bootloader capability, but it's possible to build a USB or serial bootloader.

I think the most important questions are:

(1) does the Marlin firmware allow for tight control of the nozzle temperature even under worst-case load?

(2) does the firmware allow for the appropriate control of the motor axes even when a user is controlling the interface to prevent any kind of plastic overflow or starvation?

If the answer is yes, then the Marlin firmware meets the general requirements. I've seen a couple of bugs where I have to power down the unit to reset it after I tell the unit to stop printing-- it still says "printing."

Josh Karch

 

Share this post


Link to post
Share on other sites

I think Marlin is good enough for now, but it may be challenging to add new features and sensors, such as like closed loop control, non-linear accelerations, filament flow rate sensing, and capacitive z-height sensing.

I was looking at the TI Stellaris and other low-cost ARM processors as a platform for some CNC/motion control projects of my own. I'm intrigued by QP is one framework that seems to run on everything from Arduinos and ARMs to Linux and even Android and is free under GPL. It seems like a very elegant architecture to implement complicated real-time embedded applications.

Anyone else looked at this or anything similar?

 

Share this post


Link to post
Share on other sites

If we were to adapt to another platform I would think the newest arduino announced at MakerFaire would hold some significant promise... Integrated wireless programming could make the printer even less tethered. FTP over the network a file to an onboard SD and print? That could be used in conjunction with a small appetite slicer (Vapor Engine Daid?) to make it to where someone can go from Catch123D to the printer all from an iOS/Android with no computer what so ever...

 

Share this post


Link to post
Share on other sites

Stumbled upon this thread while googling.. i dont have an Ultimaker, but i thought that some of you might want to know that a cape(module), is in the work for the Beaglebone. The Replicape, http://replicape.com/,%20http://wiki.replicape.com

Not sure if it would be a perfect replacement for the ultimaker, but the specs are interesting.

 

  • Like 1

Share this post


Link to post
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now

×

Important Information

Terms of Use Privacy Policy