A while back I wrote a piece titled, “It’s Time the Software People and Mechanical People Sat Down and Had a Talk“. It was mostly a reaction to what I believe to be a growing problem in the hacker community. Bad mechanical designs get passed on by what is essentially digital word of mouth. A sort of mythology grows around these bad designs, and they start to separate from science. Rather than combat this, people tend to defend them much like one would defend a favorite band or a painting. This comes out of various ignorance, which were covered in more detail in the original article.
There was an excellent discussion in the comments, which reaffirmed why I like writing for Hackaday so much. You guys seriously rock. After reading through the comments and thinking about it, some of my views have changed. Some have stayed the same.
It has nothing to do with software guys.
I definitely made a cognitive error. I think a lot of people who get into hardware hacking from the hobby world have a beginning in software. It makes sense, they’re already reading blogs like this one. Maybe they buy an Arduino and start messing around. It’s not long before they buy a 3D printer, and then naturally want to contribute back.
Since a larger portion of amateur mechanical designers come from software, it would make sense that when I had a bad interaction with someone over a design critique, they would be end up coming at it from a software perspective. So with a sample size too small, that didn’t fully take into account my positive interactions along with the negative ones, I made a false generalization. Sorry. When I sat down to think about it, I could easily have written an article titled, “It’s time the amateur mechanical designers and the professionals had a talk.” with the same point at the end.
Though, the part about hardware costs still applies.
I started out rather aggressively by stating that software people don’t understand the cost of physical things. I would, change that to: “anyone who hasn’t designed a physical product from napkin to market doesn’t understand the cost of things.”
It’s really easy to do. I mean, if one person set out to build an iPhone from scratch (I mean, really scratch, like bits of rock and dinosaur scratch) the cost would be astronomical. It would be a country’s economy over years. Which, if you look at it, is exactly what happened. What I’m getting at, is that our economy is set up to distort the value of things dramatically.
An iPhone costs Apple about $293 dollars the second it lands on a retail shelf. The selling price is a little over double that. (Which is actually a pretty reasonable margin.) The iPhone itself is made by Foxconn, a company that has 77 billion dollars of assets. That’s not their income or expenditure. That’s the land, machines, buildings, gold bars, etc that the company has to leverage. They can use that to take a bunch of parts and end up with an iPhone at the other side.
This kind of leverage makes it impossible to get an accurate gauge what a thing should cost if your metric is the stuff you can buy on Amazon. So it’s important to understand that once you start evaluating hardware on the price of it alone, it’s really really difficult to do so accurately by using the regular purchasing power our society imparts on us. Especially when the equipment starts to get more specialized and the manufacturing drops from the billions of leverage scale to the millions or thousands of dollars to leverage scale. Apple could make a printer nozzle of amazing quality for practically the raw cost of the metal. An import or American manufacturer with four automatic lathes cannot.
However, as mentioned, it’s also important to note that even when you have these incredible amounts of capital to leverage against, all you can do is bring the cost closer to the raw material and time cost. You do this by bringing more steps in house and running it on previously purchased capital costs. You still can’t eliminate the hardware cost and get a pure time abstraction in quite the same way as you can in software. In fact, every penny of misspent hardware costs lose money on a bigger scale than before. The sword cuts both ways for Apple engineers.
And, the part about time cost still applies.
When you get down to it, most activities are low capital cost and the billing is generalized to time. I could have made the same point from the perspective of any regular office employee. as far as most jobs are concerned, capital cost is small, and money is only made on time.
Another interesting example from the comments was the field of contract engineering. In this case, even though the engineers are designing the hardware, the cost of their time easily dwarfs the cost of the capital investments they have to make to finish the design. However, it kind of neglects the fact that someone else is eating that cost to build the thing they designed, so it’s kind of a wash. All those engineers are still doing cost estimates, or they should be if the firm is worth anything.
Also, I noted a few mechanics and technicians were mentioning that their time cost outweighed the capital costs. I don’t really think those fields apply. Though I do think someone who does construction or big installs would instantly know and have suffered through the same cost constraints.
In the end most of you agreed with my point that the hardware world has a different view on costs than software and other realms. Software and hardware design processes have so much in common, that it’s hard to note this difference at first. I still remember the first time someone handed me a stamping and told me it cost five cents. It absolutely blew my mind. I was mentally costing it out at five or ten dollars. It’s just a whole different world sometimes.
If you’re an amateur designer you HAVE to learn a little physics before you can make assumptions.
This is the other big thing I harped on was the tendency for amateurs to pass around a design as good. Pretty much no one disagreed on this with me. Just because it works doesn’t mean it’s good. A better understanding is needed before it’s wise to pass judgement on the efficacy of a movement.
A person or two asked how they could get a better understanding of mechanics. I would like to be a bit more useful that just, “learn da fyziks, stoopid,” this time around. If you would like to get more serious about being able to evaluate mechanical design, I think there is a fairly short path to a beginner understanding. Perhaps a month or so of part time learning. Here’s mine; though, I’m 100% positive we have some old hats or savants out there that can propose a better path in the comments.
- Learn what a vector is and learn how to get component forces in two dimensions. This is all algebra. Don’t worry about multiplying them. Addition and subtraction is enough.
- Moments & Joints. Learn how to convert a twisty force to a pushy force (getting technical with my verbiage) and vice versa. Learn how to draw a properly constrained mechanical schematic.
- Beam tables. Moment of Inertia Tables. Learn how things bend. These tables take the calculus out of calculating simple deflections. You basically plug in the values and add them with simple algebra. This will tell you that, no, you can’t put a three kg assembly on an 8mm round rod and expect accuracy.
- Material properties. Learn what makes a material brittle and what makes one ductile. What makes a material elastic? What’s crazing? The best way to do this is to read case studies and material descriptions. Try to find out what makes a material fail.
- Calculate spring force. Learn what a damper is. Understand that some things resonate, and somethings convert force to heat over time. Most dynamic systems can be converted to a Mass, a Spring, and a Damper. For example, the belt on a 3D printer is a spring and damper (its mass is negligible), and the extruder assembly is the mass. Don’t bother with the calculus. If you do come from electronics, it’s the exact same equations as RCL circuits.
- Learn what shear, tension, and compression is. You’ll have learned this mostly in the previous points already. Learn the math for a simple bolted connection.
- Read about mechanisms. Don’t worry about the math too much. For example, you can use the math from bullet point 1 to understand how much force a gear sees. You don’t have to actually learn what an involute curve is to use gears though.
If you enjoyed all that it’s time to brush up on basic calculus and get a mechanical design book.
The other important thing to do when learning mechanics is EXPERIMENT. EXPERIMENT. EXPERIMENT. Just like you can’t learn how to program by only reading about it. You have to code. You can’t learn mechanics by just reading about it. You have to do it. When you are doing section two, for example. Get two spring scales. Put a pivot in the middle of a stick. See how the forces change as the distance from the center changes.
If you want to learn beam tables. Hang a cinder block from some tubing. Weigh a cinderblock. Measure your tube. Do the math for it using the beam tables. Then, suspend a tube on each end. Position the center of the tube against a door frame. Make a mark with a pencil. Then hang a cinder-block off it and make another mark. Compare the result to the math. This sort of thing is fundamental to developing an understanding.
Next, take stuff apart. Go to a thrift store and buy an engine. Take it apart. Whenever you run into a why, get online and ask questions. “Hey, why is this bearing sealed?” “Why does this engine use a mixture of oil and fuel?” Go take a few inkjet printers apart. Guess why they did it. Compare a really expensive printer to a cheap one. What changed to make the print quality better?
After that, try to make your own. That’s when you start to learn things like the reason why 3D printers only use three linear bearings instead of four for each axis. (If they used four the rods would have to be absolutely perfectly aligned. When they use three the third bearing can be considered a pivoting joint constrained to the current z position of its location on the rod.)
The last two bits of advice are just general learning advice.
Be open to the idea that you are almost certainly always either totally or a little wrong. Read, Asimov’s the relativity of wrong. It’s not a bad thing to be wrong. I am almost certainly a percentage wrong through this whole rant/essay. Being wrong about something is how you learn to move the needle a little more to right. Most engineering is simply this process. It’s doing enough math and having enough understanding to get something to provably meet all requirements for most situations most of the time.- Move out of your comfort zone. It’s really hard to build a massive skillset in one thing and then move to another and find yourself a beginner again. It’s a big blow to the personal pride without an adjustment of mindset. It’s especially hard when those two things are just similar enough that they feel the same. A theme of the past piece was moving from software engineering to mechanical. My pet example of not moving out of a comfort zone is OpenSCAD. It is CAD done with programming, but it doesn’t make it good because your previous skill set got you results in a new field faster. It will take some time to develop the spatial reasoning and new patterns of thought that other modeling software require, but the tools are more powerful. Likewise, it might be tempting to write or use simulation software to do the math when learning, but it is actually more beneficial to do the math by hand and an experiment in the real world.
Distrust.
The closing statement is one of distrust. It’s a good thing. The nice thing about the sciences and technical fields is they hand you a skillset for evaluating truths. When someone tells you something (I really like 3D printing, sorry) such as, “this extruder is better than that extruder.” Ask them why. If they start telling you about experiments instead of experiences, they’re on the right track. A lot of amateurs want to use single data points as a judgement in general. I had a bad experience with X so X must always be bad. However, we all intuitively know this is not the way things work.
Ask questions that align with a mechanical understanding of the problem. Why is 1.75mm outselling 3mm filament? “I like 3mm because that’s what I’ve always used,” is not an endorsement worth consideration. 1.75mm needs less heat to melt its entire cross section and it puts a smaller back pressure on the stepper motor, is an endorsement worth considering.
Thanks to everyone who commented in the previous post. Thanks for the excellent content of them all. I hope we can continue the discussion. I hope my mistakes helped in some small way and any new mistakes I snuck into this one help too. I also hope we can see more and more cool mechanical projects on Hackaday with some really awesome design behind them. Looking forward to another discussion in the comments below.
In what ever you do, it is better to fail the first time than succeed – if you by luck, get something right the first time, it becomes a data point [ and blind spot ] in your head, so that if you have a problem involving that design / program, etc. you end up thinking ‘ It can’t possibly be that – the last/first time I did it that way, it worked, so it can’t be that ‘, rather than thinking – I wonder – is it that, I better check it.
Especially in bridge building and grenade inspection.
Any software friend of mine who wants to tinker in hardware is getting linked to this article. The 7 steps about learning the physics is spot on. I also like the section on distrust, I odn’t believe anything I calculate is right until it has been double-checked at least once.
“EXPERIMENT. EXPERIMENT. EXPERIMENT.” I wholly support this statement more so than learning the physics because as I have learned from numerous intimate encounters with those “more educated” than I, a degree is more or less proof of regurgitation, not application. Because certain factors are reasoned to not apply by means of mathematics does not actually contain the gist of reason to do as accidents are innovations greatest achievements.
Today though, you should be harping on the movement between both parties towards a direction with more application. More so the maker movement has become a novelty, a toy, more than a serious venture in changing the world as themed by your HaDPrize. Drone this, game that, clock this and LED that seems to have confused the very principle of giving the freedom to the masses to build to adapt. We are given more and more advanced tools to create a significant forum of connectivity, application and refinement of the things we abuse today and instead both sides invest their time in what is championed like useless robotics or redundant games. Not only does the creator bear some responsibility for not improving our platform but so do the forums such as Make, HaD, etc because they inspire the novice to follow a path of greater aplomb as displayed by what is advocated. Now I shall break in to song…
As a person with an advanced degree in Mechanical Engineering, and going on 30 years of professional software experience (including more than a dozen working on a feature-based, parametric solid modeling software) I would like to offer that your were right the first time. And the second time.
Once upon a time I wrote a (bad) thesis on the importance of a common design language to the success of multidisciplinary engineering teams (i.e. those working on mechatronic systems like 3D printers). Add a couple decades and I’ve come to appreciate how smart I was then. A common language (mutual understanding) is not important, it’s critical. Without it, the end product invariably sucks.
So, how can a team learn this language? The same way babies do: listen carefully, try talking it, and look for responses. Sit down with the other engineers and try *really hard* to understand what they do. Do this often, so it becomes habit. Don’t do this with a project manager in the room, ever — there is no checkbox associated with this time. In the end, however, you’ll have made yourself and the team as a whole much more valuable to the world (i.e. you’ll be doing better, more meaningful work).
Very insightful, thank you for sharing.
If it works the first time around, Start looking for the design Flaw. Something was missed.
I think there’s a Murphy’s law for that, probably phrased something like this: “If it works the first time, it will fail catastrophically in the future.”
As a person with an advanced degree in Mechanical Engineering, and going on 30 years of professional software experience (including more than a dozen working on a feature-based, parametric solid modeling software) I would like to offer that your were right the first time. And the second time.
Once upon a time I wrote a (bad) thesis on the importance of a common design language to the success of multidisciplinary engineering teams (i.e. those working on mechatronic systems like 3D printers). Add a couple decades and I’ve come to appreciate how smart I was then. A common language (mutual understanding) is not important, it’s critical. Without it, the end product invariably sucks.
So, how can a team learn this language? The same way babies do: listen carefully, try talking it, and look for responses. Sit down with the other engineers and try *really hard* to understand what they do. Do this often, so it becomes habit. Don’t do this with a project manager in the room, ever — there is no checkbox associated with this time. In the end, however, you’ll have made yourself and the team as a whole much more valuable to the world (i.e. you’ll be doing better, more meaningful work).
Almost forgot to mention Welty and Wilson were two of my profs. Love that book.
Software guy here – I did put a 3 kilogram load on 8mm rails!. That’s kind of eerie…
I take it you came to the same conclusion that the article mentioned?
My conlusion was, i need a longer rod. Hard to see it bend if it’s only 20mm long…
We need that discussion between software/digital hardware people and analog hardware designers too.
For example: there really are better op amps than 741s and TL072s.
Imagine only using compilers or software tools from the 60’s (741) or 70’s (TL072).
Well, as an EE I do agree with you. Now as a hobbyist I am really into those old 741’s and TL072’s: they are cheap and proven and readily available everywhere.
Give me a clue on your Forth. Does MVP mean anything to you?
“Just because it works doesn’t mean it’s good.” And that is how you end up with OpenSSL.
I’m a software dev and I’m seeing a similar problem. But I believe the issue lies with the internet, not “a software guy trying to do hardware” In software the common development scheme is becoming less sophisticated and more “script kiddy”. I attribute this to both the internet where people believe what they read and the fact that businesses are pushing for faster cheaper. So the real engineers are not able to spend the time that is needed to create a quality solution, instead they are pushed to create a “make it work now, fix it later” approach.
“Make the hardware work now, fix it in software”
Fail fast. That’s my philosophy.
I am more of a “study, verify and make sure everything looks good first” kind of guy. My iterations are slower but surer.
Mine is “make unit testing”.
Spot on Gerrit. Perhaps the community can find a collection of links pertaining to hardware design? Articles on loads, stresses, inertia, acceleration, radial/axial/linear. I’ve read a few of such articles, but the math always get me (if you’re not a mechanical engineer or physicist then it always appears that the calculations are unreadable).
However, I am totally ok with online calculators. They’re a quick solution if you know how to use them properly. Years ago I found one online for linear movements that was completely graphical. It would show deflection based on all of the parameters (unfortunately I cannot find it anymore).
I’m no mechanical engineer. I’m not a software engineer either. It’s all just a hobby. I’m currently on my 4th 3D printer design, this time ignoring current designs and doing everything from scratch. Why? Because most designs out there are based off the same thing, with the same faults. I’m leveraging knowledge from experienced engineers because honestly I couldn’t do it on my own (this is as opposed to amateurs asking amateurs for help). The first 3 designs all had the same faults that everyone else was making, because I had believed that they had experience and knowledge of the forces at play.
I had the same experience with my first PCB design. I had decided to take a current design, and without consideration in checking the work I made my work modelled after theirs. This was the biggest mistake I had ever made. Traces were undersized, connectors were underrated, pullups/pulldowns were omitted all because I had assumed that the original designer had chosen proper components. The PCB caught fire, and the next one I built too. I have it here sitting on my desk as a reminder to always check the specifications, do the math, and make sure everything is properly rated. There is nothing worse than an unnecessary safety risk due to negligent design. My latest revision of this PCB has been painstakingly designed to account for every reasonable mode of failure. Every component was chosen for the proper rating, every trace calculated, every connector overrated.
Don’t use someone else’s design unless you know why a component was chosen, and if it is sufficient for the job. At the same time, try to understand why certain choices were made, why is a clamp used instead of a setscrew, why a brace is used, or why a belt instead of a screw.
“Don’t use someone else’s design unless you know why a component was chosen, and if it is sufficient for the job.”
Indeed, and true regardless of whether the component is software, electronic, hardware, fluid or thermal. I try to understand the original designer as much as possible before attempting to understand their choices on a particular project. This article and these comments show that the same component can be chosen for a wide variety of reasons and purposes.
Meh. I shoot from the hip. If the component blows, then there wasn’t enough caps haha. Similar to misspelling commands in code and not picking it up for 5 revisions. Both are great sources of learning information.
And here on HaD I get to see both on a daily basis. If you have ever read the comments from a teardown, you will see that folks have quite the imagination when components are involved and only about 5 people on the planet actually know how electronics work. Pretty much all of that and using an O-scope to probe voltages smh.
That’s why the 3D printer I’m (slowly) working on will have ball screws driving all 3 axes, with 2:1 cogged belt reduction driving them. Short belts to drive the screws, just like the massive knee mill in my shop with its 10×50″ table.
Alignment issues? What alignment issues? The Z axis will run on linear bearings on two large precision round rods on a frame which someone else already paid who knows how many thousand dollars for. It cost me $10 at a surplus store. I’ve already mounted the THK linear rail to it for the X axis and had my custom design for the hot end mount 3D printed, and its bolted to the rail block. Nice and rigid and precise.
The build plate will also run on a single, larger, THK rail. I still need to design and make the support plate for the Mk3 heated aluminum plate and glass. It’s not going to be held together with cheesy binder clips. If needed, I’ll fit it with a pair of “outrigger” roller bearings and a pair of ground flat stock rails. I can’t detect any sideways rocking in the block when it’s on the rail, doesn’t mean there’s *not* a very little amount that would be magnified a few inches away at the edge of the platform.
Aiding in the endeavor are the lathes and milling machines I have, which make producing precisely round, straight, parallel or perpendicular cuts very easy.
Studying many of the existing 3D printers has shown me things to NOT do, like supporting the build plate and/or hot end rail from one side. If you’ve seen a Solidoodle II in operation, you can *see* it wibble and wobble.
I’ve worked on cars since I was in my single digit years in the 1970’s, and have done and do many varied other things which in their myriad ways work into one another to where I work in my head in 3D as though I’m cutting, shaping, filing, hammering, casting etc. When I build a thing, I’ve already run through many iterations internally so I pretty well have it down as to what I need to do the first time. That doesn’t preclude making changes on the fly.
Other times I just take materials at hand and go with it to fit to a task. This curly light bulb changer took me probably 5 minutes, the majority of the time waiting for the hot glue to cool. https://www.flickr.com/photos/27748767@N08/albums/72157635601530545 The inspiration? A burned out bulb over my bed and I didn’t want to have to shift a ton of stuff to move the bed to get a ladder in to climb to reach the bulb. Much easier to fit some cardboard to a new bulb, glue it to a scrap of PVC pipe then stand on the bed to R&R the bulb.
These two light saber hilts, 3, maybe 4 hours each. I don’t recall exactly since it was 10 years ago and I didn’t pause to take any in-progress photos. The grungy finish is intentional, and PVC makes a great substitute for Tauntaun tusk. ;) Pure serendipity that I had a length of zinc plated steel conduit that was the exact same OD as the ID of a piece of schedule 80 copper pipe. The emitters were made removable, with a hole through and a drilled blind hole inside the buttcaps so a ‘blade’ could be installed, though I didn’t make blades for them. I started with a rough idea on each then just let the ideas roll. https://www.flickr.com/photos/27748767@N08/sets/72157627785151078
If anything, it is the software engineering people who need to learn from the mechanical engineering people.
An excellent lecture on the topic:
https://www.youtube.com/watch?v=VfRVz1iqgKU
I think you meant that the other way around – the mechanical (and electrical) engineers need to learn a few things about software engineering. This was the objection that I had to the first article, that it completely ignored this fact.
And I’m saying that as an electrical engineer.
As a fellow electrical engineer, I would like to know the things you think we need to learn from software engineers.
Just as when software specialists think that hardware should be easy, and therefore make stupid mistakes based on wrong assumptions, the same goes for hardware engineers when they take on the software responsibilities, especially on one-man projects. Watch the video r4k linked for some examples of wrong assumptions in software design. Many of them boil down to incorrect assumptions that you can test software for every case. To paraphrase, software is not linear, and therefore you cannot assume that testing at the corners of the operating envelope assure correct operation at all points in between.
Also, most software does not come with specifications. You cannot know until you try it, whether software module “X” operating in operating system “Y” on CPU “Z” will meet your performance requirements for a given project. It’s not so bad with microcontrollers, since if you really want to know, you can analyze the compiled code (or write it in machine code) and count how many cycles a given function will take under worst-case conditions, at least for the critical loops. But once you step up to a multi-threaded CPU with virtual memory under an OS with a closed-source task scheduler and some set of concurrently running programs, the best you can do is demonstrate that in the final configuration you usually have plenty of CPU idle time and memory left on the system. That’s assuming you can even predict what the worst-case CPU load condition IS for your application.
Now mind you, this is all pretty much guesswork on my part – I’m smart enough to know when I don’t know something. I’ve done hybrid hardware/software projects in live video switching and streaming, and can tell you that I don’t know what the software is doing at any given moment. I can guess, but I really don’t know. Sure, I wrote the code, but I didn’t write the device drivers, the MPEG encoder, or many other library functions I used. So I compile it, run a system monitor to watch the memory and CPU usage, cross my fingers, abuse it with the worst usage cases I can think of, and go “yay” when it doesn’t get too close to running out of resources. Which as far as I can see it is equivalent to “putting a three kg assembly on an 8mm round rod” for the lack of knowing any better. For all I know, I’m going about it all wrong in a number of places.
And by the way, I think this is a big factor in why a number of hackers who promise they’ll distribute the source code for a given project, never seem to get around to it. Don’t ask me how I know this…
So yeah, this is why I think that hardware designers could benefit from a nice, long talk with software people.
Very good article
I think its mostly hobbyism vs professionalism.
as a hobbyist, you usually want the bare minimum to get out there and start getting your hands dirty. in most hobbies, we accept a very large monetary cost/ time cost trade off. whether you are doing something for the experience of doing it, or because you cant afford some gadget, you are doing so with the express understanding that you could shell out lots of money to buy one, or you could spend a lot of time and try your hand at doing it your self, hopefully spend a little less money and a lot lot lot more time.
the goals of hobbyism and professionalism are very different. certainly there are things the hobbyists can learn from the pros, but you dont need to turn them into professionals in doing so.
I would follow your blog, sir. Perfect summary of the friction on here.
You may have a point there. I guess for the hobby-people it really depends on what the actual end goal is. If you do it just to get something done as fast, simple and cheap as possible, hack away and don’t care about what the pros do might actually work (if you’re lucky). If you are however really interested in the engineering trade, why would you not try to aspire some professionalism and learn as much as you can about how to do something right? At least for the hobbys i know, it usually boils down to amateurs trying to aspire to as much professionalism as possible within theyr financial limits and the time they can devote to that hobby.
Nice article. Majority of people would probably not heed this, in essence engineer’s, advice. For me personally I find that I like to try stuff ASAP, and then debug (look into the book/internet) as I go along. Too much planning, obsessing over details, and computer design time hurts both my initiative and entushiasm, and my butt (sitting too much hurts).
I for one prefer to spend a little bit more time on the planning and studying phase, so that when it’s time to get my hands dirty I understand my stuff a little bit deeper
That is why you are an engineer. I’m not, and in my work I must often do ugly hacks because people want things done fast. It is still fairly safe and very reliable, but not pretty. OTOH, I do one-offs mostly.
I pretty much agree with everything in both articles, but this statement “You do [bring the cost closer to the raw material and time cost] by bringing more steps in house and running it on previously purchased capital costs.” From a cost-reduction standpoint, it pays to specialize. For most companies, costs are reduced by concentrating on their expertise and outsourcing everything else. You have to be careful not to take this too far, because the ultra-specialist is ultra vulnerable: you don’t want to be the engineering equivalent of a panda (eats bamboo better than everyone else, but only eats bamboo). However, if you try to bring things in house, you suddenly are confronted with the cost of maintaining a stable of engineers that can cover all the bases. Yes, when you need them, they come in handy, but when you don’t, you’re still paying for them. Next thing you know, you’re taking on projects unrelated to your core business because they will let you monetize all of those engineers you hired to bring everything in-house. Before long, you’re building towns in South America to house the workers (and their families) who harvest your rubber (see https://en.wikipedia.org/wiki/Fordl%C3%A2ndia )
Love the “learning steps” you delineated. I’d recommend, once one has a handle on the basics in steps 1-7, to go pick up a copy of Carroll Smith’s “Engineer to Win” and read the whole thing. It has everything from metallurgy and welding to suspension (kinematics) and aerodynamics. The sections on fasteners and bolting should be required reading for anyone trying to piece together a CNC or 3D printer. It has the massive advantage of being readable and conversational for those of us who didn’t get a Mech-E degree.
Ok, so where do I go to learn the stuff mentioned in your list? It’s not that I don’t know that that stuff is important, I have some knowledge of all of them already. But pretty much every source I’ve looked at to learn more assumes I’m trying to be (or already am) a mechanical engineer.
I guess we need to have a talk about what it means to have a talk. Several people have asked about resources for learning the stuff you mentioned, and not a single hint given. It looks more like you’re just grandstanding/bashing amateurs. Hopefully your third, fourth or fifth post in this series won’t be as one sided, there are plenty of us with a genuine interest in learning what we can about mechanical engineering in a practical amount of time.
Greg, sorry. I’m working on it. I don’t just want to list my text books because, well, I just paid a lot of money for them and have been trying to get what I can out of them whether they’re actually good or not. I’m doing a bit of research, and even ordering books to check out to give a better answer. Right now my favorite books are Machinery’s Handbook (any edition) and Quick Calculus, 2nd Edition. The first is dense like fruit cake and the second isn’t related to my list. I did like shigley’s mechanical design from school and the series of books by hibbeler called statics, dynamics, and mechanics of materials respectively.
I did try to give some keywords for google searches, and you can always hit up a local university and see what books they’re giving their engineers.
Okay, I looked up the books on my shelf and lo and behold, my engineering professors knew what they were going on about. Haha. So statics, mechanics of materials, and dynamics by hibbeler are all good books. Also Shigley’s is top notch. They were always my favorite books. I should’ve suspected. Find them used in hardcover. Publishers tend to take tables out of softcovers as punishment for not giving them all your money.
“Read mechanical engineering textbooks” sounds an awful lot like “become an mechanical engineer”. I’ve actually already tried this route, and that’s why I own the books “Mechanisms and Mechanical Devices Sourcebook” and “Machine Designer Reference”. I also own the “Machinery’s Handbook” because I also do a bit of machining. The first two are heavy on theory and math. Although I’ve managed to get some good info out of them there’s no way I could understand them without putting in the full effort (probably more) that a mechanical engineering student have to. It’s no secret that we’re all hobbyists here. In order for a reference to be helpful, it’s going to have to be practical as far as the amount of time required to absorb the information. Also, most of these textbooks, even used, are outside the price range for what a hobbyist could justify just to see if they can find them useful, especially if they have to buy 4 or 5 of them.
Machinery’s Handbook is a pretty good source of practical information, and is available somewhat reasonably priced used. But at 3000 pages, even if I read a few pages a day, it’d take 2-3 years to read it. I’d say recommend some sections that are important, but what I think is really needed is a more concise, less detailed source that covers the high points of most of the sections (because they all look important).
I have a BS in Computer Science and Mathematics from IU, so I consider myself ahead of the curve on the mathematics front compared to most programmers. But still, if I’m reading a book a section at a time, with pauses a few days, weeks, even months in between sections, it’s hard to even remember what variables they’re using for what, let alone actually understand and remember chains of concepts and equations built upon each other.
If you’re a mechanical engineer, I doubt a book that hobbyists will find useful exists on your bookshelf. Just as you won’t find an introductory programming book on mine.
Brilliant article. Thank you Gerrit! A few things in there that really made me think :)
This problem goes both ways when you have a project that combines design work in multiple disciplines.
Back in the 1980s I was working as a engineering technician, building prototypes of electronic devices designed by mostly mechanical and civil engineers. One project was a beautifully designed loading frame that could exert several thousands of Kilograms force on the test sample with no measurable deflection . This was in the days before desktop computers and inexpensive data acquisition systems, so most test measurements were done with chart recorders of some kind. The engineer in charge of the project needed a 24 to 48 hour ramp signal to drive one axis of a X-Y-Y recorder. He checked his books and found to generate a ramp you could use a capacitor and constant current source. Then spending several days looking up parts, he sent me his design and parts list for his project. All that would be needed was a 1.6 Farad capacitor and an adjustable pico-amp power supply. Total cost about $500 and would be about 1 foot square. I sent him back a 2″ square perf-board with a 555 oscillator, a couple of CMOS counters and some resistors in a R1-R2 network to make a simple DAC. Cost about $5.00.
Any time you are involved in a design that combines anything that you are not familiar with, it can really save a lot of time and money talking to someone that is more familiar with that discipline.
Two for the list.
1) Regarding vectors. Do learn a little about multiplying them. Torque is a vector cross product.
2)) Stress versus strain. Know why a hot bead set on a sheet of cold glass does nothing but a cold bead on a sheet of hot glass can cause it to shatter.
Since we are talking about the Apple iPhone cost it is apparent that they design products to meet a release date. The bitterness of poor quality lingers long after the joy of having met schedule has been forgotten. This fact is obvious based on the antenna screw-up on the IPhone. This was basic antenna design and any good design review or for that matter testing should have revealed this flaw. I believe the problem was known but ignored based on cost and schedule in the hopes that nobody or few people would notice. Although the article is good no risk analysis was mentioned.
They learned the hard way that when you sell millions of devices, someone is going to notice.
They didn’t learn from the alarm clock not working? I guess i answered my own question.
Great article, but help us move in the right direction…
Any book recommendations? Something like “Practical Electronics for Inventors”, but a mechanical version. Something that explains what a beam table is and how to use it? Uni lecture notes?
And what about affordable experimental kits? It’s hard to experiment when none of the odds and ends fit together. Buying parts to experiment with linear motion can be expensive, especially when you buy the wrong thing.
I think it’s called mechano ;)
System Admins would be great to this discussion if they could put down their hate for End-Users, Developers, Designers and everyone else. But no matter what they say people don’t listen.
Do you want the back-up tapes replaced? We’ve swap and run all of them down 100 times plus already? It’s been 10 years since anyone has done any checks on them. “Do you know about Beta-Max? Because this is what happens when you ignore Backups.” Yes. All Sys Admins get hostile and autistic about their systems. Considering their pay-checks are tied to those machines.
“Hard-drives having been running idle for 3 years at the same 20% I/O? And you want to use that space to now replicate a development database that will take up the remaining 60%? Yes, We just said 60% percent. I don’t have to run a S.M.A.R.T. report on the health on all the drives. We did that last month. These aren’t cars if you drive them slower they won’t get worn out so fast. Who is WE? Any and all Sys Admins worth their salt that aren’t quivered idiots will tell you the truth.” Yes, good Sys Admins are blunt, callus and judgmental toward any changes in Environments.
I taught my late teens POC (Proof Of Concept) when they were beginning a business venture of theirs. It’s served them well. Saved them a lot of heartache. The beauty of POC is it spans both software and physical engineering disciplines. There’s no harm in trying something out on a very small scale. Even failure leads to valuable knowledge..
“This is the other big thing I harped on was the tendency for amateurs to pass around a design as good. Pretty much no one disagreed on this with me. Just because it works doesn’t mean it’s good.”
Allow me to oblige then. Actually, it does. There’s a fairly well known saying in aviation according to which “any landing you can walk away from is a good landing” and that’s exactly the point. Obviously nobody _wants_ to wreck a plane on each landing, and whenever one has the dispensable resources to do it, improving things into better things is always a great idea; but ultimately, anything that does work _is_ always “good enough”. Anything more is bonus, _if_ you have an actual need for it and can actually afford the cost of “better”.
Thank you for expressing the viewpoint of the entire Chinese knock-off industry.
Yeah, “it works” is good enough, as long as:
a) You don’t care how long it works,
b) You don’t care if it works under all expected operating conditions,
c) You don’t care if it actually does what it’s meant to do,
d) You don’t care about anything but development cost and build cost.
I think I’ll pass on taking any flights with you.
It’s any landing is a good landing if you can still yes the plane, any landing you can walk away from is a spectacular
landing.
Love it! Here’s a couple to add to your list of specific to-do’s for better understanding mechanics:
#0. General familiarity with basics of tool use, manufacturing methods, and commonly used off the shelf parts. (I.E. survey 100% of McMaster Carr’s online catalog so you are aware of the existence of, say, different types of fasteners so you don’t order a custom shaft with threads if a shoulder bolt would have sufficed.)
#2 continued: How to draw a Free Body Diagram and how to distinguish between internal and external system forces so you can calculate the net effect of all relevant factors at play.
#8. Degrees of freedom and how to use the theory to prevent over/under constraint of parts within assemblies and ensure that parts are designed with adequate locating & fastening features appropriate for the material and mfg method. (I.E Lasercut edges of sheet metal are strong locators, but as soon as you add a bend the margin for error goes way up.)