Jump to content
Ultimaker Community of 3D Printing Experts
Sign in to follow this  
jhinkle

Is there a need for a 100mhz 32bit ARM Controller

Recommended Posts

I just purchased my UM1 in kit form - just shipped today to the States.

I noticed that the controller is 8/16bit Arduino based.

Is there a need/want for a 32bit controller?

I don't mean a RasPI or BeagleBone - but real embedded controller.

Would added speed and resolution improve this machine or is there still a lot of performance headway in the Arduino?

I already have a base design that I use in other projects - it has built in Ethernet and a TCP/IP stack. If there is a real need, I can look into a daughter board to provide the motor and display interface.

Any and all comments are welcome.

Thanks.

Joe

 

Share this post


Link to post
Share on other sites

I think this sounds interesting, though it's probably rather overkill than necessity (the UM1 runs pretty well, even at high speeds...)

Do you have an estimate in BOM cost? How complex is your main PCB? 4 layers, 6 layers?

The one huge advantage of an Arduino mainboard is, that it costs some ridiculous 35$ (or something). I've been playing with the thought of making a custom electronics for myself, expecially regarding shortcomins on power supply design, ESD protection, dedicated watchdog IC and expandability.

Imho it makes sense only if the new electronics are a complete replacement for the UM original electronics including the Ulticontroller. These cost 275 Euros combined, which is a price range that could be matched IF you don't charge anything for the development costs AND you produce them in small series quantity (like 100 or 200 pcs).

But the most important thing would be that it should be completely open source, just like the original. I'd love to see such a project come to life and would like to participate, and I'd definetly buy some.

I must admit though that I'm not very experienced on the firmware side of things - I don't think it's trivial to recreate Marlin for a 32bit ARM CPU. It's probably written in C (is it?) so there should be some level of portability, but that's just not (yet) my strong side...

I know that the Marlin firmware is constantly being improved and debugged, which means that "you" (meaning the guy who makes the firmware in the end) will also have to track that progress and, if necessary, adapt the ARM firmware as well.

This could become a very time consuming process - time I would probably not have.

/edit:

I'm planning on buying a second UM1 kit for my prototyping lab soon, throwing in "a few" upgrades. Improved electronics are definetly on my wishlist...

 

Share this post


Link to post
Share on other sites

There are a few options already out there for ARM based RepRap controllers. Designing the board is only part of the work. Testing, firmware, feature-completeness. That's where the difficulty lays.

I currently have an ARM prototype laying on my desk at Ultimaker. Developed by Erik vd Zalm. Pretty cool board, lots of cool features. But the firmware is a bit far from finished, and we are looking on how to go forward with this. That's all I can share right now.

 

Share this post


Link to post
Share on other sites

My current direction, for beta, is to have the board connector level equivalent with the Arduino so I can interface with the existing controller board.

It will provide a much faster cpu (120 mhz), 32bit hardware floating point, USB, ethernet, SD card.

I'm developing the firmware now so the system control and user interface will be all brand new -- nothing like the current UM1 implementation.

I've got the X/Y stepper subsystem pretty much done - now working on integrating the extruder control.

Once done -- I'll test print quality by simple driving the UM with the Arduino or my board and make comparisons.

Joe

 

Share this post


Link to post
Share on other sites

My current direction, for beta, is to have the board connector level equivalent with the Arduino so I can interface with the existing controller board.

It will provide a much faster cpu (120 mhz), 32bit hardware floating point, USB, ethernet, SD card.

I'm developing the firmware now so the system control and user interface will be all brand new -- nothing like the current UM1 implementation.

I've got the X/Y stepper subsystem pretty much done - now working on integrating the extruder control.

Once done -- I'll test print quality by simple driving the UM with the Arduino or my board and make comparisons.

Joe

 

We have 168Mhz, Ethernet, USB (host and device), MicroSD, TouchScreen LCD, Audio (because we can), TMC260 stepper drivers (which are awesome, as they allow for 256 microstepping)

All the drivers for the hardware are working, a quick port of Marlin motion planner is working on it. We can read files from the USB with USB drives. We're setting up the firmware so it will be portable across different 32bit platforms. And we're totally re-designing and making the planner modular. We actually had a design session yesterday evening.

Maybe we can work together instead of side-by-side? We have 3 people working on it right now (me from UM, 2 hobbists)

 

Share this post


Link to post
Share on other sites

Should the network processor and the stepper processor be separated? I'd hate for my print to go slow because I was pressing 'refresh' on the web interface :wink:

 

Separating the processors increases the BoM, and means you have to think about how to get gcode from one processor to the other - 250K baud serial isn't enough, unless maybe you binary encode your gcode (eg. http://wiki.ultimaker.com/Ultimate_Binary_Protocol).%20However,%20it%20means%20you%20can%20keep%20most%20of%20your%20existing%20firmware%20and%20have%20the%20ARM%20doing%20all%20the%20networking%20and%20display%20updates.

 

If there's one thing you can be certain of - putting an ethernet interface on anything means you'll need to do lots of security work on the code that works with it (think: IPv6, SSL, etc). I for one would prefer something that has plenty of spare cycles to do that rather than an embedded controller-gone-wild.

 

Just a thought :wink:

Share this post


Link to post
Share on other sites

This is indeed music to my ears Daid! Sounds really promising :)

Ethernet is an extremely computation-heavy protocol. But you can just use an Ethernet-controller IC that interfaces to the MCU, sorting out all the overhead and security stuff and just providing a clean UART datastream to the MCU. Or so, that was the plan :)

We're planning just that with a Cortex M3 MCU, but the priority on that dropped so atm I'm doing something else..

 

Share this post


Link to post
Share on other sites

Should the network processor and the stepper processor be separated? I'd hate for my print to go slow because I was pressing 'refresh' on the web interface :wink:

 

Separating the processors increases the BoM, and means you have to think about how to get gcode from one processor to the other - 250K baud serial isn't enough, unless maybe you binary encode your gcode (eg. http://wiki.ultimaker.com/Ultimate_Binary_Protocol). However, it means you can keep most of your existing firmware and have the ARM doing all the networking and display updates.

 

If there's one thing you can be certain of - putting an ethernet interface on anything means you'll need to do lots of security work on the code that works with it (think: IPv6, SSL, etc). I for one would prefer something that has plenty of spare cycles to do that rather than an embedded controller-gone-wild.

 

Just a thought :wink:

 

The processing (not stopping printing because of network load) is what a realtime-OS is for. Security is something I'm quite used to programming by now.

I did a study in embedded realtime systems. I worked for 5 years on the networking and safety parts of high end traffic lights.

With proper design and coding this can be done.

 

Share this post


Link to post
Share on other sites

What kind of chips/dev boards are you guys using?

I have a couple http://www.ti.com/tool/ek-tm4c123gxl and was wondering if they would be capable of running Ultimaker 2.

In terms of processing and memory I think it's much faster, but I think at the cost of some peripherals. They may not be built in, but could they be added externally? I know for sure it has less GPIOs but atm I don't know if Ultimaker is utilizing all 54 of the Mega's or if you really need to sample some of those I/Os all the time (maybe mux some sensors together?).

 

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
Sign in to follow this  

×

Important Information

Welcome to the Ultimaker Community of 3D printing experts. Visit the following links to read more about our Terms of Use or our Privacy Policy. Thank you!