Autodesk is a company founded on innovation. The proof of this is in the myriad products created by hundreds of entrepreneurs and engineers. But how do you maintain the revitalizing energy that comes from innovation in a large corporation? One way is to use an innovation sprint. Put simply, an innovation sprint provides a short period – only a few days – of dedicated time where a team identifies a problem to solve and creates a proof of concept.
Our journey began with my engineering team generating potential ideas. We refined the ideas and shortlisted three. Next, the team offered feedback on the desirability, feasibility, and viability of the three proposals. The idea that got most support was the G-code debugger. What’s a G-code debugger, I hear you ask? Well, let me explain.
What’s a G-Code debugger?
Let’s start with post-processing. In machining, post-processing is where a set of toolpaths (arcs and lines) are converted into G-Code – the programming language for Computer Numerical Control (CNC) machines. Each CNC controller has a different dialect of G-Code, and this is where the post-processor steps in, acting as a translator. You can find these different translators in the Autodesk post-library. The post-authors write these translators in JavaScript often using the Visual Studio Code extension.
The G-code debugger offers additional information (illustrated in the picture below) to the post-author including:
- The details about the CAM input from Fusion (the lines, arcs, etc. contained in the left panel).
- The line of G-Code this generated (contained in the NC output panel on the right).
- A code view (Center), which allows the user to see their post-file. The blue highlighting links the line of the cam input with the line in the post that generated the line of G-Code.
- Additional state information about post formatters (used to generate the G-Code strings), available post variables, and property values.
This information gives the post-author the ability to quickly understand how the post is working and aids them in fixing any issues they have with the post.
Designing the innovation sprint
So how did we go about planning our sprint?
- To start, we needed a skeleton of what the user interface for the prototype would look like. This helped us visualize the user workflow and gave the team a sharp vision of what we wanted to achieve in our proof of concept.
- The next part involved breaking the elements of the projects down into tasks that could be tackled in parallel by the members of the team.
- Making tasks parallel can be challenging for any team but in our case the project lent itself to two parallel flows: post-processor development and the VS Code extension UI (User Interface).
Deciding on technology
The next, and often controversial, part of any project was deciding on technologies. In our case, we wanted to use web-technologies so that we could embed the new functionality into various products: from a browser to VS Code, to Fusion 360, etc.
We decided on Typescript and React, which are prevalent JavaScript technologies within our group. To combine this proof of concept with the existing extension, we used gulp.js to bundle the file into a format that could be used by the VS Code extension. This is something that we want to improve in the future by moving the whole extension to Typescript. For the code editor we used Monaco, which is the editor that powers VS Code. We used BabylonJS for the 3D view.
What happened?
- We started the innovation sprint by working in a mob programming style where we laid out the ground rules and core files for the application.
- As we went through this process, we found that we could split up into pairs or work individually on various aspects of the project. This created an interesting dynamic with the team communicating through a dedicated slack channel, a regular standup, and more mob and paired programming as and when developers wanted to talk.
- We used a hybrid approach for meetings, connecting in the office and on Zoom.
- A key principle of agile is “people over process” and it felt like we succeeded by not being afraid to change our minds or tasks as we gained more understanding. But we also had the discipline to maintain a list of tasks to aid communication and commitment. The mob and paired programming were great ways of sharing knowledge within the team.
Next for us
What do we want to do in the future? First, we want to assess how well the G-Code debugger is received in the post-author community. This is a well-established VS Code extension, and we hope the new functionality will provide the extra information the community needs to debug posts more efficiently. We will use the feedback from post-authors to shape the direction of any future functionality. This is where the GitHub repo can help us with communication and encourage an active developer community around the project.
On the codebase, we have some tech-debt around the unification of the G-Code debugger with the original extension code, and we want to revisit the architecture of the debugger which is currently dependent on a single react data context.
What did we learn? We learned that collaborating on new code and technologies is fun, especially when you make progress and achieve more than you planned. Everyone found their flow in the project, and we felt it brought us closer together as a team.
About the author... David Maffioli is Software Development Manager at Autodesk
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.