Building routings for make items is one of the three critical flows in StartProto. In this article, learn how the routing system is designed, how to best build routings that match your use case, and how to approach extending routings with documentation.

Before getting into the weeds here, we recommend you take a look at the high-level overview in StartProto at a Glance- that article lays out groundwork that we expand on here.

First, a bit of a review. You can define make items and buy items in StartProto. Put simply, a routing as a “map” that let us define what operations (or steps) we have to go through to to get from buy items to make items. For example:

This routing is pretty simple. We have a single buy item (Buy Item) that feeds into Step 1, then Step 2, and Step 3, which then outputs a make item (Make Item).

From this example, it’s pretty simple to see our routing’s Input Parts and Output Parts. Input parts are simply parts that have arrows that feed “into” the routing. Output parts are, you guessed it, the opposite. See the below diagram for clarification:

In the above example, we may have simplified things a bit! Unfortunately, operations aren’t considered parts- so in the background, what is happening is the system automatically add WIP parts between each operation. In reality, this is more what our routing looks like:

Now, we have a proper map! In StartProto, these maps are the core of the work generation system.

So, above we’ve defined what stuff goes into our routing. The next step to complete this routing is to define how many of each part need to fit into each step. Through the routing editor on the make item page, you can set the number of input and output parts that are made by an operation. So, our routing now expands to look like this:

As you’ll see, you have the ability to set input and output quantities at every step. This opens up some useful possibilities:

Input Part Quantities greater than 1

Pretty self explanatory- you need 4x Black-Oxide Alloy Steel Socket Head Screw in your assembly? Easy.

(for a full example, scroll down to the Assembly case study below)

Fractional Input Quantities

Depending on the Unit specified on your input part, you can consume fractional units. Let’s say you’re sawing up buy item 1/16" x 2" 6061 Aluminum Bar into pieces that are 2.600”. If you are using inches as this item’s tracking unit, you can say that your SAW TO 2.600 operation takes 2.635 in (accounting for saw kerf, of course 🤠) of the Bar per each operation (and therefore per WIP Part out, too)

(for a full example, look at the Saw and Singulation case study below)

⚠️ ADVANCED CASE: Output Part Quantities greater than 1 (Multi-Out)

Let’s say you have a fixture that requires multiple parts to be clamped together and ran through a few operations at the same time (maybe it is easier to track and process them together. We can create a multi-out operation that makes multiple parts to fit this use case.

An important thing to note in this example is that we still will generate demand (add parts to orders) in the item quantity. Additionally, we run operations in WHOLE quantities. In this example, if we had an order for 5x Make Item, the system would schedule 1x Separate Fixture & Package, 10x Add Parts To Fixture & Process, and require you to purchase 10x Buy Item.

Above, we’ve just been playing with very linear routings- one type of part in, one type of part out of every single operation. However, we have a lot of flexibility with setting inputs on our operations! There are two main things we can do:

Add Multiple Items as Inputs

This is simple- for our assembly, we don’t just need 4x Black-Oxide Alloy Steel Socket Head Screw, but also 4x Steel Nylon-Insert Locknuts.

Adding Items Later in the Routing

Lets say we have parts that come in at later steps in a process. For example, we make the part, and then we want to pull in a box for kitting before we ship these out. We can build a routing that looks like this to fit this use case:

We do have some limitations around what the system can do, unfortunately. Below we’ve laid out both the full rules for routing as well as some ones that are important to highlight:

For the visual learners.

🚫 Issue: Unit / Input Quantity Mismatch

🚫 Issue: No Input Part

🚫 Issue: Multiple Outputs

🚫 Issue: Circular Routing

Once you’ve built a routing that fits your manufacturing process, the next step is using the routing to effectively tell the right person to do the right thing with the right set of instructions. This section will explain how StartProto has designed a system to make this easy for you to do.

As shown above, operations are the core of every routing. Generally, when someone thinks of an operation that happens at a manufacturer, they may think of an action (mill) that takes place on a type of machine (Vertical CNC Mill). In StartProto, these “types of machines” are called Work Groups. They define, at a high level, a capability that your operation has (or in some cases, that happens externally).

When these operations are scheduled on the priority list, we need a way to link them to the appropriate work group. This drives both which Work Centers are available to complete the work as well as alert the users who should work on this. We establish this link in a nuanced way that makes it easier to maintain documentation.

When building out your routings, there may be some things that you want to remind your shop floor to do every single time they run a machine in a Work Group (i.e. check coolant levels, startup procedures, etc.). Conversely, there may be a couple different types of things that you do on a specific machine (i.e. sometimes you need to whip out a 4th axis for a machine) and the documentation is different even though it is technically the same machine.

You could theoretically attach these documents every time you build a routing, but that’s slow, and what happens if you need to go back and update something? That could be hours of work.

To solve this issue, StartProto took to the DRY Rule to heart- Don’t Repeat Yourself. When building our a routing, you will notice that you have to assign a process to each operation. The process is a place that you can attach documentation that is shared between operations. Processes must be assigned to a specific Work Group.

(this concept is especially useful for the Part Variations case study below)

With the introduction of processes, there are now four specific entities that you can use to show information to the shop floor:

You can attach documentation in two ways:

Coming soon! We will have case studies that highlight: