With the advances in rapid prototyping, there’s been a huge influx of people in the physical realm of hacking. While my overall view of this development is positive, I’ve noticed a schism forming in the community. I’m going to have to call a group out. I think it stems from a fundamental refusal of software folks to change their ways of thinking to some of the real aspects of working in the physical realm, so-to-speak. The problem, I think, comes down to three things: dismissal of cost, favoring modularity over understanding, and a resulting insistence that there’s nothing to learn.
Cost Models Don’t Translate
Software guys are always the ones in the comments spitting on cost and looking at people charging reasonable prices for good, well-made, well-supported, and well-designed hardware as charlatans and thieves. Then they go and buy cheap trash and have a bad time. It’s absolutely bizarre to me, but I have a theory as to why.
The only cost in computers is time. For a sufficiently large software operation capital costs are negligible. Development cost is measured purely in time. Computer time is measured in time. Shipping the product is instant. Even if you need more computers, these days you just call Google or AWS and order more time. Everything physical is free. There’s no cost to change. You can try out new ideas quickly. If you make a mistake you update the client’s software and the cost is negligible. Even the support cost is time. It’s a magical realm of pure abstraction.
Where this differs in mechanics (or electronics), is a sort of complex minimum cost. Things cost, and they cost a very determinable way. It really comes down to this: math says you can get rid of the wobble in this movement, but it will cost this much and it’s non-negotiable. Math says you can get these parts to fit together all of the time, or half the time. It will cost this much. Math says you can get 99% reliability or 93% and it will cost this much. If you want a case without a fan, you have to buy the more expensive capacitors or they will let the magic smoke out. Math says so.
We will never ever see a FDM 3D printer that’s just as good as the industrial ones for a hundredth of the price. Maybe a tenth. A 100 dollar FDM 3D printer will suck. There is no magical code optimization that will bring it down, or a processor that is just waiting around the corner to make the computational cost meaningless. There will be some massive trade-off defined by natural laws, which are insurmountable. Ten to one it will print abysmally slowly to reduce the forces. More force generally means more material, that’s it, no argument. Perhaps a different technology all-together may help, but even that will have its natural law defined limitations.
Working in the real world costs an absolute boatload of money. Two boatloads. If you need 3,000 screws, someone has to mine, smelt, ship, melt, form, treat, ship, store, ship, and more until it’s gets to you. Each of these steps has a minimum cost. If you buy the wrong screw your product may fail. If you managed it anyway, then you have 3,000 screws you can’t just instantly wish away and bill time on. It’s real stuck capital whose value may have instantly vanished in a QC step three companies away from you.
Hardware development costs much more money, and the playing field is much more uneven. In hardware, capital wins. There is no real story where two guys in a garage made a hardware device that they got 3 million customers on, and then sold to some larger company for a boatload of money in a few months. I mean, just the screws used to hold the casing on 3 million of most products could fill a small garage from floor to ceiling and crack the concrete while they’re at it. When a hardware company gets funding, they don’t buy fancy chairs. They buy space and machinery.
If you want to try out a new feature in software, you just spend time coding it. If you want to do it in hardware you have to spend time designing it, then you have to make it and test it (although, obviously packaging and testing are a large part of software engineering too). In hardware this costs additional money. Then once you have it designed you need a big space filled with lots of people and expensive machinery, who need to build it in an organized and predictable way. When you make a change you have to throw away or phase out all the old parts, make a documented change, and order new ones. It’s really hard. It costs money. I could lament forever.
Also consider the cost of testing. Pedants aside, these days in software, you test one product, and it works pretty much everywhere. In mechanics, each and every single unit you sell is different like fingerprints. So you have to test every single one if you want to guarantee any sort of quality. Not only that, when you find an error, it will need individual attention to fix, and the part that failed the inspection is worthless. All the capital that went into it is gone forever. It even costs money to throw away. A lot of , “cheap”, manufactures skip this step as it’s insanely expensive. If you’re Apple, and you’re making millions of a thing you can spend millions to automate some of these things, but if you’re a small run manufacturer and you want to guarantee any sort of quality, you just have to pass the cost on.
Lastly is support. Just like testing, when something physical fails a physical person has to remove something broken and replace it in the real world. Who does this? How much is the replacement part? I know I’ve said it before, but a broken part is money that, relative to the company who made it, has vanished from this earth. Every hardware Kickstarter is recommended to begin at a 200% percent mark-up. I actually advocate for more. What happens when your newly launched LED party lights let out the magic smoke in 10% of the units? You eat the time cost and the physical cost. There’s no simple bug fix.
A good product, from a vendor who’s not selling lies, will cost a lot of money, and that amount of money is reasonable. If it doesn’t cost a lot of money, there are serious trade-offs.
My Modularity is Not Your Modularity
Mechanics can’t be treated like code. For example, it’s very wrong to look at a 3d printer as if it is a universal library for turning computer signals into mechanical movements. You can’t make a good CNC out of a 3d printer, you can make an okay 3d printer out of a good CNC. It’s really kind of like downloading Quake III’s source and then hacking it to load a Crysis map. Technically it’s a FPS and technically it’s a Crysis level, but it’s not even close. It even sounds dumb when I say it; would that even work?
If there are libraries and modules in mechanics, they unfortunately have to be loaded into your head. You can’t really find a, “from CNC import 3d printer,” sort of solution. You have to know; you have to ask people who know more than you. You need to take things apart. There’s quite a bit of suffering involved before you start to see the patterns.
Once you get there, you’ll find your thoughts will be fairly agnostic about materials, hardware, etc. You begin to hold these things as variables rather than components. When you begin to solve a problem you start by understanding the forces involved, or the output required. Most people with a software background tend to want to solve mechanical problems like systems problems. I’ll get a linux computer, an Arduino, a stepper driver, a stepper, some belts, some pulleys, etc. Then once they have all the parts in front of them, they try to put the chunks together to get a working “program.” Once they have a working program, it’s tuning time. However, you can’t tune “fundamentally flawed” out of a system.
The trained guy’s approach is more esoteric. Okay, I have an extruder that I estimate to weigh about 200gs, I’ll be deaccelerating this from 30mm/s to 0mm/s in 20ms so I’ll need to deal with a force in my x-direction and so on. Maybe you’ll pick up a 200g weight and try to simulate it to get a physical idea.When modules are used they are factored into these equations to shape the final answer. For example, okay, I’d like to shave 100g off my extruder, so I’ll use a Bowden, but the Bowden has its own spring force to add, etc.
Also, once you design something, how do you build it? It’s akin to having to think about how someone is going to design the compiler to compile the single line of code you’re working on, while you’re writing that code. If it’s going to be machined, molded, extruded, or formed in anyway, this is pretty much what you have to do. It requires a lot of understanding and experience of and in every step of the process.
I’m just saying there’s a whole different art to it, a whole new wonderful field of things software guys could be learning. When someone has something kind-of working and they insist that the experienced guy telling them it’s wrong is wrong, they deny themselves an opportunity to learn, and they hold back advancement in the field.
There’s a lot more to learn.
The last, and worst is, when confronted with this kind of information, people keep insisting that they are right. They are not. It’s really really hurting the progress of some of these projects in the open realm. Innovation wise, the commercial guys are doing just fine, and in a lot of ways have dramatically overtaken the free hardware movement. This is because they have to make money, and can’t ignore the rules. If they do, they go Aluminatus or LumenLab. My favorite is 3D printing, and I just haven’t seen a lot of mechanical improvement. Just the same bad hardware patterns, and better software that is starting to reach the limit of what it can compensate for. CNC machines have gotten worse since 3D printing came along. It’s likely that most people have had a bad experience with 3D printing, and just don’t know it. Half the things people tweak in the 3d printer settings should never have been a problem in the first place.
There is no way that years of programming and standing on the shoulders of really short giants makes someone an expert in machine design. Just like that bit of awful python code I did the other night doesn’t make me a good programmer. Heck, I’ve been learning to design machines and designing machines professionally for eight years now; I’m almost ready to say I’m okay at it with a straight face. Quiz me, I’m a journeyman at best, but I know it, and it gives me room to learn.
The truth is, most software guys are bad at mechanical design, and don’t have a good or even beginner grasp of it. It’s not that the bad design should stop. It’s not that people shouldn’t go out right now and build lots and lots of awful machines. Please do! It’s great! A lot of bad code has to be written before someone starts to write good code. However, if you can’t admit to the bad code, you can’t learn. You can’t even begin to ask the right questions.
When they are ready to admit it the mechanical guys will be there to work with them to make it better. I can only speak for myself, but I am willing to teach endlessly about real cad software, critique designs, talk about manufacturability, cost, the whole field, and hopefully find some spots where I am wrong or lacking and learn new things. Once we begin to be on the same page in some key ways, different perspective from a different field may even be the fresh eyes needed to find new solutions. After all, we’re all hackers in the same spirit, and making the world a more interesting, if not better place, is what we do best.