Reprap Blog 2021

Where Should Open Source Go?


In earlier texts I've linked open source to warm fuzzy feelings, freedom, and happiness. Critique often comes in terms of survival or well being of the developer. The most typical question is whether open source work can put food on the table. I've been thinking about that.

With "open source" in this text, I mean the practice of sharing intellectual work publicly down to excruciating detail.

The level of sharing is of course a continuum, and "open source" has many definitions. In this text, let's associate "open source" with the most sharing end.

This text is written to a community who wants to endure life at the sharing end. Food on the table is just one of many challenges we face, but we're asked about this so often that it deserves an answer.

Open Source Devs Have The Same Question

Sharing requires surviving, which requires covering one's expenses. The typical dev wants to share, but must also pay the bills.

Perceiving a conflict between open source and paying the bills, the developer faces a stark choice. Either they must find an open source business model, or they must leave their open source work.

It can be frustrating to not have ideals line up with the need for income. Making the two line up and build on each other would feel better.

The economically pressured open source developer will search for projects that:

  1. Must be open source in order to make sense
  2. Help the creator survive

I find nr 1 hard to crack, but nr 2 really breaks my brain.

That's partly because survival was always hard. Look at the history of almost anything, and you'll find hardship and randomness.

But it's also because being open source is almost always a terrible business plan.

With risk of actually breaking my brain, I will chase this train of thought as far as I can in this text. Let's look at four strategies that might help the pressed open creator survive.

When working on open source projects, I'm often compared to a stamp collector. The perception is that I spend time on my little hobby, for myself, in my own room, and for my own sake. It's not the activity itself that is considered useless, it's the lack of generated income.

Strategy 1️⃣ Politics

This strategy is obvious but infrequent. Don't ask me why. Elsewhere in society, all kinds of groups seek political protection all the time. Industries, religious groups, age groups and even genders use politics to benefit themselves. So why wouldn't we?

Through politics we could organize society wide efforts to support open source. We could fund our best projects with tax money. Or we could force companies that misbehave on the closed market to open source their products.

I find politics exhausting, but I also find that we should get our act together and do it anyways. Refusing to stand up for our beliefs in public debate is a self defeating attitude. (Talking for those of us who live in functioning democracies.)

At the same time the open source community must be mindful about potential downsides of political projects.

For example, politics can breed prestige and a tendency to inflate public expectations with helium.

There was a time when techies pushed for zeppelins. Big disasters scared the public away from the idea. Public open source projects gone bad would make us look a bit like this.

Saving individuals could also drag the community down. Open source gets a bad rep if low quality projects don't die quickly enough.

In today's harsh conditions, any survivor project is exceptional. With politics in the mix however, we will risk that projects get life support just to save someone's face.

I think good technical leadership in publicly funded open source is possible, but let's not head too far into dreamery.

Let's stop it there. There's little appetite for politics within our community, and we're far away from political victories.

Strategy 2️⃣ Fence In

Let's look at some similar strategies that don't involve parliaments. These ones are much more common, so I'll explore them in more depth.

Let's generalize "fence" as anything that separates insiders from outsiders.

The basic idea: Somebody builds a fence around open source work. If those on the inside survive happily, then more will join. Once everyone is inside, we're all open and good.

However, if we get a few of these open islands, and not everyone gets onboard, then everyone is stuck in half-open source land, which would be bad.

Being open for everyone is exactly the point of open source. Those who would be shut out first are the ones we're the most eager to reach. Not reaching everyone is an openness failure.

So the downside of many fencing strategies is that they start with openness failure, and try to gradually reduce the amount of failure along the way. Having to lure people over to "the open side" leads to complications.

Here follows a list of common fencing suggestions. They are put in order of increasing distance from the naive free-for-all strategy that I wish in my dreams would work.

🤺Fence 1: Private Donations and Grants

It's simple and helps creators survive.

A little confession here. Seeing the idea of retroactive public goods funding, pushed by someone wealthy enough to fund it, intrigues me. Very creative philanthropy idea there.

However, the reality today is that grants and donations are few and small. Very few devs can rely on them for food on the table.

The few large grants programmes I know about have created distorted markets. Talented people drift towards satisfying checklist requirements, or second-guessing vague requirements, rather than doing useful work. We need something more.

🤺Fence 2: Licenses

Copyleft licenses force devs to copyleft their work if it builds upon copyleft code. It has been in use for 36 years, but few are currently joining.

The grass inside the fence needs to be made greener for us to survive there.

