#5DPrint - The how, why and where we're at in code

2022-03-28 10:55 by Elliott Polk (comments: 11)

Lets Go 5D

Now that all the cameras are turned off and we're settling down from a nice week of crazy busy time, lets (finally) get down to the bits and bytes of things.

Let me set the scene a bit for you. A few (Makible) nerds... errrr, engineers sitting around the office trying to figure out the next step in doing the host software. We want to do this right. We don't like the current tools out there and we don't want to be just another app for 3D printing.

From the get go, the idea has been to make everything "connected". Not to fall into the trap of buzz words, but we're essentially making the "internet of things" but for makers. We want the non-traditional computers (such as tablets and smartphones) to be enabled to communicate with our creative devices. We want low powered systems similar to the Raspberry Pi to be able to command multiple machines without batting the proverbial eye. We want awesome gear for us but also to share it with the world. How do we do this?

We need a lightweight application server. A flexible user interface (UI). A simplified user experience (UX). My personal philosophy with this particular undertaking has been to gear this to what I'm calling "the iPad Generation" of users. People are now use to beautiful, simple UI / UX 's that make doing things simple and enjoyable. Why can't we do this with making, starting with 3D printing?

The following conversation excerpt is the entry point for this particular leg of our little adventure.

Jon: So let's think this through. What cross platform languages are there or have minimum effort to get to run cross platform?

Elliott: K. There's Python, Java, NodeJS, etc, etc... Hmmm. I don't want to use NodeJS just because it's the "new hotness", though I do like it. Java... hahaha. Python just seems to be the most reasonable, though we still have to pack the interpreter binary with each build.

Jon: OK. Are there any native one's that wouldn't require an interpreter?

Elliott: [jokingly] There's always Go. {chuckle}

Jon: Well now. Don't completely discount it. Is there any reason we shouldn't.

Elliott: Dunno. I've only been reading bits and pieces about it. Hmmm. Let me look into it a bit more.

