Drawbacks of v0.1 Setup

The v0.1 setup filtered chips from the coolant with no spills, so that alone was a huge improvement over the prototype, but beyond that, it left a lot to be desired for ease of use. It was a major pain to empty chips after a job was complete, because there wasn't enough room to remove the chip basket — the entire assembly (reservoir + filter catch basin) had to be pulled-out, from under the CNC table, in order to empty the chip basket. My original plans for v0.1 was to cut the front off of the laundry basin and add sliders so the filter could be pulled out, but I couldn't bring myself to make the cut.

The awkward coupling of the reservoir and catch basin (laundry tub) also meant it was difficult to check coolant levels and measure PH in the reservoir. The filter mesh (50µm / 270 mesh count) I was using started to clog after 2-3 jobs, and then eventually during a single job. Even after a thorough cleaning of the mesh, it was clogging consistently, and I was feeling anxious about high coolant levels in the chip basket, again.

Updates

The changes are minor, but they have been a real delight during operation. These minor iterations have made life more enjoyable when using the machine.

Ditch the Laundry Tub

Decoupling the laundry tub (see v0.1 post) from the reservoir was the first step in tackling the updates. No matter where I moved the laundry tub it took up too much space and I kept bumping into constraints. Due to it's height and vertical location, I'd have to add a small pump at the drain to get coolant back into the reservoir, which meant adding a float switch for coolant height in the catch basin, or changing the coolant return to be located on the side of the reservoir. All of which I didn't want to do. Very quickly I decided that I had to ditch the laundry tub — it felt messy trying to move forward with it.

The simplest idea at the time was to put the chip basket inside a smaller plastic bin and as long as that bin was located higher than the reservoir, it would drain.

I found a plastic container by Sterlite called a Gasket Box with dimensions of 47cm x 37.8cm x 28.3cm / 18.5" x 17.875" x 11.125" and 30L capacity. This had a nice foam gasket around the perimeter and four snap latches to seal the lid, to prevent evaporation when not in use. The latches weren't necessary, but the design and shape of the container worked well for me, and most importantly it fit the chip basket nicely.

Where to buy: Home Hardware

Hanging Chip Basket

The chip basket hangs just slightly below the top interior edge of the catch basin (gasket box). I used scrap pieces 5052 aluminum sheet and bent wide S-shaped hangers for each edge of the container.

I kept the chip basket (seedling plant trays) from v0.1 because they worked very well. I still need to better secure the filter mesh to the tray, but it's a minor asthetic issue.

Where to buy: Amazon

Bulkhead Fitting

I added a bulkhead fitting (drain) to the back of the filter catch basin (gasket box) so coolant would flow back to the reservoir.

Unfortunately I couldn't put the fitting for the drain on the bottom of the container due to height restrictions and the coolant return slope. I positioned the drain as low as possible on the side to minimize the coolant remaining in the bottom of the filter catch basin. Not ideal in my mind to have a small amount of coolant always in the bottom of the container, but it would allow me to visually inspect the colour of the coolant easily. I entertained the idea of having a small pump in the bottom of the container to circulate the coolant, but in the end I abandoned that idea.

I also added a ball valve to the reservoir return drain, so the flow could be shut off if I had to move the filter catch basin, or the reservoir.

Where to buy: Home Hardware

Slider Shelf

The slider shelf allows me to pull-out the filter catch basin and chip basket for easy access. Being able to conveniently empty the chip basket has been the best change by far. There's not much to the slider shelf, it's just a couple 2x4s, plywood and heavy-duty drawer sliders.

Where to buy: Rona - drawer sliders

Filter Mesh

Lastly, I changed the filter mesh count from 50µm (270 mesh count) to 100µm / 140 mesh count for better coolant flow. Previously a shallow pool of coolant was starting to form and not drain through the basket fast enough, as shown below. After an hour of operation, this pool of coolant would be near the top of the chip basket.

The 100µm / 140 mesh count works much better. It filters chips and the coolant drains through immediately. I might try 70µm filter mesh in the future to compare the filtration qualities, but at this time I'm very happy with 100µm.

Where to buy: Amazon

I've only used this new filter setup for 4 months, but it is a significant improvement over the v0.1 setup. These minor updates have made life very enjoyable when using the machine. I'm really glad I took the plunge and ripped out that massive laundry tub.

Wish List

There's only a couple items I would change to improve operations further.

• Dual filter baskets for quick change during operation. I would love the ability to easily empty the filter basket without stopping operations. I currently have to shut off the coolant pump, shut off the CNC table drain, slide out the filter chip drawer, pull out the full chip basket, swap in an empty chip basket, and try to not drip coolant on the floor from the full chip basket. Once swapped, then I open the CNC table drain and turn the pump back on. It's not as smooth and efficient as it could be. Having two baskets with a way to automatically divert the drain flow direction would be lovely.

• Coolant level indicator. This is a wish list item that has carried over from v0.1. Having the ability to see coolant levels during operation is really helpful. I had attached a fuel sending unit on the reservoir, but never got around to hooking up a circuit for it. Having an analog and digital read out would be ideal. Digital to signal a stop if levels are too low, and analog for a quick casual glance.

• A rigid filter catch basin drain pipe. The flexible hose I currently have attached to the filter catch basin and reservoir allows the drawer to be pulled out. The flexible hose is excessively long to accommodate the full extension of the drawer, and therefore takes up a lot of room, and also has to be supported so the hose doesn't sag and stop draining. It works, but it's a failure point that I'd like to make more robust.

• Inline filter with high mesh count. In the original prototype I used an inline filter, and I'd like to bring that back but with a different setup, possibly on a separate filter circuit that's independent of CNC operations. Then I can run the inline filter to clean the coolant a bit better.

