3 Quick Methods Wins for Mechanical Engineering Teams

Quick Wins

We'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...

1. Drawings: Datum Tables

This is something I started doing several years ago to combat my own frustration with trying to read other people's drawings, and I was always surprised that it wasn't a standard practice in any of the design departments I'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's Wally? — which isn't really what we're after.

For me, the fruit doesn't hang much lower. Work up a table^† 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.

Table 1

^†If you'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't find any reference to datum objects in the object model documentation.

2. Excel: Named Ranges

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'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. — the list goes on.

More specifically, when I'm forced to unpick somebody else'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 !Sheet2 and $C$907. Let's take a real-world example of how unnecessarily messy this can get, even for relatively simple cases, then we'll move onto cleaning things up.

The Problem

The simple example case I'm going to give here will be familiar to anyone who's ever designed an engine, a gas strut, or a (hydro)pneumatic suspension system: computing gas pressure in a cylinder of known volume. We're going to use the Van der Waals equation of state, owing to the fact that the ideal gas law is pretty rubbish at approximating the behaviour we'd typically see in any of these systems. The Van der Waal's equation of state is given by:

For simplicity, we'll take the case for n moles of gas, so this becomes: 

Where:

• P denotes pressure.
• V denotes volume.
• n denotes moles of gas.
• R denotes gas constant.
• T denotes gas temperature.
• a denotes Van der Waals constant for intermolecular interaction.
• b denotes Van der Waals constant for real gas molecule volume.

In our example scenario, we can pretend that we're solving for pressure, with all other values known, so we can quickly rearrange as follows: 

Equation shuffling out of the way, let's pluck some values from the air and get these plugged into a spreadsheet to see what we're dealing with. The values we're going with assume a 10cc volume, 20°C, and enough pure nitrogen fill to generate approximately 86barA.

The typical quick spreadsheet setup leaves us with something that looks like this: 

In my view, this isn't the end of the world; all the referenced cells are close by, and I can pick apart the formula quickly — 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're working with something which has parameters spanning sheets and substantially more complex formulas in play, this method is a nightmare. 

The Solution

Thankfully, a better way forward here is entirely quick and painless: named ranges. 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'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 'Name Manager' tools and get the most out of named range usage, but I'll just show you how much cleaner things look once you've converted cell addresses to named ranges:

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.

3. Files: Naming Convention

Finally then, the best (and shortest) tip: file naming convention. As far as I'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:

• YYMMDD-FileName.ext

For example, the file in our named range scenario might be called something like 220519-NamedRangeExample.xlsx.

By placing the date at the start of the filename, and by following the ISO8601 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'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 %20, which isn't exactly readable, and underscores can cause issues with both certain platforms and certain indexing systems.