Following this conversation, I had a 45 minute commute home and a couple of hours of heavy reading that night. Go was seriously starting to look like the viable option. Native binaries that can easily be crossed compiled on the same machine. Standard networking libraries. Wrappers for libusb (which is something we'll be revisiting in the near future). Go routines. Concurrency. Channels. All the features of a modern and flexible language with the strength of an old C language.

Go is currently frozen in version 1.1 so no major surprise changes any time soon. It's a language created and used by Google. As well, it's open sourced under the BSD license. Ok. What now. Lets see if I can get a small and simple web server that can run on all the major OS's.

package main

import (

func handler(w http.ResponseWriter, r *http.Request) {
    fmt.Fprintf(w, "Hi there, I love %s!", r.URL.Path[1:])

func main() {
    http.HandleFunc("/", handler)
    http.ListenAndServe(":8080", nil)

I was able to get a small web server written and running in less than 15 minutes all the while really understanding it's ins and outs. It'd never been so easy to pick up a C-like language and build a simplistic application server. Yes, it's essentially a "hello world" app but isn't it sexy?!

Ok... So that pretty much brings us to the "where we are" and "what now" parts.

We're currently into a rough beta of the code. We have a lightweight server that acts as a switchboard between the "devices" and the UI. The UI is written in web technologies (HTML / CSS / Javascript) and currently only being tested in Chrome and Firefox. We are getting steady prints and good feedback.




Our next steps are fairly straight forward. I'm currently working to get the Pause and Stop actions working properly. I have the concurrency working a little too well so the print is happening faster in the code than I can stop it. This will require a bit of modding to the "runExtendedJob" function so that we're not communicating over channels to run the job.

Following this, I will create an interactive panel that will provide more feedback from the app server as well as provide manual input to the attached devices. In the short term, I've exposed some functions to the Javascript console in order to accomplish this. But, we don't want everyone to have to learn Javascript just to see "raw" data.

Once the previous two pieces to the puzzle are all wrapped up, we'll move on to an API of sorts to expose control and data to any other external device that's not necessarily the attached computer / system. This will allow for control and monitoring by of jobs via things like an iOS, Android or Windows Phone device. Ideally this won't be limited. I would love to see what people can come up with.

The last little bits will be for better fail recovery. If the app server crashes or the device crashes at any point, we should be able to catch this and continue on our merry way. The current version will allow for a dirty hack around this, but we want to do it right. This may be shuffled higher up the priority chain.

Speaking of hacks. You'll notice that I continue to say "devices" instead of the MakiBox A6 and / or printer. This is for a reason. Our goal is not to limit this to our hardware. Eventually we'd love to see other devices / printers connecting to our host software. We're confident that our experience will make more since in the long term for everyone. But... since we're trying to get this out with our beta units, there are some MakiBox A6 specific hacks for the very short term. These will be stripped out and made much more general VERY soon.

Now, we want you to join in on the conversation. Jump into our forums and provide your thoughts and ideas. Tell us what you think and why. Have a look at the code. Ask questions.

5DPrint Forum

Here's to another awesome week of code and printing. We look forward to seeing what you can do with our code and hardware.

5DPrint Github

Go back

Add a comment

Comment by Thierry Giorgetti | 2022-03-30


Do not waste more time!
sell your machine! as it prints now!
the best is the enemy of the good things.



Comment by Kendall Miller | 2022-03-30

Great review... Mostly over my head, but I can see you have your thinking cap on...

Nothing is every finished, but if you release things before your satisfied that you have covered all the minimums, we will all suffer. Some people just want things "NOW", but they will be the first to complain and want it fixed for free!

I really like Jon's philosophy of, "telling it like it is", and "let the chip lay where they fall"...

Comment by Wassi | 2022-03-30

Yeah, Go for it;-)
I always wanted to see some productive code in Go!

Comment by Dan Neely | 2022-03-30

If you haven't done so already; I'd advise seeing if GO's actual Windows support matches its theoretical one. A friend of mine got burned with it a few years ago; reporting that there was zero interest in non-unix platforms by the people developing the language or the general community and that the windows version was full of bugs that no one was working on as a result.

Comment by MakiBox Member | 2022-03-30

Excellent update, Everything is right on track as predicted http://goo.gl/xaVQ0

Comment by valentin svahn | 2022-03-30


I'm thinking about an idea... If you develop your own printing software and it works in chrome, is it possible (in the future) you can print directly from web without download anything ?

For exemple, i'm on thingiverse and there is a "3D Print now" button where i click to print directly like on 2D paper printer today...

Do you have this idea in mind too ?

Comment by Elliott Polk | 2022-03-30

Hey valentin svahn... let me answer your question with just a simple and subtle smile.


Comment by AndR | 2022-03-31

Доброго Дня.
Я рад что разрабатывается программное обеспечение. Без программ аппаратные средства не могут работать. Программы очень важны, но...
программы без аппаратных средств это просто информация. как это применить если нет оборудования?
Если возможно, я бы хотел узнавать, сколько комплектов 3Д принтера отправлено.
Я буду смотреть на счетчик отправленого. и думать что я становлюсь ближе к цели. видеть что очередь движется. ожидание в неизвестности, это трудно.
спасибо, надеюсь что вы меня поняли.
===google перевод====== google translation ===
Good Day.
I am pleased that the software is developed. Programs without the hardware may not work. Programs are very important, but ...
software without the hardware is just information. how to apply if there is no equipment?
If possible, I would like to know how many sets of 3D printer sent.
I'll look at the departure counter. and to think that I am getting closer to the goal. see that the queue moves. waiting in the dark, it's hard.
Thank you, I hope that you understand me.

Comment by Rene K. Mueller | 2022-03-31

Hi Elliot,

I just have started to gain experience with browser and server shared JavaScript, in particular when dealing algorithms it works good, you literally write once code, and let it run on the browser or server (via nodejs), see https://github.com/Spiritdude/OpenJSCAD.org/wiki/User-Guide#web-browser--command-line-interface-aka-dual-use

Yet, the devil lies in the details: nodejs has fork() whereas parallel (long running) tasks in the browser work via WebWorkers, and rather cumbersome - and yes, the interaction with the local filesystem, how to get data into the program is challenging when it runs in the browser (e.g. how to deal with multiple files which depend on each other).

I will look at your GO server side implementation!

Comment by TIMOTHY BOSS | 2022-04-01

How awesome. So I am not too familiar with computer programming but to be able to control my machine from my I-pad would be unstoppable in the machining world. Currently there are great apps to show off cad designs but if I could upload a design to say my google account and then remotely send it to my 3d printer and watch it print from my iPad....... Yup I'm sold. I guarantee everyone and every company would offer similar software. It would reshape the way lazy machinists like myself do business. When I say lazy I mean make technology do all the work just as a standalone open source program that could control my printer. I'm thinking of it like this. Imagine your in a meeting and you bust out an iPad and makibox. Here is the kicker the makibox is chilling in the corner and your taking notes with your iPad and someone says I need a 3d model of this and bam you Interface your printer via Bluetooth or some Internet connection and it prints. Paper printers do it now so why can't a 3d printer? I say take the time to figure it out because your ideas are great and the technology exists. Lexmark printers have the wireless technology and the printer cost 70 dollars which can be controlled from an app. It sounds like a bit of programming and then off to the races.