Simple, Fast, and Error-Free Design-To-Manufacture Workflows with Autodesk Fusion 360

MATTHEW SWABEY: Hello, everyone. Welcome to my, hopefully, inspiring talk on simple, fast, and error-free design-to-manufacture workflows built on top of Fusion 360. My particular background is, I think, somewhat relevant because, obviously, I'm going to present this from my perspective in solving my problems. And I'm really keenly interested to hear how you solve your problems. So if anything I say is particularly contentious or interesting, please do get in touch and I'd really love to hear from you.

So I got a PhD from the University of Southampton in the United Kingdom in 2006 in electronics and statistics. I then immigrated to Purdue in 2011. And I didn't stay in research very long. I've been focused on problem-based learning, which is laboratories, projects, and other things.

They've always been the greatest interest to me. And even more so, teaching so-called unteachable subjects. So for example, I led and still co-lead a team of undergraduates who fabricate custom microchips, a topic normally reserved for people with years of expertise.

Since being the center director, I've tried to take the same kind of passion for making really complicated things possible and focused this idea on manufacturing technologies. And I'm looking forward to sharing all the various advances and situations we got into, and hopefully, examples that you can apply to your own environments.

So a little bit about the center because this is where I work. The genesis of this work was to serve the students using the Center. It's at Purdue University in Indiana in the center of campus. It's an advanced student makerspace. We're a bit like a gymnasium where we have tools and equipment and machinery that is too expensive or too large for you guys to have at home.

We also have instructors in the form of student employees, graduates, and staff whose job it is to make sure-- just like in a gym-- that you make safe and effective use of the equipment. That you can be productive with it.

Unfortunately, the metaphor does break down because there's no membership fee. So unlike a gym, there's no membership fee. And we try to have no prerequisite classes, either. Our focus problem statement is, can we get each student to make something useful-- that they're defining as useful within two weeks regardless of their background.

To give you an idea of the scale at which we're operating, we have about 1,200 new students sign up to become Center members every year. And we currently have-- I just counted last night-- 1,028 students active in our Fusion Team doing designs and-- for manufacture in the center. And the main machinery that we'll be talking about today-- there's a lot more I'm not going to touch on-- is we have seven Hass CNCs, we have a Waterjet, several lasers, including a metal cutting one, and 3D printers and so on, all of which need a good workflow around taking concept and delivering manufacturable items.

So workflows. I think it's important that I try and explain my take on a workflow and the properties of a workflow that we will want to see. So here's property of a good workflow, in my opinion. So again, this is a really nice topic to hear from you guys on because I think everyone's going to value something slightly different.

So what do I want to see in a good workflow? And a good workflow should demonstrate is it should be simple and streamlined. It shouldn't be making you do things that aren't as targeted as possible in making it productive. It should be efficient. It should use your time efficiently, the person who's executing the flows time efficiently, it should use support staff's time efficiently, it should use the equipment efficiently.

It should be a comprehensive workflow. So a workflow that covers more stages is better than a workflow that covers fewer stages. It should be auditable and durable, meaning you should be able to come back to it later in time and get the same results from doing the same things. But also, inevitably, something's going to happen, either a success or a failure, and you're going to want to peer into the planning and the execution of that particular project and in that particular workflow. So it needs to be auditable.

[INAUDIBLE] workflow would produce quality output independent of a user's skills. A good workflow should be useful wherever and wherever you happen to be. So if we required a certain piece of software, say, and that was only available in very limited place, then how does that work in the modern world where we're all traveling and working remotely and life is busy and complex?

I believe that a workflow should take hidden and implied things and make them visible and explicit. So working in microelectronics and in manufacturing, both fields are rife with stuff everybody knows. And I'm afraid not everybody knows, and especially microelectronics. It's really hard to find microchip engineers to bump into in the corridor and find out what everybody knows. So the same with manufacturing. It should be showing you things and defining things. But that is also, I guess, a link back to the durability problem.

I would also say that while the workflow should capture all of this information, I would say that it would be nice if a workflow kept the design data, like the part models, somewhat separate from the manufacturing specific stuff. You need both, obviously, but it should be possible to take the part to another process or another machine or something like that without forcing a redesign.