By James Rickwood - Flickr: P*ssed again!, CC BY 2.0,
Not enough green grass inside my fence. (Image by James Rickwood - Flickr: P*ssed again!, CC BY 2.0,

🤺Fence 3: Insurances and Law Firms

To improve the status inside the copyleft fence, we could hire lawyers.

A law firm could take on large companies in court. Insured open source creators could enjoy legal security and stability.

Uninsured creators could be protected by proactive law firms who actively search for license breakers, sue them, and split infringement compensations with rights holders.

There's one more legal path. Users are given freedoms by open source licenses. If they value these freedoms, they should be motivated to sue license breakers. The copyright holder doesn't need to be involved at all. I've seen one such example of user suing license breaker.

Alas, law is exhausting work, almost worse than politics. Most open source devs, like most users, aren't too keen on punishing anyone.

🤺Fence 4: Insider Mentoring and Treasury

Availability of learning resources and tools is what currently recruits every single programmer to be an open source developer initially. It's just impossible to learn how to program without also being exposed to open source history, methodology, and ideology.

A high rate of recruitment keeps open source in existence despite being a terrible business plan. When people leave open source, it's most often for "food-on-the-table" reasons.

Some contact with a more experienced open source developer would help many to stay in open source for longer. Opportunities could be highlighted, skills improved, and sense of community strengthened.

At this point in the list, pooling up some funds in a treasury would be preferable. Otherwise, the mentor would donate time. Relying on a few expert individuals who have the capacity to donate time is what we're trying to move away from.

It's sometimes golden to have some guidance.

🤺Fence 5: Insider Trade Agreement

Nice prices inside the fence could boost survival rates.

However, it only works if some closed source businesses still buy our stuff at non-discounted prices. We can't be too aggressive with pricing schemes, or it will backfire.

🤺Fence 6: Union of Open Source

Only let good open source creators in. Make them help each other survive. All other fencing techniques could be strengthened by an organization that we all pay for together. Deployed carefully, a union is a turbo for any kind of worker's conditions, including paychecks.

Making it float is a tad complicated. We're getting close to politics again.

🤺Fence 7: Pooling Patents

Inside something like a union, we could pool our patents and enforce them together.

With enough resources, we could create a service where outsiders could buy restricted access to our work. On our way to open source utopia, we could get rich! Survival with style, right?

These kinds of strategies are risky. Rent seekers could hi-jack the open source union. They would then own the treasury, all patents, copyrights, trade agreements, law firm contacts, and mentorship programmes.

Strong fencing strategies like unions and patent pools makes me think about the sun. A shining bright light with strong gravity. They could become so powerful that everyone would have to adapt, for better or worse.

I don't really think we should fence in that much. I think it's an arrogant idea.

Non-open companies are already specialized in surviving competition. Playing by their rules will drag us into their game. We can't beat them and have virtue at the same time. We're great, but I don't think we're that superior.

Rather, I think we're making an error of thought by pitting open source up against closed source. It's like pitting pets up against wild animals in the jungle. Or mammals up against dinosaurs.

Strategy 3️⃣ Survive In Self-Made Niches

We're looking for strategies to help our open source creators survive. To do better, let's stop treating open source like a broken business plan. It's not a business plan. It's more like a culture.

Being a culture gives us more options. We can untie ourselves from commercial culture and company culture. We can stay fluid and develop our own culture in the background.

Survival wise, be the little mammals in the age of big tech dinosaurs.

Early mammals taking a walk in the park. Not a real image. source

Open source can go where others can't.

We Can Skip Licensing

We can skip licenses on our open source work. We can ignore copyright and law enforcement altogether. That's one less burden.

We Can Skip Self Censoring

We can be vulgar, political, and personal if we like to. If others think we're wasting time, we don't have to care.

We can risk saying what we feel. We can do anonymous things and provocative things. Like jokes.

Survival doesn't have to be about getting more food on the table. Boredom kills.

We Can Create Art

We can do computer generated art, and art robots. It's perfect for us! If art ever scales, it looses value. Closed companies must scale, so they can't do art.

We can play with all forcibly low volume things. Not just low in demand. I mean we can make few copies by design.

We can talk to whoever we want and collaborate with whoever we want.

We Can Hide

Carving out and hiding within a niche where closed source can't follow will help an open source developer survive on the sharing end.

We Can Change Our Perspective

The new culture framework puts the question about food on the table in a different light. Food on the table is still hard, but the explanation to why it's hard, changes. The implied difficulties also change.

"Open source is bad business" changes into "you can't front-run the new culture development". That's the updated reason to why open source is so hard. No textbook model can predict what we will become.

The implied pragmatic answer changes from "open source is bad, so leave it" to something more like "keep re-inventing yourself until you can go where you want".

Strategy 4️⃣ Hibernate

Surviving is about taking opportunity when there is one, and saving energy if there's none. Maybe there are few open source opportunities around you right now.

One can always do something else for a while, or cut down on expenses. If we know who we are, we can pause our work with confidence, and recognize opportunities to resume when we see them.

This strategy makes sense if you, as the early open source mammal you are, think an asteroid event will clear some survival space for the real and cooler you in the future. The asteroid could be any one of these:

☄️A Mass Layoff

Automation and economic downturns will hit all professions. Many developers will turn to cool open source culture if it exists. We saw this after 2008 and during covid-19, and we'll see it again.

☄️A Digital Divide

Western and Chinese tech are increasingly being made incompatible for military strategic reasons. Closed source have to choose sides.

Open source can also be caught in the cross-fires, but we generally have more leeway to get around embargos. The growing gap between east and west could create big exclusive open-only zones.

☄️A More Open Web

The way browsers download javascript code in clear text has already made javascript the most vibrant open source community.

The next web is being built on blockchains. Regulations are currently forcing these blockchains to be open and distributed. If it continues, the next web will become a gigantic open-only zone.

☄️A Modernized Democracy

Algorithms make important decisions in our society today, and a few powerful people control them. It's reasonable to expect democratic control over the code in the future. Representatives will vote on what code gets deployed and what doesn't.

To learn about the code, the people must see it, so it must be open source.

This style of governance is commonplace in the cryptocurrency world. If proven effective over time, companies and governments will copy parts of crypto's governance structures.

☄️The Mother of All Scandals

Scandals already drive a lot of open source adoption, and we'll probably see more of them. The question is how big they will be.

If they're very big, the closed source world might be the one coming down like burning zeppelin. This would leave loads of space for open to grow into.

Mega-scale uncritical data collection is continuing in the US as well as in China. We have no historical precedence, so we don't know how that will play out.

The greatest illusion is continuity. We can know for certain that dramatic events will occur, and the future will be different.

☄️Closed Source Funds Dry Up

For the past 50 years closed source technology has been good investments. So investors have created closed source jobs.

We don't know if that trend will continue. Tech giants have stopped emerging. That's understandable, since yesterday's new names still haven't made any money.

Uber and Snapchat are still loosing billions per year, after 13 and 12 years in the red. Will they ever pay down their debts?

What's appearing instead of new tech giants is crypto projects. Hundreds of them. They're typically very profitable and all open source. They gladly go into profitable spaces that closed source can't reach.

☄️Food On The Table Becomes Free

Universal basic income has been suggested and piloted since forever. If it became reality, open source would thrive even more. The tens of years you spent building a CV that would give you a job that would put food on the table, they would be in vein. You could have been doing open source all that time, and your CV would have looked much better.

We can't teach people how to live. We have Wikihow for that. This is the first image in the tutorial How to Learn to Live Independently. It promotes templated textbook style living, as typically seen outside of open source. The image is called "Find a job".

Wrapping Up

The future is a volatile place, and a bet against open source might be as irrational as a bet in favour. Building a portfolio takes time, and it's too late to be early when everybody wants in.

But with all that said: Does open source put food on the table? Not in the most straight forward way. Not in all versions of the future.

- tobben

In earlier texts I've linked open source to warm fuzzy feelings, freedom, and happiness. Critique often comes in terms of survival or well being of the developer. The most typical question is whether open source work can put food on the table. I've been thinking about that.

Hopes, Dreams, and Agendas


HP4 works well enough for everyday use. Tiny things remain. Like attaching a Z-probe.

I'm thinking about what's next. Do I want to become a kit maker? Maybe sell big machines, or prints? Print houses? Rockets?

To get down to what I want, we must rewind the tape a little bit. It was one image in particular that propelled me into the Hangprinter project:

A directed graph showing how some real people have forwarded RepRaps to each other. Every node is a person and every edge represents a transfer of RepRap 3D printed parts. Incredible.

RepRaps have been spreading through a print-it-forward culture. That's an unusual and awesome way for machines to spread.

Getting Propelled

I was already hooked on an idea. I wanted to make a robust and distributed worldwide network of manufacturing. Peer to peer. The image above looked like an indication that it could happen.

It was a very frequent idea at the time, ca between 2011 and 2016, and lots of people were working on it. Reference for example the Wikipedia entries on Distributed manufacturing, Commons-based peer production, and Peer to peer for context.

Distributed Production. A New System

Central to the idea is eliminating thresholds for newcomers. Easy access. Anyone can join and become an independent manufacturer.

Also central is ease of replication. Anyone can easily help anyone else become an independent manufacturer.

This image shows some kind of transfers. One group is both a receiver and a supplier. Making enough groups fill both roles at once is key in establishing a distributed network.

The ethos of distributed production was copied from free/open source software, and from the Internet itself. We had achieved universal access to information and publishing in the preceding decade. Now was the time to achieve universal access to goods and manufacturing.

Praying it would take only a decade or so.

Star Shaped Networks are Easy and Rewarding, but Unfair and Fragile

Let's zoom out a little bit. Humans generally organize in star shaped networks, where the central node is very special.

Allowing for special treatment of central nodes helps star shaped networks off the ground. The prospect of ending up in center themselves motivates people to build stars around them. The star shape is also good for making quick decisions, critical in chaos and early phases.

Although easy to build, star networks can be fragile and unfair in the long run.

Network topologies. Only star leaves everyone disconnected when one single node goes down: The Center Node. The star's center has leverage on everyone else.

Distributed Networks Considered Desirable

Democracies have moved away from the star shape in their power and politics, to avoid the risks of authoritarianism.

When designing the Internet, the US military avoided the star shape. Its center would have been too easy to attack.

Democracy and the Internet have become very popular. Many like, and even idealize, their robustness/stability as well as their perceived low threshold, equality, and fairness.

Distributed Networks Are Hard To Create And Maintain

Distributed networks have few ways to reward its early creators.

In the cases of the Internet and of free software, it would undermine the projects' fundamental goals to give anyone special treatment. Being non-owned and distributed, there were no stock options to hand out. (Before tech giants appeared, but let's not go there yet.)

Harder yet: these networks had to recruit new, independent drivers of the network. A single group can not be a distributed network all by themselves.

Even still harder: All networks gravitate towards star shape. It's what people are used to, its easy to build, it's short-term efficient. A gravitation towards star shape should always be expected.

With few ways of reward, why did anyone work on such hard projects at all?

Many of them called themselves activists. In this simplified recollection, I will use that term for all of them. The Internet and free software were built by activists. They were eager to build something better than star shape, even at a personal cost.

Strong forces was put in place to counter act the gravitation towards star shape. For the Internet, it was automation (egalitarian protocol executed by computers). For free software and democracy it was law (copyleft, with its threat of punishment). Keeping a non-star network topology in check required such clever and quite ad-hoc solutions.

Keeping a network decentralized is hard, like keeping drops of mercury apart.

Distributed Production Requires Humans Who Require Rewards

It's questionable whether non-star ideals could be automated inside a manufacturing network back in 2011. Terms of Internet communication are agreed upon by computers. Terms of RepRap manufacturing were, and still are, agreed upon and executed by people. We can automate a lot, but not the people parts.

The free software movement's use of the law to keep the non-star topology in check has generally fallen out of favour. People dislike threats of punishment. We don't want to punish.

So people must be rewarded. Otherwise, they do something else.

Duplicating Internet's topology template within manufacturing requires more automation, or more reward to be present within the network than outside of it. It sounds hard. But we tried anyways.

For me, it was like this: I wanted to be useful. If accepting lower rewards made me more useful then, well ok then.

Hard and complex work was done under umbrellas such as RepRap, Arduino, and Open Source Hardware. Code and design files were maintained and improved. Plans were crafted and executed upon. Manifestos were written.

There were some Distributed Production success. The first image in this blog post convinced me that it was real. In fact, RepRaps were printed forward at least in the thousands, maybe in the millions, before more centralized brands and companies took over, and made the once distributed network of RepRaps more familiarly star shaped.

The same star shape was given to the Internet by tech giants around the same time. Centralization of the RepRap network was maybe even faster than that of the Internet. RepRap was centralized by the very earliest RepRap activists themselves.

Fencing In

Predictably, at the center of star shaped networks, tired creators are currently building fences around their work. The vast majority of open source projects have become star shaped networks. Also those who try to be distributed networks. See Nadia Eghbal's book for numbers on this. The gravitation towards star is stronger than any individual or company can overcome on their own. And we're not collectively building distributed production right now.

Having followed the activist track for a few years, creators typically need more stability and rewards. Patents, strict copyright licenses, and secretive development practices give stability and rewards.

It's nice to have a fence sometimes.

No one blames a fading activist. Everyone wish them all the best. Competitors, customers, and myself included. Even as production is tamed and locked into star like shapes, we should not call for distribution at any cost.

In the fading activist's wake, we find a richer commons (from early years, and through doors left open), and awesome products, retro-fitted into centralized manufacturing. No low threshold network, but old gems and happy customers.

Giving Up on Distributed Production?

Since I started working towards distributed production, I feel the manufacturing commons has plateaued, but at a higher level. I enjoy the heights we've reached. I feel grateful, even as we gravitate back into star shaped organizations.

But I can't help but think we're lowering our ambition by fencing in. We got half way towards an Internet-like manufacturing network, then rolled back to the old system.

We have achieved a manufacturing increment, still not a manufacturing revolution. We're not automating, we're not winning. I feel like we're retiring. We're tired.

I probably won't become a kit maker. I want to make a distributed production network. Hangprinter is too star-like already.

If I offer kits, and solve user experience issues, then I sink deeper into the middle of the Hangprinter star shape. I will get tired, and start building fences in there.

The Next Leap

Zooming back in on the present again. I think I know what to do next.

Blockchain projects, with their cryptocurrencies are a more fruitful attempt at duplicating the Internet's ideals and success. It is cyberpunk flavoured free software money, squeezed into the Internets own design template. Made by unknown activists towards whom we should be grateful.

They are protocols of rewards. Automated rewards. Non-activists stay on the network, and keep their computers on the network, because of the rewards.

As mentioned earlier in the text, distributed production needs more automation and rewards.

Let's try again, starting at the other end. Let's design protocols for decentralized manufacturing.

Let's reward manufacturing efforts with tokens. Let's introduce a blockchained manufacturing network, capable of representing and transferring real value. As real as the objects we make.

Let's create oracles who measure and quantify what we do, and what we could do. Let's get the data out. Transparently, on chain.

Let's build a treasury owned by the network itself. Let's govern it on chain, according to our own protocol.

We can't shoot objects through Internet cables. But we can shoot more things through them than we could before. Deals, rights, rewards, money, commitments, contracts, designs, plans, hopes, dreams, and progress. Let's try.

What do we have to win? Well, all the objects we'll make. We want to make things. We want the money. We want the pride. We want the craftsmanship. Manufacturing, baby!

And I think freedom. A place in society. Resilience. Owning ourselves more. Also described in 2016.

And yes, the little HP4 things that remain. My goal is, as it has been for a while, to not be the one who fixes them.

- tobben

HP4 works well enough for everyday use. Tiny things remain. Like attaching a Z-probe.

Snaily Snails Fighting Line Wear


The HP4 has done ca 75 hours of printing now, and shown great promise! I shouldn't be surprised that it's working well, given the insane amount of work hours that I've put in, but I am.

However, there's one thing that bothers be a bit. The lines already show slight signs of wear. I want to run HP4 unattended for thousands of hours. So I need to stop any fraying.

frayed D-lines
These D-lines are ever so slightly frayed.
frayed B-lines
As is this B-line. The image is heavily edited to highlight the frays.


I first tried filing down the surfaces of the bearings of the most frayed lines, to see if the rate of fraying slowed down.

small line roller anchors
The left one of these two bearings was sanded down, for a smoother and rounder surface, but its line kept fraying. Interestingly, the bearing on the right, where some colourant from the line has filled up "gaps" in the 3d printed surface of the bearing, like grease, did not fray the line nearly as much.

The result above called for experiments with line lubrication. So I tested to rub one line with stearin, just from a room tempered chunk. It seems to have stopped the fraying from getting worse from what I can see. I've also greased up one of the lines with some "multi grease" that I had lying around. That also seems to have mitigated the issue.

stearin and multi grease
Rubbing in lines with stearin and multi grease can reduce line fraying.

But even if my unstructured experiments with stearin and grease might have worked out, I don't particularly like having to lubricate my lines.

From the results above, I don't know for sure if it is the bearing surface, the sharp bearing radius, or maybe the white ceramic eyelet that causes the line to fray. But I'm making some guesses.

Since my sanding of bearing surfaces didn't immediately reduce the fraying by a lot, I'll let that potential cause rest for now.

I know that the previous Hangprinter v4 prototype also had fraying issues, but it didn't use eyelets at all. It frayed due to shear forces between lines and angled entrances to the vgroove bearings. That's why the new prototype has tilted bearings, so the line always can enter them in a straight line.