For example, I have an alias called "ci" and it runs multiple continuous integration commands in a project: clean;coverage;ca;check;analyze;test;coverageReport. I can easily type two characters in the SBT shell to execute a series of commands.

Aliases File

In the root of your Scala project, create a file called aliases.sbt. In that file you can add a command alias like so:

Replace <alias> and <command> with the values you want to use. For example, to make an alias that compiles all sources, both src and test, the alias can be anything you want, such as ca, and the command will be Test / compile:

To execute this alias from the command line, you can run sbt ca, or in the SBT shell you can execute ca

I learned of this handy feature from someone's tweet(?) on X a couple months ago, and then shortly after discovered a fantastic write-up on baeldung.com. I'm not sure why the addCommandAlias isn't in the SBT v1 or v2 documentation, but it should be. It's a great feature. The command is hidden in the depths of the SBT GitHub repository.

Samples

The following sample aliases are from a Scala 3 project I'm working on. I love the convenience of quickly calling a short alias to execute multiple commands.

A big thanks to the SBT maintainers, such as Eugene Yokota, for all of the amazing work on this incredible tool. Thank you!

Dependencies

The following dependencies were used in this post.

• scala (3.5.2)
• sbt (1.9.7)

Setup

I constructed a crude coolant system for my desktop hobby CNC machine to keep the stock/part and milling bit cool during operation. It's overkill, but it solved a problem I had with the excessively high-speed router bits getting "gummy", due to heat build-up while milling parts.

To clean the metal chips from the coolant before it returns to the reservoir, I needed a reliable catch basin and filter. My first prototype helped prove that the coolant system worked, but it was prone to backups, overflows, and caused a lot of anxiety during operation. I was constantly monitoring the coolant levels because the filters were prone to clogging often and unexpectantly — very stressful.

The current filter setup is a collection of mostly off-the-shelf parts, and the assembly works well enough that I can enjoy long milling operations with minimal supervision.

The setup consists of a plastic laundry tub (legs removed), a small tray rack inside the laundry tub, and two mesh-bottom plant grow trays lined with fine nylon screen. The coolant drains through the bottom of the CNC table into the laundry tub below, where the filter cleans out chips before draining into the reservoir.

Parts

You can find most of these parts at your local hardware store. I had to order the mesh filter and coolant online.

Laundry Tub

The laundry tub is spacious with dimensions of 61cm x 56cm x 38cm / 24" L x 22 W x 15" D. The deep sides are great for containing splashes as the coolant drains through the CNC table onto the filters, and in the worst case scenario of a drain clog, the tub can hold a lot of liquid. I like that almost all coolant in the laundry tub will find it's way back to the drain hole with the sloped tub bottom. The filter trays fit inside the basin with ample room around the perimeters.

Where to buy: Home Hardware

Storage Bin

The storage bin is the coolant reservoir and contains a small submerged fish tank pump. The bin has dimensions of 73.7cm x 50.8cm x 39.4cm / 29" L x 20" W x 15.5" H, and has more than enough volume (102L) to hold all of the coolant. I actually only have the bin filled half way with coolant, because it's quite heavy to move when I need to slide it out from under the table.

A large hole drilled into the top of the storage bin lid was an easy way to secure the laundry tub and reservoir together via the drain. Multiple other holes were drilled in the lid for pvc pipe connections for pumps (spindle and circulation).

Where to buy: Rona

Seedling Plant Trays

The mesh bottom plant trays are perfect for drainage and holding the filter screen. The dimensions are 38cm x 30cm x 8cm / 15" x 12" x 3". Prior to finding these trays, I had tried drilling holes in paint trays, and I even made a feeble attempt at making a tray, but both did not work as well as these seedling mesh bottom plant trays. These are great.

Where to buy: Amazon

Filter Mesh

The main goal with the filter mesh is to clean as much metal from the coolant return as possible. My chip size varies from 20mm to 0.1mm, and probably smaller. When I use 3.18mm bits the metal chips produced are incredibly small. I decided to use a mesh that would filter anything I could see with the naked eye. I read somewhere (reference?) that 50µm (270 mesh count) filter will catch any visible particulate.

Before I discovered that helpful tidbit, I tried many different filters with a wide variety of properties. Metal screens with larger weaves, smaller screens that didn't drain, and numerous others. I found that a 50µm (270 mesh count) nylon filter drains well once saturated. A filter with a higher mesh count (smaller microns), doesn't drain fast enough, and a filter with smaller mesh count (larger microns) lets too much particulate through. This filter screen size is also surprisingly easy to clean with a brush, and fresh water.

I still haven't figured out the best way to secure the filter mesh to the tray yet, I'm just using tape for now. I might try sewing the filter with a drawstring so it can be secured around the tray and easily removed if needed.

NOTE: I'm uncertain if this filter mesh is also cleaning the coolant lubricant out of the water. This thought crossed my mind recently when I noticed my coolant lines looking really clear, when they should be green. I'm not sure if they are clear because I haven't added fresh coolant in over a year (probably), or if the filter is too good, or if the coolant is evaporating. I don't know at this time, I will report back. TBD.

Where to buy: Amazon

Tray Rack

To hold the filter trays, I used 2020 black aluminum extrusion I had laying around, and constructed a primitive tiered rack. Originally it was three tiers with varying filter screen sizes, but in the end settled on two tiers with the same filter screen size on both for redundancy.

I'd like to find an off-the-shelf alternative to the 2020 extrusion rack, perhaps a suspended sink drying rack. Something to hold the filter trays suspended in the air, or raised off the bottom of the laundry tub.

Wish List

I've only used this filter setup for a 3 months. It is significantly better than the filter prototype I was using previously — leaps and bounds better. Now that I'm not anxiously running my CNC worrying about coolant backups in the middle of a job, I've been taking mental notes of the minor drawbacks and annoyances I've noticed during operations.