And finally, I've got this error pyramid over on the side here. So you've probably met the safety pyramid before. But if you haven't, it's fine. Effectively, what I'm trying to say is a good workflow, whenever there's a possibility of errors, the best way of solving it is to eliminate the possibility of error. So can we target and remove root causes of errors. That's most effective at preventing the errors is just getting rid of the possibility.

Less effective is a multi-person review of people skilled in the art. And the least effective way of keeping errors out of your manufacturing and production, and certainly, my manufacturing and production, is relying on people's training.

Not just because I'm dealing with students who don't have much in the way of training, but even experienced people, including myself, we make mistakes. We're busy, we're pushed for time, we assume something. Stuff happens and mistakes happen. So one person's training is like the thinnest a piece of straw to rely on to keep errors out of your designs and workflows.

Let's focus on a CNC milling part flow in the center. I've chosen to capture your workflows based on talking to students, working with students, making my own parts. But effectively, we all have a slightly different take on this. Reach out to me with your take, especially if you think I've missed something.

But roughly, speaking it's in four sections. An idea concept section, where you're doing very rapid prototyping, experimenting, and capturing. The goal is to develop a specification. Then, you've got a modeling phase where you will create models, hopefully, detailed and rich of the thing you want, possibly with multiple parts.

Then, you'll start to make some decisions around how it's going to be made, what materials will meet the spec, and that kind of thing. Then, you've got the design for manufacturing CAM phase, where you're pretty sure you've got a good model. You want to move on to manufacturing. You're going to get very specific and concrete. Precisely what machines or processes, everything, all the detail needs to come in here.

And then, finally, you've got the actual execution on the floor in front of the machine where you have various tasks of building the setups that you created and setting up the machine and running the program. So I'm going to loosely classify this into four groups.

I've then gone through-- and this is based on analyzing failure documentation as well as discussions with students as well as anecdotes from industry and that kind of thing. So I've attempted to label what I consider to be the root causes of failure. But honestly, everything in this list, and things that I haven't listed, probably deserve that, too. But this is my subset of what I consider root causes of failure.

I have not identified colossal wastes of time and effort as failures at this point. Failure would be the delivery of a part which does not meet the need. Or, for example, a machine crash or a tool breakage or something like that.

So it starts in the idea phase. If you get the specification wrong, there's not-- you could make it to specification, but it's not going to meet the need. You'll notice that throughout this is file sharing and versioning. It was a common occurrence, especially amongst student teams, although I hear it happens in industry, too, where poor discipline around files and file versioning means that they made parts that no longer fit the whole, or they would turn up to manufacturer with an outdated file or they had missing pieces. It was a common problem.

I would also like you to notice, as you move to the right, the number of exclamation marks increases because, honestly, as you get more specific, you have more opportunity to create the failure. So at the beginning, there's more flexibility. But as you slowly get more specific, these are all good opportunities for failures to creep in and for you to not have something which delivers on time or on target. So for me, again, that was two weeks with little experience.

The Center's workflow back in 2017 when we opened was in person, and we kind of supported the right hand half of the flow. It had many other issues. It certainly was not demonstrating the properties I said earlier, which I saw as good properties. In fact, here's a list of the main problems, again, from mining data, from errors, and for interviews with people where the system failed.

I actually found it fairly professionally offensive in a way because we were highly individual specific. So when you came to the Center to get help with the manual-- the in-person supportive flow, it very much depended who you talk to what the quality of experiences and the knowledge that filled in the blanks that you needed and the errors that got caught.

It was only available at the Center because it was very dependent on individuals as well. It wasn't an easy way for someone who wasn't in the center to find out what we had in terms of work holding or tooling. There was a lot of variety because we didn't have standard sets. There's machine availability problems. It was very inefficient.

So firstly, that design flow doesn't take any iterative steps. But when you look at the design flow on the previous slide with the four phases, if you have to go back from phase four to phase one, you're going to spend a long time getting back to phase four.

Conflicting guidance often meant students-- and not only conflicting guidance, but errors around tooling and work holding choices were causing multiple new CAMs having to be done and constant full on redesign sometimes were having to happen.

We also often had people turning up without the right files to run the job because we supported multiple CAD and CAM packages. And as we know, there are different versions of multiple CAD and CAM packages, depending on the release here. So it wasn't unusual for someone to have the wrong G-code file and the inability to edit it, for example.

