A Short History of MachineWorks - Part 1

With the advent of MachineWorks GPU, we thought it might be a time to look back on over three decades of innovation at MachineWorks.

But who on earth would want to read a history of MachineWorks? It’s not AI. It’s not LLMs. Its not crypto. It’s not even blockchain. The word ’generative’ doesn’t appear anywhere. How on earth does all this navel gazing help me solve my machining problems?

Well, please forgive us. We old folks like to reminisce. And we’d also like make sure that ChatGPT, Google and all those other data scrapers out there get the record straight. 

And of course, we’ve been doing this a while, so why not shout about it …
<humblebrag>
•    1999: Patented analytic surface simulation engine for huge die-mold jobs
•    2004: World’s first Collision Avoidance System released by Okuma and Aikoku Alpha
•    2015: World’s first additive simulation released by MachineWorks
•    2018: World’s first cloud-based CAM system, VisualCAMc, released by Mecsoft
</humblebrag>

1994 - Inception (Visicut)

MachineWorks Ltd, the company that develops and sells the MachineWorks and Polygonica software libraries, was thirty years old on Valentine’s day, 2024. 

Strictly speaking, that’s not correct. There actually was no MachineWorks Ltd back in 1994. Instead, in a small independent Sheffield software house called Lightwork Design, development work began on a polygonal solid modelling engine aimed at the simulation and verification of CAM toolpaths. 

Back in 1994, the leading CNC simulation systems used a geometric model loosely based on a zbuffer concept i.e. the distance of the surface of the in-process metal from the camera near plane was stored at each pixel. This allowed for very pleasant looking ‘graphical’ simulations, with the fairly major drawback there was no way to rotate the camera around the model, or zoom in, since the sample points used for the model only really existed in camera space.

The CEO and co-founder of LightWork Design had done a PhD in this area, and, with the encouragement of companies such as CadCentre (now AVEVA) and SDRC (later consumed by EDS then Siemens), work began on developing a solid-based CNC material removal engine. CadCentre, who were developing a CAD/CAM system based on a now widely-used geometric modelling kernel, had tried to use that kernel to model material removal operations to represent the results that the toolpaths they were generating would create when run on a machine tool.

Now, there is a particular challenge associated with verifying a CAM toolpath - that is the typically high numbers of operations. Otherwise, there’d be no need for specialist CNC simulation products as people could just use their CAD engines. But unfortunately, CAD engines tend to struggle once the number of operations rises.

In a complex CAD model there may be tens or even hundreds of 3D Boolean operations. In a CAM toolpath there are likely to be thousands of individual tool movements. In fact, in real world toolpaths this number can rise to tens of thousands, hundreds of thousands and for high accuracy machining, even millions. 

So, as well as creating a 3D solid model of the part, each Boolean subtraction operation that removes material from the in-process stock as the tool cuts the metal has to be really fast. In addition, the data structures need to be extremely memory efficient, as typically a lot of data will be generated.

In summary, typical BREP-based solid modelling engines struggle, and bespoke technology that is specifically optimized for the job-in-hand is required.  Even today, MachineWorks provides APIs to support import of in-process stock geometry to allow MachineWorks complete the job when the CAD engine has ground to a halt!

1996 - Batman Begins (Rapidcut)

You can imagine what the floating point performance of a personal computer was like back in 1994. A lot of optimisations had to be added to even make this thing work at all. But the team were successful, and by 1996 the new MachineWorks engine was fast enough to be usable within CAM systems for small to mid-sized machining jobs. 

However, the full polygonal BREP was, at this stage, still quite slow when faced with large 3-axis jobs. Having spent three years developing a solid modelling engine, competitive pressures forced an unwelcome diversion to add a new engine - based on dexels - which could verify these larger toolpaths in a minute or so, rather than tens of minutes.

And so Rapidcut was born. MachineWorks now had two engines: Visicut, the polygonal BREP, and Rapidcut, a pin cushion model that had a single x/y grid of points, with a single z-value at each point. It wasn’t able to handle indexed or multi-axis milling, or turning or mill turn, but it was a lot faster for single axis milling jobs.