I think the ceramic eyelets probably contributes to the problem, but I think there must be other factors contributing as well. There are some line guiding bearings on the ceiling unit, with no ceramic eyelets. The line shows some very slight frying around those, which can't be explained by wear from ceramic eyelets.

So something else must be contributing, and let's believe/assume/hope for a while that shear forces are already mostly dealt with.

Based on those preferences, experiences, beliefs, and hopes, it is clearly time to test if bigger bearing sizes could be helpful. Meet the "Snaily Snail" line roller anchor, with a 608 skate bearing in it:

The Snaily Snail line roller anchor
The Snaily Snail is identical to the previous line roller anchor, except that it uses a larger bearing, and its bearing surface is shallowly U-shaped instead of the more aggressive V-shape of its predecessor (show on the left here).
The Snaily Snail line roller anchor pic nr 2
The Snaily Snail is entirely printed by the HP4 itself, making it the first self-printed improvement (attempt) that has been put into production on a Hangprinter.

Only time will tell if snails can eliminate the need for lubrication.

What Has Been Done and What Has Not Been Done

All other cable driven robots I've seen out there have bearings that rotate freely around an axis. Only Hangprinter has insisted on stationary snails.

Standard industrial rotating block
Standard industrial rotating block.
Experiment with rotating line roller anchor
An old OpenScad experiment where I designed something similar to a standard industrial rotating block for Hangprinter. It was never tested in practice because it was both complicated, and at the same time needed to become even more complicated for it to rotate correctly.

The reason for this is that the line coming from the ceiling comes at a constant angle into the snail. If the bearing rotated freely, it would not point directly towards the effector, it would point halfway between the effector and the ceiling unit. Except, there exist at least two tricks one could use to design around that problem.

Trick 1

We could let the line from the ceiling enter the "snail" in a particular way, so that all forces from that entrance goes through the desired axis of rotation: o

Sketch explaining momentum in snail
Forces acting on the line roller anchor we used last year. The trick is to reduce the black line labeled "Distance = d" to a length of zero, so the ceiling bound line doesn't create any rotational momentum on the snail. So the whole block would rotate around the cross, and the ceiling bound line would enter the snail via a freely rotating bearing that always points towards the ceiling, and lines up with the cross.

Trick 2

If the snail's bearing had two axes to rotate around, then any entrance direction could be matched up with any exit direction of the line, without any shear forces on the line.

Standard industrial rotating rotating block
Standard industrial rotating block with added rotational axis.

Both of these tricks seem ok-ish as solutions to the fraying problem. They're both not the most complicated mechanics in the world, but they add a significant amount of moving parts. There are six of these snails in every Hangprinter. If we count the line guides on the ceiling unit as well, since they do a similar job, there are 18.

Good bearings are expensive, and each will fail after X hours. Before failing, they will start asking for lubrication, with squeaking and rattling sounds. Not the end of the world, but we're trying to reduce price and maintenance burdens here.

The thought of implementing those tricks make my thoughts wander back to the good old days, when Hangprinters were barely working, but extremely simple.

Hangprinter's Snail History

Length control screw
2015: First ever Hangprinter ABC anchor. This worked, but the printed part was unnecessary. It didn't allow doubling the lines, and it didn't allow tightening the lines individually. Other than that, this solution was fantastic and unproblematic. Lines were carried on the effector itself, so there was no entry from the ceiling unit.
A solution called frame blocks
Also 2015: First experiment with doubling the lines. Bearings jumping up and down became a problem.
Babel tower print anchors
2017: The Babel Tower was printed with single ABC lines, coupled together via lamp hooks, drilled into the wall. Lamp hooks were also used for the vertical lines. Lamp hooks worked surprisingly well with the 0.35 mm thick FireLine. All lamp hooks didn't have the same good surface finish though, and at least one Hangprinter v2 crashed into the floor because a D line had been frayed and snapped. That's how D lines got bearings first.
Simple anchor of early HP3
Also 2017: Early versions of Hangprinter version 3 still used lamp hooks for ABC anchors. Given the D-line accidents we had seen though, we knew that we would have to let simplicity fly, and make line guiding bearings part of our Hangprinter lives.
Simple anchor of early HP3
Also 2017: The first snails used U-shaped bearings with 4 mm bores, and PTFE tubes as eyelets. We were halfway into sin with this one, and it had many problems. Lines fell off the bearing, the whole thing wiggled side to side, and the PTFE tube wore down quickly.
Early HP4 line roller anchor
2018: A late HP3 line roller to the right. Lines still fell off the bearing, but it wiggled less, could double the line, and had no PTFE tube that could wear down. Unfortunately, the slimmer vgroove bearings increased shear forces on the line. It was also easily broken if someone stepped on it by accident. The early HP4 line roller to the left only solved one of those problems. It was more sturdy, but it ate through FireLine in only a few hundred hours.

Hangprinter's Snaily Snail Slow Design Development in General

We're moving towards what other cable driven robots have been doing since forever, right? Why do we do it so slowly?

Hangprinter is searching the design space at the cheaper end of cable driven robotics. None of the other cable driven robots have become wide spread either, so we can't copy/paste or do "the obvious" while we're searching for solutions that aren't obvious yet.

There must be some deliberate searching on our end if we're to reach our goals. I wish we could search a bit faster though, but alas.

- tobben

The HP4 has done ca 75 hours of printing now, and shown great promise! I shouldn't be surprised that it's working well, given the insane amount of work hours that I've put in, but I am.