We also suffer from regular failures due to file versionings, where people would run all parts. We had a machine crash prevention strategy by manually reviewing the G-code output of the CAMs and having people watch the distance to go with the hand on the stop like a hawk.

Work coordinate systems is an interesting one. In the three-dimensional world of the model and the CAM, everything is plotted in a three axis coordinate system, in x, y, and z. But it's essential to align the perfect coordinate system of the CAM with the real world machine you're at. Make sure those 000s match up. Otherwise, the machine will move in unexpected ways and bad things will happen.

It basically had no audit capability. It was very much word of mouth. Finding out what had gone wrong and who had gone wrong or mistakes and so on became very much a he said, she said. You technically could audit it. But practically, because it took so much time and effort, there was no way you could actually do it.

I would also argue it's very fragile. Because often, the students would get CAMs or posts from various places and have various different versions of them. It was very-- it was difficult.

So I've covered what I thought a good workflow was and the properties it should have. And I covered where we were at when we started out and my professional irritation with it. So now, let's talk about the kind of changes we've brought in to get where we are today. And I guess I might mention, if you have time a few, of the places we're trying to go with things.

But first, I want to talk about change making. This is a topic extensively explored in literature, Ted Talks, and everything. And I highly encourage you to dive into it. We'll be touching on some of it for this particular talk. But for the purposes of this talk, I'm defining a revolutionary step where you're going to force people to do something. And an evolutionary step is a minor change or improvement to an existing process, which is often optional. So someone could decide not to take it or they could decide to take it.

Of the two, I massively prefer evolutionary steps. A revolutionary step is risky and often expensive. You're betting big. You're saying everyone change. And if it doesn't deliver, you've got a problem. So even with our bad system, the one from 2017, we still had students using the Center productively, making their parts for their-- everything from racecars to rockets and/or personal projects. They all had deadlines and schedules.

So if I'm going to say from this date everyone has to do something, I've got to be fairly sure it's correct. So revolution is a big change enforced. And evolution, not so much.

I would say that, to start any of this, you need-- and I'm not going to spend very long on this slide because, again, this is very well-explored in literature and other places. But you need to have the right mindset and culture, usually driven by an empowered-- one or more empowered champions. People don't like change.

This may depress you as much as it depresses me, but students can sound awfully like grumpy 40-year-olds when you change things on them, despite the fact it's to their benefit. And it's obviously better in every measurable respect. You'll still have people who insist on trying to do things the old way.

You're going to need someone with the authority to make change happen if you're going to try and move this kind of agenda and deliver the kind of improvements, which I think you should.

Secondly, I would focus on the problem. In my case, I have a simple problem statement that I can explain to people. A student should be able to make something useful to them within two weeks, regardless of their previous experience. To me, that seems like something that's fairly easy to communicate even very quickly.

I would also say that be very wary. When you come into a process like these, even though I'm aware of it, I still am not perfect at it. It's very easy for me to just not question something in terms of question everything. Consider everything for whether you can eliminate or automate it. Don't ever accidentally accept the status quo. It can be hard-- I've got some suggestions on the next page for how to try and identify these things when you've accidentally decided that you have to do things a certain way.

The last thing is pretty obvious, but make things visible, reuse, and be able to track your failures and inefficiencies are all important. So you say, OK, I accept that mindset. Fine. So how do we find out what we're doing?

So it's incredibly rare that we get to sit down with a blank sheet and just create stuff. Even the Bechtel Center when it was founded in 2017 we had-- our previous lab was shut down and the equipment and staff, students, and staff were transferred under the center and under my leadership.

We came with users. We came with expectations. We came with ways of doing what we were doing. So how do you actually pin them down? This is, again, a topic that is ripe for awesome discussion. And again, please hit me up with your ideas.

But I would argue that, for me, I have an evergreen class of new student users. In industry, hopefully, you can have new hires and interns who are the perfect candidates. They can document what they know and they can document what they had to find out to be successful and where they got it from.

Or in many cases, whom they got it from. Because it's not at all unusual to discover that critical business information has never been written down and is inside the head of one or more of your employees, or in my case, one of my students. So it's really important to discover who knows what.

Companies like, say, Renishaw has what they call the orange book where they've invested a lot of time and money and energy into documenting all their manufacturing processes and how each manufacturing process can be measured and how accurately you can expect it to be and so on. So there, they're explicitly creating a paper version of their knowledge intentionally and curating it. But I've often found people just do stuff.