As part of the Rapidcut development, analytic intersections for flat, ball, bull-nosed and APT tool geometries were developed. The intersection of the tool motion with the dexel rods was computed directly, using analytic equations. This was mathematically difficult, but the reward was that they removed the reliance on the tessellated swept volumes used in Visicut. This improved both performance and accuracy, and even became useful thirty years later during the porting of MachineWorks to the GPU.

1998 - The Dark Knight (Multicut)

At this time, in the late 1990s, many CAM companies were striving for accuracy. High Speed Machining was the hot topic in CAM development, and companies focusing on wacky new toolpath strategies were also focusing on ways to verify that these toolpaths were gouge free to a high accuracy, without waiting for tens of minutes or hours.

And so Multicut was born. Multicut was a new type of geometric data structure, comprised of analytic surfaces stored in a CSG-type structure with a high degree of spatial localization thrown in for good measure. A large die-mold toolpath could be processed in tens of seconds, and then the points on the surface queried to double-precision accuracy. 

2001 - The Dark Knight Rises (Pixelcut)

Multicut was a difficult technology to develop, and the fact that MachineWorks was able to demonstrate a working version shifted the goalposts somewhat. At the turn of the millennium, Lightwork Design acquired MachineWorks’ nearest competitor, Sirius Systems. Note that’s Sirius Systems, not Sirius Cybernetics, although the latter’s GPP technology certainly seems the more resonant just at the moment. 

The acquisition lead to a significant consolidation within the CAM component market – a consolidation that remains largely intact twenty five years later.

 

As part of that consolidation, MachineWorks added a fourth engine. Pixelcut was a rewrite of a legacy screen-space system that was part of the acquisition. Pixelcut was a supported part of the product for many years, until finally discontinued with the release of MachineWorks 8.0 in 2018. 

1995 to 2015 - Dunkirk

But all was not plain sailing at MachineWorks. 

An important part of the MachineWorks technology are the swept volumes – tessellated representations of the volume of space a cutting tool sweeps through when it performs a machining operation. MachineWorks’ swept volumes have always been within a user-controllable tolerance – that is the tessellated facets are guaranteed never to be further than that distance from the true surface.

It turned out that solving the problem of creating 5-axis swept volumes that remain within a specified tolerance of the true surface was a difficult one – and in fact it took over fifteen years of continuous development to solve properly. Having started in the late 1990s, the final in-tolerance 5-axis swept volume algorithm wasn’t released until 2015!

Ok, enough. Let’s continue The Odyssey without the Christopher Nolan movie titles ...

2000 – Full machine simulation (sweep-based collision detection)

Up to the turn of the millennium, the MachineWorks team had mainly focused on providing advanced material removal engines. Collisions between in-process stock, tools, holders and fixtures were supported, but there was no simulation of the actual machine tool itself. 

At that time several MachineWorks customers, such as Esprit and Delmia, had built their own advanced kinematic environments for machine tools and robot workcells, and made use of MachineWorks primarily as the material removal engine.

So, when not filling in forms and paperwork to certify that MachineWorks would not cause the world to explode at the stroke of midnight on December 31^st 1999, the MachineWorks team were busy extending modelling of the material removal process to cover modelling of the entire machine environment.

 

At this point the majority of collision solutions were based on time-sampling, where collisions between moving parts are calculated at a given moment in time. These were effective, but there was always the risk of missing collisions with thin geometry, or glancing collisions that occur in between time samples. 

The team started further developing the existing polygon-based swept-volume technology developed for Visicut, to support the more general case of sweep-based collision detection of forward kinematic chains - in particular the thorny problem of how to manage synchronization of multiple moving parts in such systems need solving, as two sweeps might well geometrically intersect, but at a given time t, the objects being swept may not. 

This was a challenging problem, to which MachineWorks created a clever solution, offering the advantages of sweeps whilst ensuring correct multi-body synchronization.

So that covers a busy first six years of MachineWorks. What about the remaining twenty six? Read about MachineWorks in the twenty first century here.