Hangprinter version 4 works now. It is the default Hangprinter design in the repo. It has some documentation, and it has some builders. It prints decent quality things, like this:

food waste bag holder Hangprinted
A holder for paper bags.

... and this:

self-replicated spool Hangprinted
A self-replicated spool for HP4.

... and this:

White Benchy
A white Benchy printed by HP4 while tuning firmware and slicer configs.

- tobben

Hangprinter version 4 works now. It is the default Hangprinter design in the repo. It has some documentation, and it has some builders. It prints decent quality things, like this:

Hangprinter v4

The HP4 Prototype 2
HP4 again.
Another image of HP4.

- tobben

Philosophy of Hangprinter


The Software

People hate Software.
Bugs, leaks, errors.
Cryptic messages.
Menus, forms, and help-pages.

Software says "Ok, doing it".
And you wait, you don't know how long.
You don't know what it's doing.
You need it to work.
It sometimes fails. After a while.

Like the most under-funded government agency imaginable.
Broken windows, rotten apples, full trashcans everywhere.
People defend themselves.
Against software.

The Plastic

People hate plastic.
Weak, cheap, poison.
Awful smell, cracking sounds, hysterical colors.
Short use.
Long trash.
Buries us, in lifeless artificiality.

Whatever disease you get,
there's always a chance
that plastic,
disturbing your hormones
triggered it.

That's what people feel.
Plastic comes from an unknown place, underground.
Plastic poison can penetrate your skin.
Get into your body.
Like the devil.

All other materials are natural.
Only plastic is not.
People defend themselves.
Against plastic.

The Robots

People abhor most robots.
Plastic and software with motors.
Commanded by others.
In our surroundings.

The few robots that people love,
are exactly those
that they control,

Other robots steal.
Grab attention.
Grab pictures, writings, and videos.
Robots intrude.
Take jobs.
Take lives.

Robots make money.
For the already rich.

Robots are
the ultimate source
of faceless power.

The Future

A single person
with superior robots
could subjugate all other humans.
All you need is scale.
This risk was not in the past,
but is in the future.

A group of countries
or companies
or countries and companies
with superior robots
own the world.
That's the present.

People must defend themselves.
Against robots.
And the only way
is with robots.

The power over yourself,
can stay yours in two ways:
through kindness of others,
who have robots,

Or you can have robots yourself.

People who hate software
who hate plastic
who have little money
will stumble into non-ownership of robots.
Through defending themselves
against software and plastic.

They must be given ownership,
or they will be owned.
Or worse:

They need free robots.
They need to be handed their free robots.
For free.
Extremely friendly robots.
Easy robots.
Entirely under their command robots.
But strong and valuable robots.

Robots that they will accept.
Robots that will eventually defend them.

But people hate robots.
And receive robots with stiff smiles.
Least wanted pair of socks, on Christmas Day.
Hangprinter is me, knitting socks.

I hate software and plastic. But I need Robots. And also you.

Just my kindness,
will not be enough to cover all,
when robots of power march in.

They will call it,
"economic realities",
and do what they want.
They will harm you only by accident.
Because they won't notice you at all.

But if you have robots.
A few for yourselves,
that you love.
Then you can step aside.
Not care about those in power.
And be free.

- tobben

People hate Software. Bugs, leaks, errors. Cryptic messages. Work-arounds. Menus, forms, and help-pages.

Torbjørn Must Test New Things. hp-mark Is Good Enough.


I saw this talk about one of my favourite artist's creative process. Here are a few quotes from it that I've reasoned around the last few days:

1: "Publishing is not finishing. All the emotions are different. [...] Publishing is deciding to stop when you want to keep working. And it's super painful."

2: "Publishing works best if you think of it as a style of working. It's an attitude that persists throughout the entire creative process. Working to publish is about getting shit done. Your whole mentality shifts when you're working to publish. You focus on the stuff that matters, and you ignore the stuff that doesn't."

3: "Working to publish, it's selfless, it's outward focused, it's about results, and giving back, and contributing to the world."

His shortest version of the good work to publish method is this:

4: "... doing only what matters, the whole time, and then stopping."

He explains that this is a great strategy because most ideas and attempts flop, and you don't know which will succeed beforehand.

5: "You can't choose what you're famous for. ... I can't make a song a hit. I can't control how my songs are pushed through the world and are experienced by others. What I can do is be prolific, I can be creative, I can make great stuff. What I can do is work to publish. You write the next scene, you record the next instrument, you build the next set, you shoot the next tape, you design the next synth, and I can [publish all that] and then I can move on, and I can go to sleep at night, knowing that I did everything I could."

I want to see if this musician's points can help me think better about where to take hp-mark and Hangprinter from here. His work is different from my work, but we're also similar. Let's see if we can make our experiences fit.

1: Publishing Is Not Finishing

Things are never finished, we have that in common. I like his emotion focused description.

With where I'm at with hp-mark right now, I don't want to keep working. So we're not exactly at the same spot, the musician and I. That's because hp-mark is not like a song. It's more like an instrument.

Since even before starting to build hp-mark, I've thought of it as lifting Open Source Hardware over a threshold, closing the loop, ending the guessing game in open source hardware positioning. A short-term grind, a long-term investment for the common good.

Proprietary machines have had motion tracking for decades. Everyone knows an OSHW motion tracker could be made. It just requires someone's work hours. That might as well be me, I thought. But it's not very fun, no, and I knew that. It's painful to continue. It will be delightful to stop.

My hp-mark process changes after this month's demo, because hp-mark is good enough. I have improved both code and hardware a lot, and tested it thoroughly over the last month. It can take OSHW over the threshold just fine, if it reaches widely.