• Tight coupling between tub and reservoir. Having the laundry tub and reservoir linked together originally seemed like a great idea, but the more I try to maintain and operate the system I see that it is a hinderence and needs to be changed for easier operations. Most of the challenges below are related to this coupling. I would like to move the reservoir to another area.

• Awkward to clean the filter. I need to pull both the laundry tub and reservoir forward to gain access to the filter trays. Then squeeze the trays out a narrow opening between the CNC table and the top of the laundry tub. I was originally planning to cut an opening in the front of the laundry tub for easier access, but it just didn't feel right at the time. I also have to be cautious when pulling the entire assembly out, because the reservoir is connected to the coolant lines and electrical wires. Not ideal.

• Difficult to monitor and adjust coolant PH levels. Opening the reservoir lid is really awkward and not practical at all, for all the reasons listed above. For the first time since I purchased GreenCut cutting fluid, I've noticed that my coolant lines are no longer green, so I ordered more coolant. When I received the new container of cutting fluid it had instructions for how to maintain the PH levels. I'm almost certain the original shipment from a year or two ago also had this, but I misplaced them and forgot. Now I'm trying to measure the PH levels in the tank and there's no easy way to do it. I need to be better at maintaining the coolant PH, and before I can do that I need an easy way to mix, measure and check without pulling the entire assembly out. Not ideal.

• Difficult to see coolant levels. I want to make a coolant level circuit to show what's happening inside the reservoir, but haven't got around to it yet. I have a fuel sending unit installed in the reservoir to determine levels from resistence changes, but I still need to make the actual circuit. At this time, I just hook up a voltmeter and measure the resistence during CNC jobs to periodically check on coolant levels. Not ideal.

• Submerged pump is not easily serviceable. There is a fish tank pump in the reservoir, a remnant from the original coolant prototype, that sends coolant to the spindle. The pump worked well enough that I didn't want to buy another pump when I made this new setup. I dislike having the pump inside the reservoir though. It's not a huge deal, but similar to monitoring the PH levels, I need to open the lid to do any pump maintenance. Lately I've been thinking that with all the other challenges listed above, it might be time to move the pump out of the reservoir — rethink the entire setup.

• Drain plug or shut-off valve. When the system is not in use, I'd like to be able to completely close the reservoir to prevent evaporation.

Try

I would like to try cutting fluid paper at some point, but I've only seen it available in large rolls. I would like a small amount to try before I go all in. It could potentially be a great alternative to the filter mesh listed above based on what I've read.

Add the following to your build.sbt file to resolve the dynamic loading Java agent warning:

Mockito Path

If you are using Mockito in your Scala tests (not mockito-scala) and you are on a recent JVM version (>= 21), you may have seen the following warning:

To fix this warning, you need to set the javaOptions for the test JVM in the Scala build.sbt file. You need to find where the Mockito jar file is located on your system. Use the byte-buddy-agent path in the warning message as a hint for where Mockito is probably located. This is the path mentioned in the warning:

In the maven2 directory, Mockito should be located at the path org/mockito/mockito-core/<version> which will match the dependency entry in your build.sbt file ("org.mockito" % "mockito-core" % "5.14.2"). For my system (macOS and SBT), the Mockito jar is located at:

Options and Fork

Open the build.sbt file for your Scala project and add the following to your Test configuration:

You will also need to add Test / fork := true to your build.sbt file. The result should look something like this:

In your SBT shell, reload the project, and re-run your tests. The warning message should no longer be visible. Woo hoo!!

Let's update the path so it's not hardcoded to a specific Mockito version. In your build.sbt file, create a value for the Mockito version number (val mockitoVersion = "5.14.2") and use the value in your dependencies:

Modify the javaOptions string to be an interpolated string (notice the "s" at the beginning), and add the Mockito version there too:

Let's also update the cache path to work for various operating systems, so it's not hardcoded to your system. To get the cache path we need to know which SBT key the value is stored under — it's helpful to know that SBT uses Coursier for managed dependencies, and the key is csrCacheDirectory. In the SBT shell, enter show csrCacheDirectory to see the path value:

You may recognize that path as part of the path you discovered earlier. To get the absolute path from this, you will use csrCacheDirectory.value.getAbsolutePath() in your java options string. Your final build.sbt file should look similar to this with all the changes you've made:

I hope you found this post helpful, and it resolved the dynamic Java agent warning message. If you have any questions, please reach out to me.

Dependencies

The following dependencies were used in this post.

• scala (3.5.2)
• mockito (5.14.2)
• sbt (1.9.7)
• java (21.0.5-tem)

Attributions

• The main post image was generated with Leonardo.AI, using the prompt "A rogue retro secret agent is spying and looking suspicious while sitting at an old fashioned computer terminal. No faces visible. Danger is lurking in the shadows"

Download PDF

Attributions

• The main post image was generated with Leonardo.AI, using the prompt "retro futuristic apparatus for testing software, shows abstract code with checkmarks for passed tests and X for failed tests, probes, complex systems"

Scoverage is a code coverage tool in Scala. It generates coverage reports to show you what branches and statements have been executed in your tests. Using the coverage flag will gather data about what code pathways were traversed in your codebase.

I'd recommend NOT using the SBT shell when executing the following steps. Assuming you have SBT and Scoverage installed, from the command line run the following:

Clean removes any artifacts in the build directory (target), Coverage enables the coverage flag for the compiler, and test runs the test suites. The data collected during the tests isn't friendly for human consumption and needs to be formatted in a more palatable way. To format the data, you need to generate a coverage report:

You should see the code coverage report summary in the terminal:

Awesome it generated a report! If you have limited, but not zero test coverage in your project, the summary should tell you the statement and branch coverage of your code base. If you have tests and you see 0%, make sure you are NOT running SBT shell. I find the coverage and coverageReports commands generate reliable results when not using SBT shell, eg. execute them direct from the terminal command line.

