A Bit of History

I’m now a month into my new journey as VP Business Development at Dyndrite - I thought I’d share my thoughts on why I joined, what I believe, and why I believe this emerging company is quickly becoming a cornerstone of the AM industry.

I have worked in software development and management for over 20 years in a variety of positions, from the early days of web development and back-end server operations, through to managing a software development group of ~200 developers engaged on a multitude of metrology, healthcare and Additive Manufacturing (AM) software projects at a major OEM.

I first began to work with metal AM systems and software around 2013. We identified that our new machine development efforts were slowed due to insufficient access to, and dependence on, third party build preparation software. Naturally, systems engineers worked around these issues by developing their own R&D test harnesses, built on existing internal infrastructure. As these test harnesses extended to include new customer requests the software inevitably and gradually escaped into wider use; first by internal applications engineers and ultimately by early adopter end-users. More importantly though, this set us on a diverging development path from the ISVs who traditionally had provided build preparation, slicing and toolpathing, particularly as we began to adapt slice file formats to contain settings uniquely required to support our new printers.

Our accelerated new hardware development speed, coupled with the need to protect IP, caused further difficulties with integration of new requested features with our ISVs, and ultimately led to a decision to develop our own build prep, slice and tool pathing software focused on our machine processes. This gave us incredible freedom to develop optimised workflows, but ultimately came with a price.

Our first product release was built really fast and incorporated a number of unique features including: an open material properties editor to enable customer Design of Experiments (DOE) studies to be completed in a fraction of the time, as compared to other systems; a slicer that allowed users to hop around in the build height to begin the slicing process in areas that they regarded as potentially problematic and a highly capable support editing tools. With an extensible API architecture and a new stripped-down GUI focused on ease of use, without any unnecessary menus or legacy features. THis led to a package that  was a delight to use, nimble and easy to learn. Upon release in 2014-2015 it was, and still remains, highly acclaimed.

Unfortunately, while this approach appeared successful, its cost was by no means insignificant. With well over 100 developer years invested, never mind the ancillary services: project management, testing, I.T. infrastructure and maintenance of software development systems, the Operational Expenditure or OPEX to build such a product is, to put it mildly, is substantial!

Further, we created a support and maintenance burden far beyond what was imagined when version 1.0 was released. For sure, scheduling in new features is still easier than asking an independent third party developer to do it, but with an ever-more complex product and ever-expanding list of functional requirements, refactoring the code base still causes scale and scheduling issues and agility suffers.

In short, ensuring our development freedom came with the high price tag of building and maintaining a substantial software team which wasn’t the core focus of our business as a machine OEM.

What we had to do is a decision many OEMs are forced to reckon with.Until recently there have largely been three software options for AM OEMS:

1.     Build and support your own software stack. The advantage is control, speed and protection of IP. The disadvantage is the heavy cost of development- particularly problematic if the software is not part of your core product differentiation as you are employing costly experts in areas that are not core to your bottom line.

2.     Rely on an existing ISV. The advantage being you don’t need to build out your own tool and team. Disadvantages include: Concerns over sharing IP, and possible leakage, heavy license and added cost and maintenance for your customers, coupled with not being able to control ISV development direction, nor take advantage of latest technologies. You’re in their hands, or ultimately in the hands of your competitors - if they are more valuable to the ISV.

3.     Rely on free or open source software. This is an attractive option, particularly for startups. But often the solutions are sub-optimal and don’t keep pace with new product development. Plus can you rely on it being around in a few years and what’s the support like? Very often start-ups following this path soon find they need to redevelop their code and add programmers. This again can be cost prohibitive, and often leads to sliding into option one.

Moreover, with additive machines becoming ever more powerful these models look increasingly fragile. Like other 3D and CAD tools, AM software, built on antiquated geometry kernels have not kept pace with AM hardware. Build preparation and slicing takes way too much time, hours to days in some cases - and is expected to worsen as build sizes get larger and larger.

Build preparation software is crucial to additive manufacturing. OEMs rely on it as a data on-ramp to their machines. Unfortunately, as outlined above, the options currently available either require tons of cash, delays in product or feature commercialization, or IP vulnerability.

Additionally, OEMs relying on option 1 are creating increasingly isolated systems incapable of integration with others while forcing customers to run a plethora of software tools if they use different machines. This is unacceptable for agile, digital manufacturing and is preventing wider adoption of AM in general manufacturing.

Similarly, manufacturers following option 2 are slowed in their ability to use new compute technologies - they’re reliant on older software architectures and can only run at the development speed and direction of their chosen ISV. As with option 1 this is a bottleneck to wider adoption of AM as it decreases choice and agility.

For those following option 3 this may work for a time - but often such reliance on free tools do not scale as you try to build product differentiation. Again, like option 2, even with an open source you are often limited by the development communities’ direction of travel, enthusiasm, ability to support and maintain.

The bottom line is, additive systems are set to become ever more complex - Machines are getting more “multi” (think multi-laser or multi-print head) leading to increased tool path complexity. There is an  increased requirement to continuously vary machine parameters throughout the build to hit tolerances, ensure material condition or hit certain aesthetics. More and more machines are being fit with measurement sensors leading to the need to process, evaluate and analyze data, sometimes during a build. There’s a growing requirement to interface build prep with simulation in order to analyze expected stress effects, particularly on metal builds. Finally, and what is likely a game changer for the industry, requirements to create end-user-specific functional workflows (a.k.a. rules or recipes) to allow individual manufacturers to automate and serialize their production.

I’ve spent over 20 years at one of the leading metal additive manufacturing OEMs, building software solutions to empower customers. I’ve faced the same three options now faced by similar OEMs across the industry.

So is there a better way to go?

Thankfully there is now a fourth option for the AM industry and that is Dyndrite….

Stay tuned for some exciting new announcements.