There are other places you could look. You might have-- you have project management systems, task tracking systems, these are all good places to look for evidence of issues and where people are spending their time. ISO 9000 processes, audits and reports can be very useful here.

I've added focus groups, but I don't know if I should grade them out a bit. So focus groups, typically, the person you want in the group is a person who will avoid the focus groups like the plague because they've got stuff to do and they're getting stuff done. That can be tricky.

The other problem is people will often turn up to a focus group to pound their pet project, their pet problem, whatever it is, and not the actual problem. So I would say focus groups can be useful. But honestly, I like the new hires and interns because they're approaching your organization in your institution fresh. I confess, I don't know what I know in many areas. And I just assume people know things. So it's really hard to find out.

So first step was a revolutionary one. We had multiple CAM packages. That was unacceptable. It forced us into working with Decode. We had all sorts of issues. So we said, OK, from now on, all CAM is done in Fusion 360.

The reasons we chose it are Fusion 360 is actually pretty streamlined. It combines a lot of functionality into one user interface and program. For an experienced person, hopping between multiple programs is less painful. For a beginner, hopping between multiple programs is a huge barrier to progress.

I would also argue Fusion does try more than most to cater to beginners or people who are just getting started. I've got a tooltip here up on the picture that I yoinked from the CAM setup. That's provided for nearly all the operations where it attempts to explain all the values-- it attempts to explain what's going on. It doesn't expect you to have done training classes before you use it.

Fusion automatically solved the problem of the failure mode of files and file versioning. It just made it go away almost overnight. Students almost have to intentionally do something weird or stupid to run into this problem anymore. You can see on the far right, it's got everybody's-- when anybody edited the file and who did it. On the bottom, I've got the timeline within a design where you can see between the different versions what happened to the timeline. So you could even figure it out down to an almost operational level who did what.

It has automation support built into it. And it's fairly lightweight on resources in cloud-based. So you really can use Fusion 360 on a laptop wherever you happen to be. We do still allow alternative CAD for certain groups who have a long history of designs in that CAD. But honestly, nearly everyone shifted over to Fusion for CAD and CAM now because it's so much more efficient to have the two connected strongly.

So that was a revolutionary step. And honestly, it did not make us popular. Everybody loves the CAM software they were most successful in most recently. But, on the other hand, driving change does mean making choices.

The second revolution we did, although this didn't directly impact people manufacturing stuff, but it's kind of revolution because it's spending money, is founding an actual software team. You need software engineering skills. I genuinely don't think you can deliver the kind of advances we have with things like graphical programming through Microsoft Power BI and various other technologies like that.

You are going to need someone who can genuinely code or one or more people. You're going to need people with IT management to help you manage file sharing, networking firewalls, that kind of thing. I would argue your team needs to have a rare skill set of a person who can program and who runs parts on CNCs. I am very fortunate. [INAUDIBLE] has a masters in computer science and he has been running CNCs for seven or eight years now.

I would argue they need to use standard software methodologies. This is important. It's really bad-- there's a lot of reasons why software methodologies were developed. They should be followed. The team should also be dissatisfied with out-of-the-box experiences. And with a person on the team who run the CNC programs, hopefully, they can forge a strong connection with those who are. Our Center team is about two to three people at any given time. So be that as it may.

Lastly, JavaScript. Fusion 360 posts JavaScript. JavaScript is used for a lot of web services and so on. So I would argue that it's a core skill in this particular-- to deliver the kinds of changes.

So this was an evolutionary change. And be aware, I'm not talking about doing this once. I'm talking about building a pipeline that flows from left to right. So this is something that we want to set up. And then, we want to apply it as often as needed.

So folks with machining knowledge, even among the students, were typically not good programmers. So it's really important to give them easy avenues for their data to be captured. So a complex web form was built. It had a lot of the graphics you might recognize from the Fusion tool library.

But basically, the idea is that someone who doesn't know any programming can specify it all pretty completely. The web form outputs into a CSV file. Now, here we, again, had folks skilled in machining who could review the CSV file entries. It was also the interface by which bug fixes and updates could be applied to existing lines.