Minimum Coverage

If your code base has decent code coverage, consider setting the coverageFailOnMinimum flag along with minimum coverage requirements. This prevents the coverageReport from succeeding if coverage drops below certain thresholds. In your build.sbt file, add the following line somewhere at the bottom of the file, you can move it elsewhere in the build file if you want:

Just adding this line wont do much without minimum values. Below are the default recommended values from Scoverage documentation. Set the values to whatever works best for your project at this time.

Re-run the previous commands used earlier: sbt clean coverage test and sbt coverageReport. If you set really aggressive minimum values that are higher than your current code coverage, you'll see an exception in your terminal.

This is helpful if your team is still adopting test driven development, and they have a bad habit of adding code without tests — you'll know who broke the build.

HTML Report

If you need to consume the coverage reports in more detail, the HTML report allows you to browse line by line what code is covered. In your build.sbt file, near the previous line you added, add the following:

If you'd like, you can also set the output directory for the coverage reports by adding:

This will place all of the coverage information in the directory target/coverage. The default location buries the reports in target/<scala-version>.

Re-run the previous commands used earlier: sbt clean coverage test and sbt coverageReport. Open the directory target/coverage, there will be three new directories: coverage-report, scoverage-data and scoverage-report. scoverage-report contains the HTML output of the generated report. The index.html report file shows a coverage breakdown of the files found in the project.

Similar to other code coverage reporting tools in different languages, Scoverage allows you to click on individual files to see the line by line breakdown of what statements and branches are covered.

As of Scala 3.3.4 most major language features are supported in code coverage data. For-comprehensions were recently fixed in Scala 3.3.3 so almost everything between Scala 2 and 3 should give similar code coverage results now.

Dependencies

The following dependencies were used in this post.

• scala (3.3.4)
• sbt-scoverage (2.2.2)

Attributions

• The main post image was generated with Leonardo.AI, using the prompt "An ornate, intricately detailed logo in the style of vintage gilt tarot cards, evoking a sense of mysticism and mystique, with a Steampunk twist, featuring a bold, cursive script with subtle, distressed textures, reading "Scoverage" in a flowing, art nouveau-inspired font, surrounded by delicate, filigree-like patterns and ornate, gothic-inspired flourishes, set against a rich, dark background with subtle, warm golden undertones, reminiscent of antique, worn leather, with hints of copper and brass accents, and subtle, eerie flickers of candlelight casting an air of mystery and otherworldliness."

Using specific types for domain ids (eg. LocationId, EventId… etc) instead of generic UUIDs (Universally Unique Identifiers), is a great way to communicate intent to yourself, other developers, and leverage the compiler type checker. In Scala 3 there are several ways to implement domain ids and each has it's tradeoffs. My preferred approach right now uses opaque types and traits.

At compile time, the domain id (LocationId) will be type checked, and at runtime each domain id will actually just be a UUID. It's a slick little feature that has no overhead. It's more efficient than creating a case class that wraps the UUID. This approach does have a few hiccups that need to be addressed though — initialization and imports.

Companion Object

To initialize an opaque type you need a companion object with an apply method or constructor methods. For example:

The companion object allows us to initialize the id by calling LocationId.init, LocationId.fromBinary or LocationId(value) and all methods will produce a valid LocationId. If there are more than a couple domain ids, this initialization code will be duplicated all over. To minimize code, the companion object can be rewritten as a trait and generalized.

This is a cleaner solution, but there's still room for improvement when it comes to imports.

Wrap External Dependencies

It's seldom a good idea to liter the codebase with external dependencies, even if it is the JDK, such as java.util.UUID. I personally like to confine each external dependency to one file location in the code base, if possible. Wrapping an exernal dependency, whether it's a library, resource, or a function, allows you to maximize your control, minimize change impact and encapsulate code.

It does require more work to write the glue code, but I find it to be a worthwhile tradeoff in the long run. In this case, the wrapping code is just one line.

This may appear like an unnecessary layer of abstraction, but it is a step towards reducing imports and simplifying domain id usage for other developers.

Uuid Companion Trait

The final Uuid implementation encapsulates the Uuid methods and keeps the java.util.UUID type confined to one file.

Defining each domain id type is a lot less work now; one import and two statements.

Using the domain type is the same as before.

Hopefully this helps make your code more readable, type safe, and reduces your maintainable code.

TODO

• I would love to reduce the type definition and the object extension method into one statement. I'm not sure how to do that yet. Maybe using Scala macros? Not sure.

Attributions

• The main post image was generated with Leonardo.AI, using the prompt "Abstract painting representing category theory with bright colours and random numbers embedded in the background".

Summary

Using ZIO Schedule, I wrote a Scala 3 extension method to reset exponential backoff when an input predicate is true: resetWhenInput(f: A => Boolean).

Schedule

I am working on a project that requires multiple processes to continually chew through relational data, forever. The processes need to fire fast when there is data, and use an exponential backoff when there is no data.

Given the codebase already uses the ZIO library, I started exploring the documentation looking for recommend ways of working with long running processes. I discovered that ZIO has the ability to elegantly Schedule recurring effects, and this appeared to be the best path forward for trying to tackle this problem.

My first attempt at creating a naive forever looping process, looked like this:

The code when executed produced a never ending stream of Hello World. Certainly a step in the right direction, but it needed to be refined.

The schedule class contains many pre-defined schedules and combinators, such as recurs, spaced, exponential, zip, whileInput, andThen. Mixing these methods together produces a wide range of scheduling behaviours. My second attempt was almost exactly what I needed.

Note: the above code excludes the for-comprehension and loop code.