Done March/April 2021
Tasks completed during this sprint.

2: Working to Publish

The musician and I have different outputs and different metrics. For music, success is to reach people. hp-mark needs to

to be successful. My pain comes from ignoring/failing at the former while working to my bones on the latter.

But the musician's point makes a lot of sense for hp-mark in the continuation. Just make a small thing and see if it flies. See if you can have a little success, quickly. I will get back to that way of working.

Make something small work well enough, then try to reach people. Make something else work then try to reach people again. And again and again and so on.

I regret not pasting a giant Aruco marker on the Hangprinter back in November 2020. I could also have dropped the spherical markers in December, when I found they were hard to make/source. And the colored markers stayed with me for too long also. I would have reached more collaborators and supporters by doing something simple, and then spent time reaching out instead. Imperfect decisions there. Well, well.

3 and 4 are Mostly the Same

I think quotes 3 and 4 mostly come down to the same improvement of process for hp-mark as quote 2 did:

  1. Make a small thing.
  2. See if it flies.

5: Torbjørn Tests New Things

I interpret quote 5 as "test new things, test different things, do the next thing". The last couple of Hangprinter years have felt a bit stagnant. Particularly on the outreach side of things. Why?

Many worthwhile Hangprinter related projects are hard and time consuming. Robustness is not quick, easy, cheap, or sensational. We need robustness. So I had to dive into "doing it right", and swam across the swamp.

Still, I should have done it more quick, easy, cheap, and sensational than I did.

There's always a light version of any project, one that breaks you down less. I must break down less. Economically and motivationally.

Quick things to try:

Things that I don't yet know how to fit into the quick publish and outreach success template:

- tobben

I saw this talk about one of my favourite artist's creative process. Here are a few quotes from it that I've reasoned around the last few days:

hp-mark Is Good But Lonely


