I remember a couple of months ago when my co-founder Jesse excitedly (a little too excitedly) announced that we would be bringing formulas into Bommer for Fusion 360. I was a bit confused at the time, thinking yea that sounded cool and all but what would it really deliver for our users? As we talked through the possibilities it would unlock, the coffee started kicking in and I started to understand. And then it hit me, kind of like...

What I realized (and what explained Jesse’s over-excitement) was that there are often several steps to go from part metadata (typically entered into a bill of materials) to actionable information used in manufacturing. Those steps are usually calculations or transformations — in other words, formulas — that are built into a spreadsheet (or another software package), or computed manually. Building formulas into Bommer is a big deal because it keeps those steps inside your single source of truth, along with the data, to be automatically updated whenever the source data changes. This means our users won't have to worry about: Did I remember how to compute this value correctly? Did I format this data in the correct units? To the correct precision? Will my documentation be correct?

Example formulas and use cases

Let me go into some examples from real-world use cases that we saw as an opportunity for us to do some good here. If you’re familiar with writing formulas in Excel, many of these will look familiar (though our formula structure is slightly different); in either case, we have a handy guide for you to follow along with, and a guide with common formulas and their uses to set you up for success.

Starting off simple, here's how you can compute the total cost of a line item with the Bommer properties Quantity, and Vendor Cost

= Quantity * Vendor Cost

This multiplies the Quantity times the Vendor Cost (cost per item), and stores the result. Pretty straightforward.

For fasteners and other items sold in packages, we probably need the quantity of packages to buy:

= Quantity / Package Quantity | ceil

This divides Quantity by the property Package Quantity, and then uses the ceil formatting command to round the value up to the nearest whole number. As an example, 76 screws divided by 50 screws per package will show 2 packages needed to complete this assembly.

To get the cost of those packages, we could replace Quantity in the first example with the field we use to hold this value, or just write out the whole formula:

= (Quantity / Vendor Lot Size | ceil) * Vendor Cost

And if we always order more fasteners than we need for safety, we can add that factor in as well:

= (Quantity * 1.1 / Vendor Lot Size | ceil) * Vendor Cost

In these examples, Vendor Cost actually holds the cost per package, and we multiply it by the computed number of packages we need to buy. Now we're getting somewhere; this is a number our purchaser can use. In the second example, the 10% "fudge factor" could be stored in a design parameter or a property instead of written as a fixed number, to make it more configurable as your project evolves.

One of Bommer's strengths is its ability to automatically extract your physical properties and dimensions into your BOM. Fusion has a robust unit system, but it's not always easy to get the data out in the format you want. With Bommer, unit conversion is now expressible as a formula.

Maybe you like to work in millimeters, but your shop expects lengths in inches:

= Longest Dimension ::in

This converts the default property Longest Dimension from your document units to inches.

Similarly, maybe you need to represent shipping weight in kilograms, but don't want to model in meters. You don't need to flip flop your document units, you can create a property in Bommer with this as the default formula:

= Mass ::kg

Similar to above, this reads the default property Mass and converts it to kg, regardless of the units configured in Fusion. There is a lot of flexibility here.

This last one came up a lot when we were talking to users about their BOMs, and it's one of my favorites (and the most complicated one on this list). Here's a formula to format a dimension as ft and inches, e.g. x'y" :

=(Width ::ft | floor) & \' & (Width ::ft | rem ::in | 0) & \"

Parentheses and sub-expressions, unit conversions, multiple formatting functions, and the & operator to concatenate the bits of text together: this will let you represent (in Excel and on your drawing sheets) a dimension — in this case, Width — as feet and inches. You can use this formula with any Bommer dimension just by replacing Width with the correct property name. And it doesn't have to be a Bommer property, it can be a Fusion design parameter that you are already using to drive geometry in your model. Boom.

A more powerful bill of materials

This is exciting, but the more I thought about it, the more I started to see more. See, at our core, Bommer has always been about saving time and hassle. And where we can, we like to step a bit outside of our sandbox if it lets us help out our users. With the addition of formulas, your BOM has the potential to grow beyond just documentation; it can now be a design tool, letting you keep an eye on critical metrics as you’re designing to ensure that your parts will not be too heavy, your subsystems will not be too expensive, and your assembly will not be too large. Imagine having your BOM tell you if you’ve met or exceeded your design targets? Or your product spec? Right in your CAD software? That’s what I am talking about.

So give it a try, bring in that one excel wizard that lives and breaths equations, and let them loose on your BOM. Make sure they know anything other than Fireball beforehand though.