If you run the above code, at first glance it produces the desired scheduling behaviour, but there's a subtle issue with the exponential backoff - it doesn't reset when it encounters input data. The exponential backoff resumes at the last duration in state. This is the desired default behaviour for exponential backoff, but in the context of a loop, the state should reset when an input predicate is true.

The sample data and comments below illustrate where the exponential backoff should reset and increment.

The Schedule methods that would reset the exponential backoff on input data eluded me. The methods that jumped out as potential candidates for solving this problem were resetWhen(f: Out => Boolean) and resetAfter(duration: Duration). Using the output, or an arbitrary duration to determine when to reset the backoff wastes unnecessary time.

There is probably a way to pass the input data through using built in methods, but it wasn't clear to me how to do that. A reset that is based on the input data would be perfect — unfortunately I couldn't find one.

Extension Methods

I felt the need to write a function that would reset the exponential backoff when input data was present. Scala has an amazing feature called extension methods, formerly known as implicits. With extension methods any type already defined can have new methods added to it; this allows a method like resetWhenInput to be added to the Schedule type:

When extension methods are imported into a file they can be called using the dot operator on the instance of the type extended, for example: noDataSchedule.resetWhenInput().

The input should be a predicate function that takes an argument and returns a boolean, f(A) => Boolean. The input should also accept anything that is a subtype, conforms-to, or extends that type, [B <: A]. The new method signature looks like this resetWhenInput[B <: A](f: B => Boolean).

The extension method must also incorporate the generic Schedule types. Those generic Schedule types are [Env, In, Out]. Merging the predicate types with the Schedule generic types produces the following method signature:

Reset when Input

The final stretch requires digging into the inner workings of Schedule. There is a State type, initial state, and a step function. The step function is the most important part for determining whether to continue (step) or not. Essentially if the predicate is true, then use the initial state ("reset"), otherwise use the current state.

To verify this method works as expected:

Wrap Up

Adding the new resetWhenInput method to the exponential backoff produces the desired scheduling outcome. For convenience, I wrapped the schedule in a function for quick usage and easy testing.

Testing functions that deal with the passage of time can be a slow and painful process, but ZIO only describes the effects, so the passage of time can be adjusted. For example, to adjust the passage of time by 2 minutes in tests, use TestClock.adjust(2.minutes). This will give instant results, but the code will behave as if 2 minutes has passed. The clock adjustment is really helpful when testing long running processes.

In the sample data below, the first repeat doesn't take place until after the loop function has been executed once. Also important to know, the ZIO exponential function is defined as base * factor ^ n. With a base of 50ms, and a default factor of 2, the first no-data repeat will be 100ms (50 * 2 ^ 1 == 100) or 0.1s.

… and Voila! Green tests across the board. Writing this function didn't take very long, thanks to the great ZIO documentation, both on the web and in the code. In fact this blog post took 1,000,000 times longer to write than the function.

I hope some part of this code journey was helpful for you.

TODO

• reach out to the ZIO library maintainers and ask if there is an alternate way of solving resetWhenInput with just the built-in Schedule methods.
• If yes, update post
• If not, ask if this would be a welcome contribution to the library

Attribution

• The main post image was generated with MidJourney, using the prompt "abstract painting of charts depicting exponential growth with a plateau and drop".

Machine

In the Spring of 2021, I had an idea for a product that I wanted to make. After a couple shocking cost estimates and quotes from manufacturers to produce the idea, I decided to try and make it myself. One of the requirements to bring the idea to life was metal molds. I settled on aluminum because it met the heat specifications needed for baking the product and it seemed to be the easiest metal to work with on a budget. I decided that a small CNC (computer numerical control) milling machine would probably be the best option for making the aluminum molds.

The budget I had in mind for a CNC was roughly $1000 CAD (Canadian Dollars). I compared various CNC machines, and in the end settled on the SainSmart Genmitsu ProVerXL 4030. It's a desktop CNC that advertised it could mill/engrave aluminum. The final cost was a bit more than $1200 with shipping. The machine looked robust, had a decent work area, several upgrade options, there was a lovely community of people online, SainSmart had a good reputation, the company website was informative, and it could mill aluminum. It checked all of the boxes for me.

A lot to Learn

I was incredibly naive of what I was getting myself into; the amount of time, effort and learning involved to operate a CNC machine was a lot more than I anticipated. I knew the learning curve would be steeper than 3D printing, but I vastly underestimated how much I would need to learn in order to mill parts.

Many factors are required to create a successful part, such as: the rigidity of the machine, the spindle speed, holding the material, fixtures, the size of the bit, the quality of the bits, the type of stock, accuracy, datums, what certain sounds mean, zeroing, work coordinates, operating temperatures, feeds, 3D CAD modeling, and a multitude of things related to the CAM software that create the actual program for the CNC to follow.

Hands-on

I consumed as much information as I could — I read forums, I read books, I did tutorials, and I even watched videos of professionals and amateurs milling parts in various materials. The biggest leaps and bounds came from hands-on trial and error experience coupled with the knowledge I was soaking up from various sources. Those a-ha moments when I experienced the situation or scenario I read about, or a concept clicked in my head, those were pivotal learning moments.

I often found myself watching videos of how to do something on a machine that was 100x more expensive than mine, and it seemed easy with all the fancy features that machine had. When I tried to apply it to my own setup, things didn't map over. Not all of the take-aways were applicable, but they all contributed to my understanding in small ways. Many topics depend on the machine and it's capabilities, as well as the materials and skill you have with all of the above.

Experiments

While learning I lost track of my goal of milling aluminum, and for extended periods of time I went on unrelated tangents experimenting with various add-ons, such as a drag knife and laser cutter. It satisfied my curiosity at the time, but they were minor distractions.

Learning was chaotic and messy. I found myself throwing various materials into the machine to see what I could make, and also experimenting with how the feeds and speeds needed to be changed for different materials. I played around with milling wood and engraved a cutting board for two friends getting married. I enjoyed milling wood, but hated the dust and mess, it was awful.

