Read on to learn how different factors influence the strength of 3D printed parts and what you can do to improve the strength of your prints.

How Strong Are 3D Printed Parts? A Comprehensive Analysis

<h2 id="isPasted">Some Historical Perspective</h2>The relationship between physical engineering and the programmable computer is as old as the computer itself. The reality is that, for most of us, crunching lots of numbers by hand is frustrating, time-consuming, and error-prone.The British government of the 1820s agreed, opting to fund the early development of Charles Babbage&#39;s difference engines. These were visually striking machines: large mechanical computers, some capable of solving 7th order polynomials, that were intended to dramatically reduce the cost of production of tabulated trigonometric and logarithmic functions &mdash; the kind that were incredibly useful to scientists, engineers and navigators in the immediate aftermath of the Industrial Revolution.Fast forward to 1945, and we see the first glimpse of modernity: ENIAC, the world&#39;s first programmable, electronic, general-purpose digital computer. If you&#39;re curious as to what was it designed for, the answer is the computation of artillery and mortar firing tables; a task that involves exactly the kind of Newtonian mechanics calculations that will be familiar to any undergraduate mechanical or aerospace engineering student (see: Mayevski&#39;s <a href="https://books.google.co.uk/books/about/Trait%C3%A9_de_balistique_ext%C3%A9rieure.html?id=jE_zAAAAMAAJ&redir_esc=y" target="_blank">Trait&eacute; de balistique ext&eacute;rierure&nbsp;</a>, or the US Army Ballistic Research Laboratories&#39; <a href="https://asset-pdf.scinapse.io/prod/77299953/77299953.pdf" target="_blank">The Production of Firing Tables for Cannon Artillery</a>).Just a decade or so after ENIAC, IBM drew up its first specifications for a new programming language, The IBM Mathematical Formula Translating System, familiar to many of us as FORTRAN. Developed expressly for science and engineering, FORTRAN is a true titan of the scientific computing world. If you&#39;ve ever fired up MATLAB, analysed a load-case with an <a href="https://en.wikipedia.org/wiki/Finite_element_method" target="_blank">FEA</a> package, or run some new geometry in <a href="https://en.wikipedia.org/wiki/Computational_fluid_dynamics" target="_blank">CFD</a> &mdash; then it&#39;s almost certain that FORTRAN is involved in that stack somewhere, even six or seven decades on.<hr><h2 id="isPasted">Why Software Matters For Hardware</h2>The advantages of using digital computers in the physical engineering disciplines are both marked and multifarious, and I hope somewhat obvious.At a low level, these advantages can be quite straightforward. They include things like providing engineers with the ability to perform large numbers of calculations with little to no risk of human error. Think of something like repeated matrix multiplication, perhaps as part of a kinematics problem. How confident would you be in getting every step of that calculation right, without accidentally picking up a value one row down or one column across from where you intended? Thankfully, with the help of a few lines of FORTRAN, MATLAB, or Python, the computer can perform these calculations on your behalf, perhaps billions of times, without the threat of inconsistency or human error. At least... <a href="https://en.wikipedia.org/wiki/Pentium_FDIV_bug" target="_blank">almost all of the time.</a>At a higher level, however, these advantages are even more pronounced. They are the culmination of decades of work across several disciplines; the output of engineers, scientists and mathematicians who have designed, implemented, and shared computational techniques that address a myriad of challenging problems &mdash; from solving partial differential equations at scale, enabling modern FEA and CFD, through to the development of boundary representation solid modelling techniques that enable modern CAD systems. The convergence of these technologies has revolutionised engineering; accelerating development cycles, reducing the need for physical testing, and helping the world&#39;s engineers improve the quality and performance of everything from ships to spacecraft.As an illustration, think of the draughting process. For many engineering professionals who started their careers prior to the 1990s, draughting work would have still involved a drawing board, pens, and paper, cellulose, and/or linen. In the event of a mistake, the draughtsperson would have had to break out the scalpel or Tipp-Ex to &#39;erase&#39; the error, or issue an entirely separate drawing amendment to be paired with the original documents. With modern CAD systems, minor drawing modifications completed prior to release go completely unnoticed, and subsequent amendments can be as simple as a quick tweak and a brief change order &mdash; no redrawing of anything, no folder of amendments.<img src="https://images.wevolver.com/eyJidWNrZXQiOiJ3ZXZvbHZlci1wcm9qZWN0LWltYWdlcyIsImtleSI6ImZyb2FsYS8xNjg1NTI3MDQ5MjY0LUhXRHJhd2luZ09mZmljZS5qcGciLCJlZGl0cyI6eyJyZXNpemUiOnsid2lkdGgiOjk1MCwiZml0IjoiY292ZXIifX19" style="width: 300px;" class="fr-fic fr-dib"><figcaption id="isPasted">The Harland &amp; Wolff Drawing Office, Belfast, at some point during the 1960s or 1970s. My father served part of his apprenticeship in this room a decade or two later. Maritime Belfast/National Museums Northern Ireland</figcaption>Better yet, imagine the difference in resource requirement and development cycle times for something like a turbocharger. If every minor tweak to blade or housing geometry requires an entire manufacture, assembly, and balancing routine before the new design makes it to the gas stand, every iteration will fall weeks behind and cost significantly more to explore than its simulation-driven counterpart &mdash; where a design change could make it to CFD in a matter of minutes. This is before we even consider the introduction of something like mathematical optimisation into this loop, where the responsible engineer could define their objective function, their variables, and their constraints, and conceivably let the computer play tunes with the geometry, feed that into the simulation, interrogate the results, then rinse and repeat until it reaches an optimum. Ultimately, well correlated models, <a href="https://en.wikipedia.org/wiki/All_models_are_wrong" id="isPasted" target="_blank">even if wrong</a>, are incredibly useful.<hr><h2 id="isPasted">Why Hardware Matters for Everyone</h2>So computers are wonderful tools, and so are the niche software packages we run on them, but so what? Well, I believe we now find ourselves at a critical point in both the trajectory of engineering as a discipline, and in its utility as a mechanism for improving our lives as a species. We have a lot of *very* active engineering fields right now, with a lot of important problems to address &mdash; and in the end, at some point, somebody has to actually make stuff to make things better.For example, it seems to me that we are standing but a few feet forward of the starting line in a new, privately funded space race. We have seen SpaceX engineers repeatedly achieve nothing short of a triumph of control engineering: reversing a rocket onto a barge in the ocean, opening the door to reuse, and as a result, both dramatically reduced space access costs and dramatically increased launch cadence. We have companies like SpinLaunch working to yield orbital access mechanisms that help escape <a href="https://www.nasa.gov/mission_pages/station/expeditions/expedition30/tryanny.html" target="_blank">the tyranny of the rocket equation&nbsp;</a>.We have a burgeoning paradigm shift in personal transport, with electric cars, scooters, and e-bikes encroaching further and further on the internal combustion engine&#39;s long-established territory.We have additive manufacturing evolving into a serious, cost-competitive manufacturing technique that can achieve geometries beyond the reach of traditional subtractive approaches, and we have generative design technology helping engineers produce mathematically optimised, often organic-looking solutions to pressing design problems. To see the power of these two in concert, just look at <a href="https://www.czinger.com/" target="_blank">Czinger</a> and <a href="https://www.divergent3d.com/" target="_blank">Divergent</a>.And, of course, we have ever more compelling incentives to overhaul the majority of our civilisation&#39;s energy infrastructure, pushing us to diversify the means by which we generate electricity, fostering the development of improved wind, solar, and &mdash; I hope &mdash; nuclear technologies.In short, we&#39;ve got a lot of real-world engineering to tackle, and plenty of hardware to build.<hr><h2 id="isPasted">Software is Eating the World</h2>Ultimately, it strikes me that the way in which we develop the physical systems around us is changing, and not all our tools yet accommodate this.Despite the arrival of an entire range of engineering software systems in the latter part of the last century, these were typically specialised products, often designed to form improved but effectively like-for-like replacements of an existing way of accomplishing a given task, whether that was replacing the draughtsman and his drawing board with a CAD workstation, or replacing a complex, <a href="https://twitter.com/CalumDouglas1/status/1550594001874698246" target="_blank">stiffness-altering oil pressure measurement apparatus&nbsp;</a>around a bearing with a CFD case.As a result, we find ourselves at a point where, as a profession, we&#39;re equipped with some extremely impressive tools; tools that can help us build the shorter iterative loops that are required to yield accelerated system development.However, it feels like we&#39;re still using these revolutionary tools, developing the technology that is critical to our species&#39; future, inside an operational framework that was designed for slide rules, drawing boards, and row after row of draughtsmen packing a tobacco smoke filled drawing office.Our systems are heavily siloed, our teams often fragmented. We struggle to collaborate across teams, sites, and time zones. We have vast and unstructured knowledge bases that are full of effectively undiscoverable data, put beyond the reach of those who don&#39;t know exactly where to look. And we struggle for visibility &mdash; of tasks, responsibilities, upcoming changes, and most importantly, of our data.Even the big players recognise this. Dassault push <a href="https://discover.3ds.com/reduce-non-value-added-work" target="_blank">research</a> that shows engineers spend 34% of their time performing &#39;non-value-added&#39; work; dominated by the amount of time spent just looking for stuff, trawling through network drives and cluttered inboxes. This same research shows that engineers are typically working with outdated information 20% of the time &mdash; imagine a full day a week, every week, for every member of your team, just being thrown away because of bad input data. This pattern has to change.In fact, for newer hardware companies, I think some things have *already* changed. <a href="https://a16z.com/2011/08/20/why-software-is-eating-the-world" target="_blank">Software is eating the world&nbsp;</a>applies not only to the electronic control of fuel injectors and ignition coils, but to the adoption of software-like management practices, with a focus on short design-build-test loops. I may hate the confusing, jargon-heavy nomenclature of &#39;agile&#39; methodology, but there is some method in the madness.<hr><h2 id="isPasted">Better, More Collaborative Software for Engineering Teams</h2>The future that I see is one where we not only have specialised tools for specific parts of the engineering cycle, but we have a central, engineering specific hub; an operating system that ties these things together.We want to see the world&#39;s physical engineering teams build better products faster; to achieve shorter development cycles, to iterate faster, and to better leverage their internal knowledge &mdash; so that they can achieve their goals, whether that&#39;s kinetic launch, faster cars, or greener energy.We think this will be brought about by transforming how hardware teams communicate, collaborate, and manage technical knowledge. That means better, more connected software; software that focuses on resolving the productivity-killing shortfalls in current engineering process. We think hardware teams should have technical communication mechanisms that are fast, painless, and traceable; that allow new hires to find the information they need, without requiring someone else to go rooting through their inbox for half an hour. We think engineers should be able to see what colleagues are working on, how these items are prioritised, and what&#39;s coming next. We think engineers should be able to annotate drawings, share calculations and schematics, and offer opinions on proposed solutions &mdash; all in real-time, wherever they are, with all that data stored and indexed for easy discoverability down the line.&nbsp;Above all, we think engineers should have a single source of truth to work with; a repository of version-controlled design values, simulation outputs, and performance targets &mdash; whether those are scalar values, or n-dimensional maps.In the end, what we want to see is engineering teams moving beyond the pain of e-mail ping-pong with spreadsheets and presentations, to stop scrawling performance differentiating IP over paper drawings that are destined for the shredder, and to start letting the computers handle the busywork.