The rabbit hole has gotten deeper. But progress is fast at this stage. Average error (that's accuracy) has shrunk from ca 35 mm to ca 3.5 mm. Maybe even smaller. I haven't tested accuracy thoroughly yet.

Precision (that's stability of repeated measurements) at the origin is down from ca 5 mm to ca 1 mm. And also:

CHECK!Detect all markers on 95% of training images

The markers have changed from small colored spheres to bigger retro-reflective disks. They're cheaper, lighter, easier to manufacture, and perform much, much better.

I had to go and implement the disk geometric equations. My body protested for days when I picked up that task. Luckily, this time I had a research paper to guide me through most of the theory, and I could quickly replicate my old test structure. This made me ca 10x faster compared to when I did the sphere geometry.

I've posted a couple of demos since last time:

The first video shows the more fundamental use case for hp-mark: auto/assisted anchor calibration. It enables all other hp-mark use cases, including homing.

So hp-mark is growing up.

The extremely high recognition and identification rate I have now is thanks to some LEDs that I put around the camera:

My Picam with led rings around it
My picam v2 with two rings of in total 20 LEDs around it. This removes most problems I had with shadows disturbing measurements. I'd say it took identification rate from ca 95% to ca 99%(?). Out of ca 1000 test images, I haven't recorded a single identification failure yet.

I know I could enhance accuracy and precision further by mounting these slightly higher end, low distortion lenses:

A set of low distortion lenses
A set of low distortion lenses that I ordered from Arducam. This setup would use the same image sensor, wire connection, and software interface as the current Picam v2.

However, changing the camera PCB and lens means having to calibrate it and also make a new mounting bracket for it. Plus all the fiddling with wires, focusing the camera, unexpected stuff etc.

My guess is 1-2 days of work. Is it worth it? What are my goals?

Keep Your Head Down And Work!

This sprint's goal is "high accuracy auto calibration". The higher level goal is "a reliable work horse". Peace of mind.

The better camera achieves all of that. So I have to do it. Just like I redid the markers.

This isn't how I worked a few years back. This isn't how the HP1, HP2, HP3, and first prototype of HP4 were made. They were all just barely working systems. This is why HP4 will be different.


Body is shouting loudly. And for good reason.

Rest of World, aka everyone I meet, care extremely little about hp-mark in its current form. It you're reading this blog post, you're among very few (source).

As much as I crave attention, Rest of World craves brain tickle. Humans need this always. Brains want to light up.

Current form hp-mark just isn't very...

A side shot of Darth Vader's helmet
MRI scan of person reading up on how a measurement system that is unrelated to their life improved from 35 to 3.5.

... stimulating. For me, a person who is constantly dying for attention, this is a problem.

What To Do

Even at nanometer precision, hp-mark without a context would be nano-stimulating to the non-Hangprinter owning world. Common solutions to this kind of problem:

  1. Pay folks to suffer through your under-stimulating thing. Attention-as-a-service. Day jobs. Ads. This is the most common solution out in the wild.
  2. Find people who love your stuff by unusual amounts.
  3. Put your thing into an exciting context/story.
  4. Pitch! Learn pitching dark arts.
  5. Accept defeat.

All of these have their own pros and cons. Too much to write down here. I will do number 5 for the rest of this sprint, and then try my luck at number 3.

Tasks of the current sprint
The sprint in question.

The first slightly more exciting context, at least for hp-mark, will be HP4. End-to-end, released machine, with build manual and all. I look forward to that.


HP4 is not very interesting on its own either though. It will need it's own number 3 eventually. A context creates a story. Without a story, humans can not understand, or hardly even perceive your stuff.

Number 3 Suggestions for HP4

Short End Note

The old HP story is basically "a living thing that creates economic value". Fully automated, self-replicating, printing furniture, taking zero space when not in use. I'm not sure if that is tickly enough from my attention cravings' perspective. Before it's even out there we'll never know.

hp-mark does more than just exist now. It's getting quite good, but also quite lonely.

- tobben

The rabbit hole has gotten deeper. But progress is fast at this stage. Average error (that's accuracy) has shrunk from ca 35 mm to ca 3.5 mm. Maybe even smaller. I haven't tested accuracy thoroughly yet.

hp-mark Exists Now


I climbed down a rabbit hole recently. Nearly half a year working on hp-mark. The past 84 days even skipping blog post and newsletter writing.

Progress has been steady. It works now. hp-mark measures positions, like:

First ever non-zero result from hp-mark
Result 1: [-1.27, -217.65, 2.68]. Hand measured position is [0, -217, 0].

Accuracy is not fantastic. The image above is a lucky one, with only 3 mm of error. A more commonly seen error is around 35 mm.

A lot of hp-mark work remains. I ticked 2 boxes, and added 6 new ones in the roadmap today:

Acquire camera 6D pose (this includes defining our world coordinate system)
Acquire effector 6D pose
Detect all markers on 95% of training images
Take image ourselves upon request, don't rely on other programs to take image first
Create a continuous stream of position measurements (video?)
Get a statistical idea about size of error
Respond to RepRapFirmware/Duet request for position measurement
Integrate a second camera, to reduce error

I'm a bit overwhelmed still. I need to look backwards a bit.

What Have I Done?

I've been surprised.

Video stitched together from today's test images.

I chose C++, OpenCV, and a very traditional approach for this project. I just wanted the most basic code that would mechanically find circles among pixels, and then apply static geometric equations to transform circles into a nozzle position. No AI stuff, no GPU stuff, no fancy hardware control, just $$ f(x) \rightarrow y, $$ where \(x\) is an image, and \(y\) is a nozzle position.

Such an old and explored problem! I felt confident.

Some things that took long for me to program, in descending order:

I feel like I'm almost too tired of it to even write about this stuff now. But before I climb out of this rabbit hole, I can show you something about how the ellipse detector works internally:

Input to ellipse detector
A zoomed in version of the original image from the PiCam v2.
edge image inside ellipse detector
Color contrast between pixels were used to find these edges in the image.
segment image inside ellipse detector
The edge pixels are the grouped into segments. Each segment has a different color in this visualization. A single segment that forms a closed circle or ellipse will be detected already at this stage. Most detectors can find complete closed-curve ellipses quickly and easily. What sets ED_Lib apart is how hard it tries to piece together the chopped-up circles, and how quick and cheap it manages to do this.
lines image inside ellipse detector
The segments are split up further into lines and arcs. These are the lines.
arcs image inside ellipse detector
... and these are the arcs. (If you compare very closely with the segments image, you find that not all arcs match exactly. They should match exactly. I mixed up images from two different runs when preparing this, so this arc visualization is ever so slightly off. It's still representative for the result below though, in that the top blue marker could not be found among these arcs either, but all other markers were found.)
output of ellipse detector
The arcs are combined into circles and ellipses according to many different heuristics.

In the image above, we see that one marker was missed, despise ED_Lib's many different heuristics. I tried to tune the heuristics for the hp-mark use case. See how that went, here.

Ultimately failing to tune the heuristics convinced me to put background plates below my markers. That is what I'm currently working on. They will probably end up looking something like this:

marker with bent octagonal background
Test of marker background with bent octagonal background.

The final background design will probably be flat and circular, and hp-mark will use the edge of the background, as well as the marker itself, to determine its position, further improving both robustness and accuracy of the system.

But not today. I'm so tired of that kind of programming. Let's celebrate the results at the top of this post for a while first. And let's rest.

- tobben

I climbed down a rabbit hole recently. Nearly half a year working on hp-mark. The past 84 days even skipping blog post and newsletter writing.


Yearly archive: 2014, 2015, 2016, 2017, 2018, 2020, 2021, 2022, 2023

Hangprinter Project: [1], [2], [3], [4], [5], [6], [7], [8], [9], [10], [11], [12], [13], [14], [15], [16], [17], [18], [19], [20], [21], [22], [23], [24], [25], [26], [27], [28], [29], [30], [31], [32], [33], [34], [35], [36], [37], [38], [39], [40], [41], [42], [43], [44], [45], [46], [47], [48], [49], [50], [51], [52], [53], [54], [55], [56], [57], [58], [59], [60], [61], [62], [63], [64], [65], [66], [67], [68], [69], [70], [71], [72], [73], [74], [75], [76], [77], [78], [79], [80], [81], [82]

Hangprinter Campaign: Github Sponsors

Hangprinter Merchandise USA:

Hangprinter Merchandise Sweden:

Hangprinter Project Homepage:

Print Issue Solution Filter Project: [1], [2], [3], [4]

Sourcing RepRappro Mendel in Larvik: [1], [2], [3], [4], [5], [6], [7]

Github Profile: link

Gitlab Profile: link

Hangprinter project on Gitlab: link

Vimeo User: link

Youtube User: link

Twitter User: link

Instagram User: link

Master's Thesis: link

Linkedin Profile: link

Appropedia User: link

RepRap Forums User: link

Forums threads: Hangprinter version 1, Hangprinter version 2, Hangprinter version 3, List of Hangprinter threads

Source for this blog: Gitlab repo

Everything on this homepage, except those videos who are published via Vimeo or Youtube, is licensed under the Gnu Free Documentation License. The videos published via Vimeo or Youtube are also licensed via Vimeo or Youtube.