Enclosure

Milling wood produced a lot of dust, and milling aluminum left tiny little flakes around my office. I'd occasionally find a shiny metal chip in my living room that had hitched a ride on the bottom of my foot. I purchased a dust boot to suck up any debris. It worked well to collect lightweight cut materials.

The shop vac was actually louder than the CNC machine. Running the vacuum for extended periods of time wasn't ideal and I soon learned that shop vacs are not designed for that use-case; I blew the motor on the shop vac and the smell of burnt materials filled my office.

I decided to ditch the dust boot and build an enclosure to keep the metal chips and any other materials safely contained. Nothing fancy, just a couple MDF panels glued and nailed together.

I added doors on the front and it worked really well for containing the mess inside the enclosure. After operations were finished, I would easily vacuum up the debris. I mounted a little web cam inside so I could see cutting operations while the doors were closed. Switching back and forth between the GCode being executed to the web cam footage was a blast. I got such a kick out of watching the machine making an absolute mess while bringing my ideas to life.

Spindle

As I refocused on my goal, I spent more time milling aluminum and exploring the feed rates and speeds that could work well for my machine. I struggled to produce parts at the rate and quality I wanted. The results were far below what I was hoping for. In fairness it wasn't all on the machine, as a big factor was the operator (me) and my understanding/skill with the tools I was using — as you can see in the photo below, that bit could be shortened significantly to reduce chatter. At the time, I didn't understand that, and the results I was getting were not what I had dreamed of. It was so slow and the goal of rapidly making parts felt so far away.

It wasn't uncommon for me to leave the machine running for 24 hours. Patiently waiting for tiny parts to be finished. Sometimes a mistake would happen half way through, and starting over was soul crushing. I wanted to push the feed rate faster and I needed to increase the cut quality, but I couldn't figure out how to do it with the current setup.

I did managed to successfully make the first version of two mold halves for the original idea I had, along with some other really basic parts, but it was taking a really long time to do anything. I was curious if a bigger spindle/router would help alleviate some of my pains.

The tiny 300W spindle that came with the machine was good to learn the basics and experiment with feeds and speeds, but my growing frustrations with the quality and durations led me to explore alternate options. One of the included options for the machine was a larger spindle holder, so I could add a more powerful spindle to the CNC.