Betty Jean Jennings and Fran Bilas at the main ENIAC control panel. Moore School of Electrical Engineering. U.S. Army, ARL Technical Library Archives

The recent history of our physical engineering disciplines is intertwined with computing. The future is too. 

The Future of Hardware is... Better Software

<h2 id="isPasted">Quick Wins</h2>We&#39;ll be looking at three items here that should be broadly universal across any Mechanical Engineering function, and should also be applicable to other disciplines. Our objective is to highlight some minor changes in workflow that can offer a significant benefit for your team. Taking these in order...<hr><h2 id="isPasted">1. Drawings: Datum Tables</h2>This is something I started doing several years ago to combat my own frustration with trying to read other people&#39;s drawings, and I was always surprised that it wasn&#39;t a standard practice in any of the design departments I&#39;ve worked in.Picture the scene: one of your colleagues has just finished off the drawings for a new cylinder head, and they pass them to you for peer review. If your brain works anything like mine, the first things you want to check are all the major datum features. However, when a drawing pack runs to six or seven substantial pages, this turns into a less entertaining, more time-consuming, monochrome version of Where&#39;s Wally? &mdash; which isn&#39;t really what we&#39;re after.For me, the fruit doesn&#39;t hang much lower. Work up a table&dagger; that lists datum features in alphabetical order, list their sheet, list their grid reference, then place the table somewhere easy to find on the drawing. Anyone else lifting the drawings will be able to dive right into reading the important bits, without having to scour the thing for ten minutes before they start actually thinking about the task at hand. This can as simple as Table 1.<img src="https://images.wevolver.com/eyJidWNrZXQiOiJ3ZXZvbHZlci1wcm9qZWN0LWltYWdlcyIsImtleSI6ImZyb2FsYS8xNjg0MjI1NDYxMjE1LVRhYmxlSW1hZ2UucG5nIiwiZWRpdHMiOnsicmVzaXplIjp7IndpZHRoIjo5NTAsImZpdCI6ImNvdmVyIn19fQ==" style="width: 766px;" class="fr-fic fr-dib">Table 1 &dagger;If you&#39;re so inclined, I also imagine that it should be possible to implement automatic table assembly with a little bit of code. From memory, when I last explored this with CATIA v5 macros, I couldn&#39;t find any reference to datum objects in the object model documentation.<hr><h2 id="isPasted">2. Excel: Named Ranges</h2>As the sort of engineer whose professional home lies in writing code to analyse, simulate, and control physical systems, this point is much closer to my heart. With a few notable use-case exceptions, such as its easily accessed optimisation tools, I basically hate Excel. I consider it to be like the adjustable spanner of the software world: it might work for the task at hand, but it&#39;s still the wrong tool for just about every job.I believe that Excel inadvertently pushes people to construct terribly organised models and analyses that are often borderline unintelligible, and that building a clean solution in Excel requires the adoption of some very considered practice that you would basically get by accident if you did this work in any one of MATLAB, Python, Julia, Fortran etc. &mdash; the list goes on.More specifically, when I&#39;m forced to unpick somebody else&#39;s Excel-based model or analysis, there is one overwhelmingly common piece of practice that makes me want to tear my hair out: an overflowing formula bar, brimming with unnecessary parentheses and mysterious references to <code>!Sheet2&nbsp;</code>and <code>$C$907</code>. Let&#39;s take a real-world example of how unnecessarily messy this can get, even for relatively simple cases, then we&#39;ll move onto cleaning things up.<h3>The Problem</h3>The simple example case I&#39;m going to give here will be familiar to anyone who&#39;s ever designed an engine, a gas strut, or a (hydro)pneumatic suspension system: computing gas pressure in a cylinder of known volume. We&#39;re going to use the <a href="https://en.wikipedia.org/wiki/Van_der_Waals_equation" target="_blank">Van der Waals equation of state,&nbsp;</a>owing to the fact that the ideal gas law is pretty rubbish at approximating the behaviour we&#39;d typically see in any of these systems. The Van der Waal&#39;s equation of state is given by:<img src="https://images.wevolver.com/eyJidWNrZXQiOiJ3ZXZvbHZlci1wcm9qZWN0LWltYWdlcyIsImtleSI6ImZyb2FsYS8xNjg0MTY3MzEzOTIyLUVxMS5wbmciLCJlZGl0cyI6eyJyZXNpemUiOnsid2lkdGgiOjk1MCwiZml0IjoiY292ZXIifX19" style="width: 766px;" class="fr-fic fr-dib">For simplicity, we&#39;ll take the case for n moles of gas, so this becomes:&nbsp;<img src="https://images.wevolver.com/eyJidWNrZXQiOiJ3ZXZvbHZlci1wcm9qZWN0LWltYWdlcyIsImtleSI6ImZyb2FsYS8xNjg0MTY3MzQ0NzcxLUVxMi5wbmciLCJlZGl0cyI6eyJyZXNpemUiOnsid2lkdGgiOjk1MCwiZml0IjoiY292ZXIifX19" style="width: 766px;" class="fr-fic fr-dib">Where:<ul><li>P denotes pressure.</li><li>V denotes volume.</li><li>n denotes moles of gas.</li><li>R&nbsp;denotes gas constant.</li><li>T denotes gas temperature.</li><li>a denotes Van der Waals constant for intermolecular interaction.</li><li>b denotes Van der Waals constant for real gas molecule volume.</li></ul>In our example scenario, we can pretend that we&#39;re solving for pressure, with all other values known, so we can quickly rearrange as follows:&nbsp;<img src="https://images.wevolver.com/eyJidWNrZXQiOiJ3ZXZvbHZlci1wcm9qZWN0LWltYWdlcyIsImtleSI6ImZyb2FsYS8xNjg0MTY3Mzk1NTExLUVxMzQucG5nIiwiZWRpdHMiOnsicmVzaXplIjp7IndpZHRoIjo5NTAsImZpdCI6ImNvdmVyIn19fQ==" style="width: 766px;" class="fr-fic fr-dib">Equation shuffling out of the way, let&#39;s pluck some values from the air and get these plugged into a spreadsheet to see what we&#39;re dealing with. The values we&#39;re going with assume a 10cc volume, 20&deg;C, and enough pure nitrogen fill to generate approximately 86barA.<img src="https://images.wevolver.com/eyJidWNrZXQiOiJ3ZXZvbHZlci1wcm9qZWN0LWltYWdlcyIsImtleSI6ImZyb2FsYS8xNjg0MjIxMjQ5NDg2LVNjcmVlbnNob3QgMjAyMy0wNS0xNiAxMDA5MTYucG5nIiwiZWRpdHMiOnsicmVzaXplIjp7IndpZHRoIjo5NTAsImZpdCI6ImNvdmVyIn19fQ==" style="width: 766px;" class="fr-fic fr-dib">The typical quick spreadsheet setup leaves us with something that looks like this:&nbsp;<img src="https://images.wevolver.com/eyJidWNrZXQiOiJ3ZXZvbHZlci1wcm9qZWN0LWltYWdlcyIsImtleSI6ImZyb2FsYS8xNjg0MTY3NTAxNDA0LTIyMDUxOS0zUXVpY2tXaW5zLU5vTmFtZWRSYW5nZS5wbmciLCJlZGl0cyI6eyJyZXNpemUiOnsid2lkdGgiOjk1MCwiZml0IjoiY292ZXIifX19" style="width: 730px;" class="fr-fic fr-dib">In my view, this isn&#39;t the end of the world; all the referenced cells are close by, and I can pick apart the formula quickly &mdash; but you can already see that extension of this sort of pattern to something more complex will start to cause serious headaches. By the time you&#39;re working with something which has parameters spanning sheets and substantially more complex formulas in play, this method is a nightmare.&nbsp;<h3 id="isPasted">The Solution</h3>Thankfully, a better way forward here is entirely quick and painless: <a href="https://support.microsoft.com/en-us/office/define-and-use-names-in-formulas-4d0f13ac-53b7-422e-afd2-abd7ff379c64" target="_blank">named ranges.&nbsp;</a>Named ranges effectively allow us to assign variable names of our choosing to these parameters, while also allowing us to configure the scope of the variables, i.e., whether they are visible only on a given worksheet, or whether they&#39;re global across the workbook.Setting a named range on a single value is as easy as clicking the cell in the top-left corner that currently shows cell address, overwriting it with an appropriate value, and hitting enter. There are plenty of other websites that explain how to use the &#39;Name Manager&#39; tools and get the most out of named range usage, but I&#39;ll just show you how much cleaner things look once you&#39;ve converted cell addresses to named ranges:<img src="https://images.wevolver.com/eyJidWNrZXQiOiJ3ZXZvbHZlci1wcm9qZWN0LWltYWdlcyIsImtleSI6ImZyb2FsYS8xNjg0MTY3NTI3MDI2LTIyMDUxOS0zUXVpY2tXaW5zLU5hbWVkUmFuZ2UucG5nIiwiZWRpdHMiOnsicmVzaXplIjp7IndpZHRoIjo5NTAsImZpdCI6ImNvdmVyIn19fQ==" style="width: 766px;" class="fr-fic fr-dib">At least to my mind, this is an immediate and significant improvement. Compared with how it was previously, it is now substantially more straightforward to compare the formula with our target equation above. Any misplaced brackets or indices that might otherwise cause some serious pain to review or debug can now be caught much more readily, and you can move forward with increased confidence that your spready is trustworthy.<hr><h2 id="isPasted">3. Files: Naming Convention</h2>Finally then, the best (and shortest) tip: file naming convention. As far as I&#39;m concerned, there is precisely one correct way to name the sort of files generated by most engineering operations, and that way is as follows:<ul><li><code>YYMMDD-FileName.ext</code></li></ul>For example, the file in our named range scenario might be called something like <code>220519-NamedRangeExample.xlsx</code>.By placing the date at the start of the filename, and by following the <a href="https://en.wikipedia.org/wiki/ISO_8601" target="_blank">ISO8601</a> date component order, lexicographical sorts will yield files in chronological order, irrelevant of when they were copied to the particular directory.Then, by adopting dashes instead of spaces, underscores, or whatever else you might fancy for separation of sections of the file name, you&#39;re making the decision up-front that you simply want to avoid any funnies with respect to how filenames are handled.For example, any files appearing at a web URL will have spaces substituted for <code>%20</code>, which isn&#39;t exactly readable, and underscores can cause issues with both certain platforms and certain indexing systems.&nbsp;

mechanical design

Latest Posts

How Strong Are 3D Printed Parts? A Comprehensive Analysis

The Future of Hardware is... Better Software

3 Quick Methods Wins for Mechanical Engineering Teams

Profiles