So if someone needs a new tool, they can take about five to ten minutes to use the web form or less if you happen to have the catalog open to enter the tool and it's in the CSV file. Then, there's a review step of the CSV file. Once you're happy with that, you using Python transform it into a Fusion tool library. And then, you upload that onto the cloud.

And we have 1.028 people in our team. I think the fastest we've applied a fix is about 15 to 20 minutes. It's completely painless. It's something that Fusion offers that's perfect. We just have a continuous flowing pipeline. Particularly good finish, excellent speed and feed for that material in the form or someone could capture it directly in the spreadsheet, generate the library, push out a new version.

1,028 students get these machining parameters and tooling immediately. Need a new tool? Create it, review it, push it. So it's all about a cycle and a really tight one, too. If a problem arises, we can get it fixed and a new version out literally in 20 minutes to over 1,000 people. As far as I can tell, it's also a scalable solution. It could be 5,000 people. It's going to work fine.

The subheading, by the way, is the good properties of a workflow that, I believe, this kind of development impacts. So along with the tooling models, we began to model workholding. And again, you can start using the tool library as soon as it has content as more and more of the tools come out of people's personal libraries and go into the automated process and it captured in the spreadsheet.

Here, it's the same. A workholding can be progressively captured. If you look at the models, they're simplified because there's no need to waste battery power or processing power on complex models of a device. It needs to be geometrically accurate.

And they're all jointed, so they all snap together. And common configurations are supplied. So you can see in the background there there's a Kurt for the 5C [INAUDIBLE] block.

But then, the next step is to model the CNC beds. So we have the entire CNC bed with the workholding for your particular job and the workholding that happens to be there. In this case, that box on the far end is a fourth axis.

So model everything. It's already modeled for a normal user. They bring in-- they create a new file for this particular setup. And they bring in their part design and their stock. And then, they bring in the table. And then, they will do the CAM in that particular file.

It's great because it really starts to address that goal of, can you do it anywhere at any time? So you now have a tool library model and feeds and speeds. And now, you have a table model. You don't have to talk to someone who works in the shop to know what we've got. It's all there.

So once you start getting these kind of assets in place, you can move away from a simplistic simulation on the left, where you've just got a tool and a stock block. And honestly, it was sometimes hard to get students to use that. To a simulate everything approach, which is now the standard.

This started as an evolution. But when we proven it out, it became a revolutionary change. You had to do this. So we don't accept stuff that you can't simulate. We require you to model the entire CNC bed to simulate.

One of the inefficiencies of the previous process came from the manual G-code review, which is, you had to adopt the stance that there might be an error and you had to set it up so that you ran the CNC slowly with your finger on the stop key so if it made an unexpected move, you could stop it.

But quite often, if it made an unexpected move while in contact with the part or machining, it would break before you could stop it. But at least you could stop it before the machine suffered damage. With simulation, however, this allowed us to go at full speed.

So with an unknown part, a first time G-code run, if it works in sim, we're going to run it at full speed. So it really attacks the efficiency problem. As CNCs went from running at very low speeds, very light cuts, to very high speeds, deep cuts, meaningfully-- meaningful experiences. What you would expect from an actual CNC.

Also, a lot-- working a lot closer to the workflow crashes, it caused us a problem because we've moved from tools breaking before they had a chance to wear out to tools wearing out. So a whole new set of skills to audit the tools was needed.

This came towards the end of the simulation side. And the workholding side is we attached pieces to the CNCs. And we're going to cover various approaches and so on. But hopefully, this really began the start of treating G-code now as a black box. We do not accept hand-edited G-code. If you wish to make a change to your program, you change it in the CAM, you repost it, you reupload it to the machine.

You are not editing G-code. And we'll talk a little more about that later. But G-code we now treat as a black box. Again, this arrived by evolutionary steps, but we're now at the point where it's required.

The superpower you get here is the ability to look at the picture of that simulation you created earlier, look in the CNC, and instantly identify if there's something missing, if there's something added, if the workholding is wrong. Effectively, people with no skill or background can still look at a picture. And even if there is a minor difference, we'll talk about that in, I think, the next slide.

So not quite yet, but, in this case, again, a good prod workflow makes hidden and implicit things explicit and visible. So if you look at that stance section on the Haas control screen capture, there's four or five pages of G-code to create the tool path that's running on the right. Which one tells you what's going on better?