I decided to upgrade the stock spindle to a 840W DeWalt DWP611 router with a 6.4mm (1/4") chuck. It was in my price point, and it was something I had seen others use in their setups online. At the time, had I known there was a difference between a router and a spindle, I would have gone a directly to a VFD spindle for rpm control, torque, reduced noise, and cooling.

More power

Very quickly it became clear that the extra cutting power was going to be a big win. The new router allowed me to vastly increase the feeds, speeds, and the quality of each part. Jobs that previously took 24 hours milling aluminum, now took 24 minutes. I was thrilled to see larger chips getting cut instead of little specs of aluminum.

One major downside of the router, I soon encountered, was I had to manually turn it on before I started a job; I'd reach into the enclosure, flick the power switch on the router, the router would spin up to high speeds, I'd close the doors, and then press start on the computer to run the job. This also meant that if something went wrong during a job, the router would continue to spin even though the controller had stopped the machine. Not ideal.

Not even a day later after installing the new router, I setup the machine to mill a new job, and I wasn't paying attention to my cut paths. My clamps were directly in the cutting path. The machine demolished one clamp and significantly chewed into the part before I realized something was wrong. Hitting the emergency stop button on the controller prevented the machine from advancing through the remaining clamp, but the router was still on and spinning, sitting flush against the clamp it had chewed half-way through. I shut off the router, and immediately started searching for solutions.

Relay hack is essential for a router

I saw that others had hooked up a relay switch from the CNC controller to toggle the router power and that was a reasonably quick fix (see blog post). That allowed the controller to start and stop the router just as it had done before with the stock spindle. Doing a similar modification to the speed control on the router wasn't something I wanted to do, nor spend time looking into.

Noise and Heat

The router is tremendously loud compared to the stock spindle. I felt self conscious running the machine now and worried my neighbours might hear it. Keep in mind this machine is in my home office in a townhouse. I added 5cm (2") thick styrofoam to the inside of the enclosure to help reduce the noise. It muffled the sounds, but it also insulated the enclosure and prevented heat from radiating out. It wasn't a major issue because I wasn't running jobs for extended periods, thanks to the increased cutting power. It did get warm in the enclosure, but not something I felt I needed to address at that time.

Another problem related to the extra cutting power surfaced. For the first time ever, I had aluminum melting to the milling bit. Possibly because my router was spinning too fast, not taking aggressive enough cuts, the cut aluminum was not getting cleared out of the cutting path properly, not being cooled correctly — maybe all of the above.

Coolant

I used compressed air to clear the cutting path, and that helped, but it didn't do much for cooling the bit. My router was spinning really fast (16,000RPM +) on it's lowest setting. The other downside with the air was the compressor was louder than the CNC machine, and it often would blow the circuit breaker causing the CNC to shut off.

Inspiration

What worked really well was occasionally spraying cutting fluid on the part being milled. It almost completely eliminated the aluminum build up on the milling bit. I'd crack open the enclosure doors while the CNC was running and spray cutting fluid on the part. It was terrifying to stand there with the doors open, putting my hands near this cutting contraption. Just imagine sharp aluminum chips flying towards you, fluid spattering all over, wincing and cowering behind your safety goggles for fear that a bit spinning at 20,000 RPMs might break off and find it's way into your body. It was the last thing I wanted to be doing, but it was working.

The sporadic nature of when I would spray the cutting fluid on the part, wasn't consistent enough to produce reliable results. It was too hands on, prone to error, and once again I had metal chips creating a mess on the floor. Every time I opened the enclosure doors I wondered if there was a better and safer way. I had seen videos of professional machines using large quantities of liquid coolant flooding the part, and that's what I wanted to try. That looked like something that could run continuously with minimal input from me. I wanted to be hands off with the doors closed. I began brainstorming how I could seal the wooden enclosure for using liquids (link to blog post).

Will it work?

I wasn't sure if this idea would work with my machine, so I tried to keep expenses to a minimum. I lined the interior of the enclosure with 3.2mm (1/8") plastic sheets - thinner would have also worked. Overlapping them where I could so liquids wouldn't get out. I used a heat gun to shape the plastic underneath the cnc machine, forming a primitive a basin that would drain towards the center. I regretted using the plastic as soon as started trying to shape it — it bent, warped and expanded in ways I couldn't anticipate.

If I hadn't spent so much money on the sheets of plastic I would have tried using metal instead. I added a PVC drain to the center of the table, and from there the liquids would pass through a filter underneath, and into a reservoir. A fish pump in the reservoir then pushed coolant up through a series of clear flexible tubing to the CNC spray nozzle.

Filters

The chip filter underneath the CNC was made of random kitchen supplies cobbled together; a strainer and a metal salad bowl with a hole drilled in the bottom. I added an inline water filter from the hardware store, to capture smaller partciulate before it got back to the reservoir. I connected it all together with PVC pipe, plumbers putty, thread tape, and PVC glue. No duct tape, but I think MacGyver would be proud. It's the ugliest damn thing I've ever made, and I'm embarrased to share it, but it was perfect to experiment with. I tested all the connections with small buckets of water, fixed any leaks, and then quickly jumped into full operation with bio-lubricant.

It works, sorta

My budget coolant setup worked well enough that I could see and hear differences in the cutting performance. I no longer had aluminum getting gummy on the milling bits, I wasn't opening the doors to fiddle with the machine, and the machine didn't seem affected by all of the liquids spraying everywhere. I made little splash covers to protect the limit switches and provide a roof over the router and steppers motors. I added a second relay switch to toggle the coolant pump when the router was turned on and off. I added additional metal kitchen mesh to the top of the salad bowl to filter chips before they reached the inline filter.

I kept using this setup for the better part of year, despite a number of mishaps. The biggest pain was after 30 or 40 minutes of continuous operation, the inline filter was prone to getting clogged and caused coolant to overflow the sides of the metal bowl. Turns out, I incorrectly placed the inline filter and the low pressure flow wasn't ideal. Unfortunately once I realized my mistake I was already designing the new coolant system, so I left it and suffered for a period of time.

I once made the mistake of closing the enclosure doors for a couple weeks and when I came back and opened the enclosure, it was incredibly humid inside, and a lot of the CNC parts looked corroded — screws, the shaft of the router, and other random parts. No airflow inside, coupled with the residual coolant on the walls wasn't the ideal environment for certain metals.

The coolant setup has introduced a new anxiety to my CNC operations - a fear of overflow. I quickly added a secondary power switch for the coolant pump, so it could be manually shut off during jobs. The constant monitoring of coolant levels, and toggling the coolant pump off and on as needed to maintain levels, is annoying and stressful. I briefly enjoy hands off operations for the first thirty minutes of a job, but after that it is full time baby sitting. There is definitely room for improvement.

Next Steps

This hacked together hobby setup is less than perfect, but it works for now. I love that I can make metal parts on this inexpensive machine, but I also struggle with it's limitations.

• update chip filters — this will allow for longer operating periods, less anxiety, more fun and joy [DONE]
• circuit for detecting low and high coolant levels [IN PROGRESS]
• add a separate pump and circuit for manually cycling the reservoir liquid [DONE]
• move the hose line to the second pump, use a recoil hose and spray nozzle [DONE]
• air blast hose for cleaning parts coming out of the machine [IN PROGRESS]
• replace the T-tracks with a large fixture plate / add large fixture plate [DONE]
• airflow in the enclosure
• replace all of the chasis screws [IN PROGRESS]
• replace the semi-open plastic reservoir bin with a sealed container [DONE]
• update the controller board for coolant control
• door alarms
• 4th axis
• move all electronics into a new box
• add more structural support to the machine for rigidity
• consider using heavy duty linear rails with carriage blocks
• add more height to the Z-axis
• replace wood enclosure (water damage) with metal, open bottom with generous slopes for drainage and chip collection
• slide doors open or up — swing doors drip coolant on the floor or chips fall out
• larger workarea
• removable side panels for larger pieces, or maintenance
• have thick safety windows on the enclosure to see inside
• replace router with water cooled VFD spindle — more power and bigger chuck - quick change would be ideal
• tool height probe
• offset library for tool changes
• add an auger for chip evacuation

Scala 3

In Scala 3, given and using replace the original implicit object and implicit, respectively. Define the implicit object with given and specify where it can be used with using.

Scala 2

Define the implicit object and override the trait methods.

Full Scala 3 Example

Output

Unplug and sit in silence for 1-15 minutes: intention, focus, connect, insight, inspired action. Do after showering.

Happy Hour

For 60 minutes, focus on advancing a personal project; develop, design, create. First thing in the morning.

Try-It Tuesday

Dedicate 1-60 minutes to trying something new, or improving a skill; try a tutorial, reflect, write, repeat. Fusion 360, Photoshop, Scala, CNC, Sewing, Cooking, etc.

Writing Wednesday

For 1-60 minutes write. Topic ideas: learned about, proud of, worked on, a challenge, success, failure, book review, scared of, childhood, goals, ideas, etc.

Semana Social

Connect in-person with loved ones. Go for a walk, enjoy a glass of wine, host games nights, experience an activity, try something new, cook dinner, etc. Get together, face to face.

Read Regularly

Read at least 1 page or more before bed. Aim for 1 chapter. Balance the fiction and non-fiction. Stretch my body while reading.

Fresh Friday

Cold plunge in the lake, balance in hot yoga, walk up a mountain, work from a coffee shop or a library.

Gratitude Glow

Every Sunday at lunch, write down as many great or funny things that happened this week. Put it in a jar. Fill the jar.

Stair Squats

Every trip up the stairs requires six deep squats, six calf lifts, and six step downs — as much weight as possible.

Requirements

To accurately calculate shipping costs for Brown Hockey customers, I needed a bin packing algorithm that could take a list of products, and determine an efficient, human executable, packing solution given a set of fixed box sizes. Preferrably this algorithm would be written in TypeScript or JavaScript, so I could easily drop it into the website code base. Many of the solutions I found on NPM were old, defunct, unmaintained, and/or did not have test coverage. The one package that stood out in the JavaScript pile was BinPackingJS.

BinPackingJS had good test coverage, it supported 2D and 3D bin packing, it wasn't too old (last updated two years ago), it had a number of maintainers, decent weekly usage, and a few stale pull-requests. It was the best solution I could find in JavaScript and I hoped it would work for my needs.

Close, but not quite

At first glance, the package passed all of my simple bin packing tests, but more complex test cases highlighted its short-comings. The package appeared to lack the ability to minimize the quantity of bins used, it seldom found the smallest bin for an item, and if more bins were needed it didn't add them.

While testing the package, I started to realize I was probably not using the package in the way the original authors had intended. I needed a bin packing solution that minimized bins used, found the smallest bin for the packed item(s), and added bins until all items were packed. As it was, the package wouldn't meet those needs.

Leveraging Strengths

I have been spoiled with the quantity and quality of packages available these days, and instead of initially deciding to work with the package as-is, I opted to continue searching for alternative solutions. Once again, I came up empty handed. I could see that other people were running into similar issues as me, and alternative packages were popping up, but none solved any of my problems, or they were lacking essentials to be trustworthy enough to use in production. BinPackingJS was still the best solution for the language I was working in.

I reluctantly decided to try and modify the behaviour of the package. I encapsulated the package to protect my project from any unexpected package changes. I kept the original unit tests I wrote, added simple value types, and charged forward with hope that I could improve the bin packing results. The first iteration simply added more bins if there wasn't enough. It was very crude, but it solved a bin test I had.

This ugly first attempt gave me the confidence to push forward. It did not thoroughly solve the "add more bins" problem, but it was a stepping stone to solving other problems. The code quickly exploded out of control, as I wrote a lot of unnecessary code, while attempting to wrap my head around this problem. I moved the packing strategies from the BinPackingJS wrapper into their own file to keep things simple. As I wildly explored the solutions my brain was suggesting, I began to slowly understand the strengths and weaknesses of BinPackingJS.

The package handles rotating and limiting the weight of items for the bin really well. It was good at packing one bin and multiple items, or at least good enough for my needs. Building around the idea of "one bin at a time" felt like the next logical step.

Better fit

Optimizating bin sizes was important to get the best shipping costs for Brown Hockey customers. The BinPackingJS package would often put items in bins that were excessively large. I began by brainstorming and visualizing the steps I might take to pack a bin (corrugated box) in front of me. Such as:

1. Grab a bin
2. Put item in bin: Is item too big? Is bin too big?
3. Try another bin size

This exercise coupled with my basic understanding of BinPackingJS' strengths helped me to focus on iteratively packing one bin. I cobbled together a recursive solution of finding smaller bins for the packed items. My conditional logic was flawed in the smaller bin comparison, but I didn't notice it until much later.

Early versions of this code stopped at the first smaller bin found. I quickly realized that in some cases an irregular shaped bin could often fit fewer items than a smaller bin. For example, a long skinny rectangle could be the largest volume but it might only fit certain items. The code was changed to traverse down the entire list of bin sizes.

Add more bins

At this point in the project I wanted to cleanup my original attempt at packing multiple boxes. It was ugly and unnecessary.

I was feeling very positive about my progress, because most unit tests were passing, except for the last one. It was a contrived example, but it was a packing situation I knew would come up, and if I didn't solve it now, it would plague me later on.

As I dug deeper into the failing test, I realized there was a simpler subset of items and bins in my contrived example that would cause a failing test. It was a subtle packing issue that gave terrible results.

There was a lot of head scratching at this point, but I was determined to figure it out. I struggled to understand what was wrong with the code. I mentally stepped through line by line, and everything appeared to be doing what I expected. I went through all the code multiple times, and it wasn't until I sat down with a piece of paper to track the output of each packing iteration when I finally saw the glaring issue.

The smallest box comparison wasn't taking into account the volume used, or more specifically how much volume was remaining in the current solution compared to the previous solution. It was only comparing the current and previous bin manifest and unfit item counts. I added a property for bin volume, and modified the comparison for smallest bin:

… and Voila! Green tests across the board. It was a moment of rejoice and delight for me. I had taken multiple stabs at the bin optimization problem sporadically over a few days and I was getting frustrated with the lack of progress in the last leg of the journey. It was nice to sink my teeth into this problem and see it through to completion. I'm very excited to integrate it into the shipping cost estimator for Brown Hockey

TODO

I have one more bin packing strategy I would like to explore, and then I'll make this solution available to others:

• Publish a public repo of the code [DONE]
• Publish my first public package on NPM
• Connect with the BinPackingJS crew and chat about contributing, eg. add type definitions, add packing strategies, update documentation

Attributions

• The main post image was generated with Leonardo.AI, using the prompt "1930s old fashioned film grain, stacks of corrugated boxes of various sizes with focus on single corrugated box sitting on the floor not in a stack, shipping container interior"