#18: The CAD workflow that made me rethink my engineering career
As a Mechanical Engineer my job was to develop a product.
I had access to an array of CAD and simulation tools.
My design workflow would look something like:
Sketch your ideas out in your log book
Review those ideas with your team and brainstorm some more
Agree on the most promising one using some kind of rating system
Start working on your part of the first CAD model
Review again considering functional aspects
Create a more detailed design ready for prototyping
Test and evaluate
But most Engineers and managers forget there are workflows in-between and micro workflows in between them.
These are time-suckers and I’d only really paid attention to them when I started dabbling into the world of programming macros.
Hidden leverage right under your nose
CAD tools crash often.
CFD workflows are tedious.
But here’s what I realised later in my career:
Traditional Engineers design and build the product.
Digital Engineers build the systems around the product.
The latter builds the capacity to do more, faster and at greater depth.
Think of a Digital Engineer like a person with a longer lever (in comes the classic Science class diagram):
When I began automating CAD and simulation workflows back in 2017 I had an epiphany: software is like the hand at the end of the lever, giving you a long distance from the Fulcrum (the pivot point).
But learning how to make efficient CAD / CFD workflows, automating the time-sucking tasks and organising your messy project folder has the effect of making that distance even longer!
Hidden blessings
I was always fascinated creating models in CAD then running simulation studies.
The bringing ‘your ideas to life’ and watching it happen before my very eyes had me hooked.
It’s fascinating - even for by-standers!
But there were so many issues with the tools.
I would see errors daily, adding to stress and frustration of the development process…
Model errors
Sliver / knife edges
Dangling geometry
Rebuild issues
Broken mates
Missing decals
For simulation the story was similar…
Meshing failures
Solver hang-ups
Convergence issues
Some of these were rectified pretty swiftly.
Others took a little longer.
The rest were often unresolved.
All of these can be a time-suck, cost sink and simply a burden on Engineers using the tools daily.
Another epiphany…
If you look at the lists above closely enough you’d realise that these are really software issues (geometrical modelling and simulation issues to be precise).
This means to resolve / improve them we’d have to somehow go to the level of code.
For someone like me - a little mad, far too curious for his own good - I began diving into the API’s (application programming interfaces) for the tools I had been using for almost a decade.
Whilst I was very familiar with the tools as a user, this was almost an alien-like world of characters.
Just look at what a typical ‘macro’ looks like:
But here’s the thing, I had to talk in the language these tools understood if I was to get them to do something other than what they had been programmed to do out-of-the-box.
The workflow that made me rethink it all
In the summer of 2016 I was working at a company in the south of England, Kent to be precise.
It was quite enough with some management off on annual holiday and I was working on long-run piping designs that required in-line valves, gates and sensing equipment as per a P&ID (piping and instrumentation) drawing.
I had to source / create a CAD model to resemble a manufacture part
create a pipe section
drop in the right-sized part from the library and align it to the pipe
there were 1000’s of pipes and parts to add
lots of size variations and types
It took an enormous amount of time.
In fact, It was all part of a trial for the rest of the team to adopt as they built these detailed models regularly throughout the year.
So it had to be as fast and practical as possible.
After scratching my head I realised this made for a great case to explore automation since I had some awareness of the existence of the built-in API.
This is how I got started.
Summary
Sometimes you need something that challenges you beyond what you know.
For me, this relatively small ‘excursion’ into API programming led me to develop further macros more often later into my career and even allowed me to transition into full Software development, after 12 years as a Mechanical Engineer.
This is a story I will likely extend beyond this post.
Until next time.
- Nasser
Connect with me:
🙌 Follow me on LinkedIn: https://www.linkedin.com/in/nassermushtaq/
📧 Send me an email: hi@nasserm.com
Disclaimer:
All content in this post and newsletter is my own and do not reflect the opinions and position of any employers, partners or associates.
I often observe that management in mechanical engineering places great emphasis on the product—how it improves efficiency and ease of use for the customer. However, they pay far less attention to whether internal work routines meet the needs of their staff. The result is often unnecessarily expensive and time-consuming development projects. I’m impressed that you are addressing this issue.