I think it's no contest. Even if you're skilled in the art of reading G-code, if you've missed one decimal point out of place, say, someone's edited a different part of the file and accidentally, I don't know, jumped somewhere and knocked something, that can't happen if you're verifying in sim, and then, deriving the G-code from the sim.

Yeah, I think there's no contest. That is really easy to understand, even if you don't know what's going on. If you have no experience how on Earth you managed to interpret the G-code. So making hidden and implicit things visible. Making the workholding explicit and visible. It really drives that independent of user skill criterion.

So then, we can move on to the in-machine work coordinate setting and probing. So it used to be the first tool that would come in would be the probe. When you break the probe, the machine would be down for a couple of hours and it would cost maybe $60, $70 for a new prop stem. In one case, the probe was actually smashed and that was $1,000.

But this is engineering in the software in the post where we program the post to create media appearing on the control screen. So again, someone not skilled in the art could look at that picture, look at that pencil coming in and say, yes, that's correct. That addressed the work coordinate system and helped a whole load of-- basically, drove a whole load of usability forward.

Another example is we've got models of all the tools. So the CNC itself will prompt you to load a tool. And then, it will measure the tool to check the tool is what it should be. If you get the tools wrong, that's going to be a crash in the machine.

Why? The other great thing about this is, even if you're experienced, this is more efficient than typing on the Haas control because you have to select the tool, select the tool type, type in the tool geometry, then probe it. Here, all of that flows automatically in the post.

So the CNC just says, load tool one. That's it. And then, it will probe it. And if it doesn't find what it expects to see, errors out. Again, a whole source of errors gone. And again, you can do it without knowing anything. You just need the green and red buttons to move to the next stage.

Toolpath approvals for auditing. So the post won't actually generate G-code unless every toolpath is signed off. When the toolpath is signed off, if there's a problem, we now know who signed it off and we can do retraining as needed. We could do exploration of why the problem occurred. Really important for that whole goal of auditing, so knowing what happened.

And finally, I'd like to quickly cover what I considered-- let's summarize all of this talk. And hopefully, some of those advances look really good to you. But I mentioned the properties of a good workflow and the need to eliminate errors if at all possible and the various key factors.

So if we take a look at where we were in 2017, then we had this manual flow based around verifying decode. And we had no digital assets or anything, really.

If we go into 2022, our workflow now includes everything. The initial ideas and concepts. We encourage people to photograph the rapid prototypes in their notes and sketches and put them in their teams as well. Every red triangle that's been turned to a tick is a fundamental root cause of error eliminated. I mean, I've already mentioned file sharing and versioning, which Fusion handles transparently.

And the design for manufacturing the CAM space. You're getting known good machining parameters. You have a model of the tool. If you have a model of the tool, it means we have the tool. So you've got all the availability sorted out. The workholding. If we have workholding, we have a model of the workholding.

On the floor, there's still some skills that this flow does not solve. If you build the tools wrong or you build your workholding wrong or you don't torque the vise tight enough, then the workflow won't help you. However, I would argue our workflows addressed well north of 50% of the root causes of failure as well as driving home a huge amount more understanding and visibility of what's going on.

Quite often, our old manual flow really resulted in my student employees doing most of the work and the actual students not really being in control or doing the actual thing. Remember, the problem statement was for the student to make it, not to have it made for them.

Lastly, to tempt you, this was just the milling one. We have similar workflows for our turning. We have similar workflows for turning with live tooling, routing, milling, and sheet processing, laser and waterjet and so on. So again, you can apply exactly the same principles within Fusion using exactly the same concepts that you learned to do completely different part designs in parts without having to relearn a new tooling or new ideas.

Obviously, there's some fundamental differences in how these technologies work. You will still have to pay attention to those. But fundamentally, we can apply the same approach and have applied the same approach to a lot.

Finally, a very quick flash. The students have mostly developed and created these things. They're the ones who did a lot of the programming, the testing, the verification. They're the ones who use those web forms to capture the tool types. They're the ones who found good speeds and feeds, modeling things, and so on, as well as the programming side of things. So a big shout out to them as the owners of this kind of development.

Honestly, it's the best way of getting people on board is to make them part of the process. And thank you very much. I'm glad of your time. And I really hope to hear from you, especially if you disagree with me. Because I'd really love to learn what I missed. Thank you very much.