MAKEIT is a web application for designing and making things, specifically using CNC machines. People use the online CAD (Computer Aided Design) tools to create geometry which can be converted into manufacturing CAM (Computer Aided Manufacturing) operations. The design can be submitted to and made by MAKEIT, using their selection of materials and machines. Alternatively the part can be made on the users CNC machine just as easily. The parts sent to MAKEIT are automatically milled out and shipped. Costing is calculated as a combination of machine time and area used.

The original idea for a CAD functionality was to use OpenJSCad. After some research it seems OpenJSCad isn't really good enough for making complex models, especially if they contain complex surface modelling. The main limiting factor is its use of CSG (Constructive Solid Geometry). Great for designing mildly complex 3D printer objects, but not so great for machinable entities. BRep (Boundary Representation) is the common method of modelling geometry is all modern CAD programs.

No one has written a JavaScript BRep CAD library yet, probably because JavaScript isn't a great choice for mathy/intensive computing. It is however great for easily shared apps, aka, the modern web. JavaScript is also constantly being improved, performance wise, so maybe it could work out okay. No one just goes and writes a BRep library though, it's hard. Starting with a simple 2D CAD library is the obvious first step. Maybe then it can fleshed out to include 3D operations in a BRepy style.

In my mind what's even more important is a slick way of actually getting designs to the CNC machine. CAD is only half the problem, CAM is just as tricky. Traditionally, people create the Geometry using some CAD software, then export it. It then gets passed along and imported in some specialist CAM software where the machine G-code commands are generated. It's this clunky approach I really don't like. Did I mention the commercial software is very expensive as well.

The problem with going from CAD to CAM software is the logic is lost. The CAM software doesn't know what I want to do, it doesn't recognise the geometrical objects in the same way as the original CAD software. Hold up, CAD and CAM software are generally separate for a good reason, they tackle two different problems after all. Coupled with file standards (.step, .iges, .stl etc.) they are very flexible like this. What I'm trying to get to here, is that I want to be able to pass my geometrical 'objects' straight in CAM operations (profile, pocket, hole etc.). And I want to be able to do it programmatically. So, a CAD/CAM library is what it's all about.

Keeping the app programmatic and not initially adding a GUI for CAD/CAM operations is the current idea. Manipulating geometry and CAM operations programmatically should be powerful, and naturally parametric. Modern CAD libraries have a parametric engine. They store all the geometric objects/model and when a dimension changes (and you have set constraints) they figure out what to do with all the other dimensions. Here, I am proposing a straight run through type program. Nothing is modified dynamically. Every time you make a change to the design code the whole script is re-run a-fresh. Doing this makes use of the natural parametric style of the language (variables). It also makes it much more simple to code. Of course re-running an entire model every time something changes is not a great idea performance wise, but oh well. It not a commercial challenger, just a useful, functional library for the home hobbyist.

Using code to create geometry and generate CAM operations is not just powerful for designing, but improves workflow (if you like to code!). So, when lots of people work on a CAD design, or it's just pretty complex, they need some kind of system to manage the process. Enter PDM (Product Data Management). This is normally sold on top of the standard CAD software. It does the job, probably well, I've never had the privilege of using it. You basically check parts out, work on them, then check them back in. No one can work on a checked out part. Sounds a lot like version control!

Using code to define the CAD/CAM makes it super easy to add this kind of functionality, just use Git. That takes care of a lot of trouble. Essentially, keeping the design code based means it can make use of tons of proven open source tools. Another example, package managers. There are no general, opensource, mature CAD/CAM package managers, it's just not a thing. Using code and JavaScript in particular, you just piggyback NPM for sharing, done.

So, in summary, CAD files could be held in a Git repos. This would make it easy to edit files both locally and in the online editor. Files can be downloaded using a normal 'git clone', edited and pushed back. This could either be done through a third party or by setting up a private Git server. Saves made online would be done as commits, allowing versioning and rollbacks.

Sharing or collaborating is what makes the complex possible. The app would be frustrating if people had to start designs from scratch every time. Being able to share code that functions as a plugin is powerful. Picture this very simplified scenario. I design a box, programmatically, using the app. It takes the dimensions of a box (length, width, height) and generates the geometry for all the faces. It then generates the G-code to mill out the faces on a CNC machine (from sheet wood). I wrap this up and make it a callable function (a plugin in the apps sense). Next time I want to make a box, I just call the box function with the dimensions, done.

Maybe I want to make a wall of boxes, or a wall out of boxes, kind of like wooden lego blocks. In my app code I define the size of the wall and split it into chunks. The box plugin from earlier can be called for each individual box generating all the data needed to cut out the sheet wood automatically. Maybe I got the wall size wrong. Just change a dimension and re-run, All the data has been re-generated. I wrap this code block up in another function (another plugin).

Maybe I want to make a bunch of walls and join them together. I define the footprint of the walled area and split them into individual walls. Calling the wall plugin for each wall takes care of the rest. All that's left is to cut out the wooden sheets using the generated G-code and put it all together. Turns out that a bunch of walls could be a house/shed/garage etc. Imagine if you could define a 3D space and automatically generate a flat pack house with a few lines of code! The idea of making a house from flat packed wooden boxes is not new. It has actually been done, on grand designs.

That might have been a very convoluted and simplified scenario, which could have been explained much more quickly with a coding example. Thats because this concept of reuse is completely trivial to programmers, that's what programming is. What's interesting is how that process doesn't get naturally carried over to normal CAD work on an inter-project basis. More traditional GUI based CAD software lets you write macros to do this kind of thing, but it's not really exploited much. I think it's because there is no easy/direct way of sharing them robustly. No real package managers, or integrated version control. Making code the primary way of designing with the app forces you to think in a more modular sharing way. That's what this app wants to tap into.

Part of the main concept is the ability to go from geometry to G-code in one place. Being able to use the G-code is therefore important. The other half of this idea is an app for running CNC machines. It should take G-code and relay it to the CNC machine appropriately. The app can be designed around the same software stack, a web server with the browser acting as the GUI. A fully blown computer can be attached the CNC machine these days thanks to the Raspberry Pi and friends. The Raspberry Pi doesn't control the machine directly, it just barks orders at a microcontroller.

Having a CNC machine exposed through it's own web page is an interesting idea. Not only is it cross platform but also cross device. You could control or monitor it with a phone for example. Stick a bunch of these machines in a room together. When you need to cut something out, log on the to appropriate machines web page, grab the G-code and go. Connecting all the machines to the same wireless network would make for super easy access. Machines could also interact with each other using this method, automating a production line.

Being able to design products parametrically in the browsers native language creates further possibilities. As people begins to develop their own parametric models a 'model store' could be created. A place where developers can submit their parametric designs. When approved people can buy them with their specific dimensions. MAKEIT or whoever then makes then using CNC machinery. The designer get paid a commission percentage on the purchase price. It could almost become an 'on demand' IKEA. Furniture and other objects are CNC'd on demand to the customers exact needs. Parametric modelling and automated CAM help achieve this.

This forms the possibility of creating a very lean business, when products are made on demand without noticable delay. This means no warehouses or stocking overheads and issues, greatly reducing costs. The key is seamless design and manufacturing. A store or opensource collection of makable objects is not new. 3D printing turned this into a business a while ago. The difference is CNC machining is more complicated to automate. 3D printers just slice a model up into layers, there is order with depth, and a generic approach is possible. CNC machines don't work like that. Cuts are ordered by operations like making a hole or pocketing an area. Depth has no effect on the order. Hence, there is no general way of milling a CAD model, is has to be defined by the user. Making this process as slick as possible is the important concept.