Multi-material 3D Printing with Palette+

Posted on 2019-06-09 by M. Eric Carr

Hobbyist 3D printers get more capable each year — and generally, these advances come in the form of potential upgrades or add-ons. The modularity of Prusa-type FDM printers means that just about any part can be swapped out and replaced as needed.

Until recently, hobbyist 3D printers have been nearly all single-extruder devices, capable of printing with only one material at a time. Multiple-nozzle extruder schemes exist, from a basic dual-extruder setup to exotics like the four-nozzle, water-cooled Kraken (which looks awesome but is worthless unless a viable toolchain exists.)

The four-extruder, water-cooled Kraken.

These come with their own problems — mainly ones of calibration. If the extruder has more than one nozzle, the nozzle tips must always be at exactly the same Z offset. Otherwise, the lowest nozzle will inevitably drag across the printed plastic deposited by the others. X and possibly Y offsets must also be set — but this is easily handled in software.

It would be nice if a single-nozzle solution existed — and now, it does. The folks at Mosaic have come up with one solution to the problem — create a custom-spliced filament and feed it into an unmodified 3D printer.

Note: The Palette+ referenced in this article is last year’s model. The new Palette2 and Palette2 Pro do the same job, but with some additional refinements. They also cost less. Progress!

A sample of custom-spliced filament made by the Palette+

This is a subtler process than it seems at first. 3D printers vary slightly in the rate at which they use filament in a given print. This can even vary somewhat throughout the print. If a single extruder is used with a variegated feedstock and you want nice clean color transitions in your print, the color transitions need to be at the right point in the filament so the new color comes along just as the printer is getting ready to print a feature in that color. If the amount of filament actually used (as opposed to commanded) isn’t tracked by some closed-loop process, the position of transitions will inevitably drift, leading to increasingly inaccurate color transitions.

Worse, when the filament changes from one color to another, the process takes some time — longer if transitioning from dark to light filaments, shorter if transitioning from light to dark (generally speaking). Even if the color transitions happen at exactly the right locations, the change will generally be gradual and smeared, as the plastic in the hot end is gradually replaced.

Transition towers (or other purge methods) help with this.  When transitioning between colors, the material near the transition is deposited into a sacrificial tower or block. This unfortunately wastes a lot of plastic, but it does ensure clean transitions as long as the transitions happen at close to the right time. The color smearing happens — ideally — on the transition tower, and not on the part being printed.

A (short) transition tower. (Corresponding part not shown.)  As partial compensation for the extra plastic and time, some of these are genuinely beautiful.

The “secret sauce” to producing custom filament and transition towers involves two key parts: an autosplicer and custom gcode-processing software.

To combine up to four different filaments into a single stream, Mosaic’s Palette+ autosplicer uses seven stepper motors, a heater block, various sensors, a microcontroller, and custom-machined guides to precisely cut and splice the filament as instructed by the Chroma software. Four filaments enter; one combined stream leaves. It’s over-engineered as hell. This is not just engineering, but art. Fittingly, it’s housed in a very solid enameled stainless-steel case. Just don’t drop it on your foot. It’s a beast.

The Palette+ autosplicer, with its cover off.
(Image from Hackaday.com)

As an example of how the process works, here are the steps needed to produce a four-color print, using Sketchup for modeling and Simplify3D as the slicer.

The first step is to produce separate .stl files for each material of the process. These .stl files should not overlap geometrically in any places (since two different materials can’t occupy the same point in space.) Support requirements apply to the union of all of the materials, however. It’s OK if parts of one or more colors appear to be floating in midair, as long as they will be supported by other colors in the final print.

The four pieces of the model, separated.

These separate models are then made into groups and brought together in their correct final arrangement. This gives the resulting .stl files a common origin, so they can be easily combined in S3D. (One trick is to create the files with a uniform spacing of something like 50mm or 100mm, so moving them back when done is easy.)

The pieces of the model, with a common origin point.

The four models are then exported, one at a time. It’s a good idea to label them with the intended colors at this point, since the next step is to assign a separate process (and tool) to each of the models. This is what will tell Chroma which filament to use for which part. The printer has only one extruder, of course, but Chroma will use the tool information to know when the color transitions happen.

Next, the four models are imported into Simplify3D. They will probably be lined up in a row. Hold Shift and click on “Center and Arrange,” and they will all snap to the center. Make sure they look like they are correctly aligned, with no missing pieces.

Checking the fit in Simplify3D. (Those holes are intentional.)

The next step is to create four (usually identical except the tool number) processes in S3D. These should each use a different tool for the extruder (usually, 0, 1, 2, and 3 respectively.) I like to keep the rest of the settings the same. You especially should match layer height, bed temperature, flow rate, and other settings which could cause incompatibilities.) Assign each process to exactly one of the models with the “Select models” button at the bottom left of the dialog box. When all four are done, preview the print and choose to color by process/tool. If it looks right, save the .gcode file — but don’t hit Print just yet.

S3D preview, showing the four processes.

Now the first step is done — but we still need to make the transition tower and calculate the lengths of the splices for the Palette+ autosplicer. This is done in Chroma — special postprocessing software created by Mosaic for the Palette+ and other splicers.

In Chroma, click on Load Model and select the .gcode file you just made. Chroma will pause and analyze it for a few moments. When finished, it will display a preview of the model plus a transition tower. Clicking on the colored circles next to the four material selections at the top will allow you to change the colors of the model. (These serve to inform you and Chroma which colors are which — you, so you can load the correct filaments, and Chroma, so it can estimate how long the transitions need to be, based on the starting and ending colors. The splicer itself can’t tell colors or materials apart; differences are specified here manually.)

Planning the colors and transition tower in Chroma. (The same size tower can serve for multiple copies of a part.)

This not only helps you visualize what the final print will look like, but gives Chroma some information about how long to make the transitions. Going from light to dark filament happens quickly, for instance — but going from dark to light can take more time, as the darker color is visible for much longer.

When you click Save for Printer, Chroma will output two files: a file ending in .msf for the Palette+ autosplicer, and a modified .msf.gcode file to be printed. The .msf file is loaded onto a SD card to be put into the Palette+, since the Palette+ only has USB support for firmware upgrades, and is basically a standalone unit. Once the SD card is loaded and the file is selected under the Multicolor menu, the Palette+ will start producing filament after a few minutes’ warm-up time.

The .msf file goes on the Palette+’s SD card. Print the new .msf.gcode file, not the original one!

The .gcode file needs to be printed as usual — via SD card or Raspberry Pi or whatever. Simplify3D can still be used to preview the print in real time, provided you reload the new .gcode file using the “Preview .gcode file” option in the File menu. (The .msf script file controlling the autosplicer will expect the extra usage from the transition tower, as well as the included commanded pauses, so don’t print the original .gcode file.)

Once the .msf.gcode file is ready to print, the filament is loaded into the printer, passing through a distance measuring device to precisely monitor filament usage. The Palette+ will guide you as to the correct length of filament to feed into the printer. It will also judge how good a job you do; apparently an 0.3mm loading error (well within tolerances) is “Superb” loading. (I think I recall it deeming some of my first tries merely “acceptable.”)

The printer and splicer will then work together to produce the right lengths of each color of filament: calibrated pauses are built into the .gcode, causing the printer to periodically stop using filament for a few seconds at a time. The Palette+ detects this and uses this information to keep track of where the printer is in the print. It then adjusts the amount of filament produced so the transitions happen where they should.

The coin and its transition “tower.” (These are always the same height as the last color transition in the model.)

The process is definitely more involved than for single-color prints, but the results can be impressive.

Benchy Of Unusual Size.

It’s a surprisingly reliable process, if a bit complicated. Once I figured out that the filament has to stay dry in order to splice reliably, the Palette+ has been one of the most reliable parts of the printing process. (The new Palette2 does have USB control capability when used with the new Palette Hub.)

Happy printing!

Posted in 3D Printing, Reviews, Tools, Toys | Tagged , , , , , , | Leave a comment

Component Tester

Posted on 2019-05-31 by M. Eric Carr

The microcontroller revolution has accelerated the development of tools available to the electronics industry. Multimeters (recently, DMMs) and oscilloscopes (recently, DSOs) have been a staple of electronics workbenches for decades, along with signal generators, frequency counters, and other specialized tools.

All of these tools, however, have generally been made to make measurements of basic quantities — voltage, current, frequency, or perhaps subtler measurements like capacitance or even complex impedance, in the case of LCR meters. The intelligence has always been, ostensibly, with the operator.

Automated component testers.
Definitely not your father’s multimeter. (His required some skill to use!)

Tools like automated component testers are starting to change that. Instead of having to know what a particular component is and find the right instrument or come up with a test procedure, these devices help play detective for you. Connect a mystery component across two or three terminals, lower the latch, press the big blue button that is literally the only control on the unit, and it (usually) tells you what the component is, which terminal is which (if it matters), and even the specs.

For $15 or so, it would be a cool little device if it just did resistors; this kind of form factor can be convenient. But so far, I’ve seen it identify not only resistors, but diodes, FET and BJT transistors, capacitors, inductors, and (unreliably) combinations of two or more of the above, such as diode-plus-resistor combinations.

For components like diodes, it will give a good estimate of the forward voltage drop as well as the capacitance, which is easy to forget about until you wonder why your LED is acting like a capacitor.

Not just “it’s a diode,” but forward voltage and capacitance
(as well as which terminal is which — useful on some of the weird ones!)

…and knowing modern tech, there’s a good chance that it started life as an Arduino project.

Posted in Analog, Components, Electronics, Reviews, Tools | Tagged , | Leave a comment

NodeMCU

Posted on 2019-04-30 by M. Eric Carr

New toys are always such fun, especially when you find a replacement for a component that has more features, better specs, and costs half as much.

The Arduino Uno is deservedly popular. It makes introductory embedded system design easy, and has introduced millions to the fun of open-source projects. Generic versions are available for as little as a few dollars, and even the cheap ones generally more-or-less work okay. (Brand-name Arduino Unos cost more, but you’re paying for reliability. They just work.)

The Uno, however, is starting to show its age. It runs at 16MHz, which is adequate for most hobby projects but nothing exceptional. It has a popular-but-still-weird shield scheme, which works only because the Arduino ecosystem is so huge that there’s just about every kind of shield you can imagine and then some. And it’s still relatively expensive, for what it is — connecting it to the outside world still usually requires a computer or at least an expensive and not-very-capable WiFi or Ethernet shield.

Enter the NodeMCU…

A NodeMCU 1.0 dev board

The NodeMCU 1.0 solves many of these issues. The NodeMCU is an ESP8266-based, Arduino-compatible dev board. Once you download the USB drivers and Arduino core, it can be programmed with the Arduino IDE. In addition, it’s breadboardable, has onboard WiFi, and costs roughly 1/2 to 1/3 as much as the Uno.

It also has better specs:

ItemArduino UnoNodeMCU 1.0
SRAM
2kB128kB
Flash ROM32kB4MB
Clock speed16MHz80MHZ/160MHZ
Usable I/O1813

It is a 3.3V part, so some designs may need to be modified. (3v3 is really the future of hobby electronics, anyway.)

Posted in Arduino, C, Digital, Reviews, Tools, Toys | Tagged , , , , , , | Leave a comment

Recursion

Posted on 2019-03-27 by M. Eric Carr

“To know recursion, you must first know recursion.”

(Original author unknown)

Much of the fun of writing code is learning about all of the various algorithms and techniques that help get the job done. Some of these are relatively straightforward: if (this), then (do that); while (this is true) then (keep doing that), and so on.
It’s what makes the magic work.

One of the more interesting techniques is recursion. Analogous to mathematical induction, recursion involves using the function being written in part of its own definition. This sounds not only unintuitive but unsound — but it turns out to be mathematically rigorous.

Computing factorials is a straightforward task that can easily be done either recursively or non-recursively. X factorial, written as X!, is (for integers) the product of all integers from 2 up to X. So, 5! == 5 * 4 * 3 * 2, or 120. (Factorials get large very quickly.)

Writing a FOR loop is one way of computing the factorial (and probably the best way, since recursion doesn’t buy you much here). To implement this, you would simply multiply the integers between 2 and X, inclusive:

int factorial(int num){
    int n, result=1;
    if(num < 2){return(1);}
    for (n=2;n<=num;n++){result *= n;}
    return(result);
    }

This works well and doesn’t have the overhead associated with recursive calls, so it’s efficient, as well. A recursive approach, while less efficient, is instructive — especially since it’s so concise:

int factRecurs(int num){
    if(num < 2){return(1);}
    return(num * factRecurs(num-1));
    }

You could even make it a one-liner, using the ternary operator:

int factR(int num){return((num<2) ? 1 : num*factR(num-1));}

That’s it. That’s the algorithm. We tell it how to handle the factorial of 1 (or less), then how to handle N!, given that we know how to compute (N-1)!. It feels like cheating, but it’s sound.

If factRecurs(3) were called, for instance, it would call factRecurs(2), which would call factRecurs(1), which would return a value of 1. factRecurs(2) would then multiply this by 2 and return it to factRecurs(3), which would multiply it by 3 and return the correct answer: 6.

The “Towers of Hanoi” puzzle is probably the best-known “poster child” problem for recursion. There is a nonrecursive formula, but it’s unintuitive.

“Towers of Hanoi” is a puzzle consisting of a stack of discs of increasing diameter, and three piles in which they can be placed. The puzzle starts out with the discs stacked in order from largest to smallest in one pile; the goal is to move them to another pile, by moving only one disc at a time and without ever stacking a larger disc on a smaller one.

A wooden, 8-disc Towers of Hanoi puzzle. (255 moves to solve.)
(Image credit: Wikipedia)

The optimal solution, produced by the recursive algorithm, takes 2^N-1 moves for a pile of N discs. (One move with one disc; three moves with two; seven moves with three, etc.) Surprisingly, a pile of any size can be moved according to the rules, given enough time.

The recursive algorithm may not be obvious at first, but once it is understood, it almost feels like cheating — yet it works. The base case is, of course, moving one disc. If our function is called to move one disc from one pile to another, it simply prints out that move. (We could include a move legality check, but as it turns out, we won’t need to.)

The question arises of what to do when presented with more than one disc to move. The recursive Hanoi algorithm’s answer to this is that this is really the same problem we’re trying to solve, so we will just assume we know how to solve it!

The recursive case of moving N discs from A to B goes like this:

* Move N-1 discs from A to C;
* Move one disc from A to B;
* Move N-1 discs from C to B.

It seems too simple to work — somewhat like Douglas Adams’ story of how the Infinite Improbability Drive was created by someone simply figuring out how improbable it would be for one to appear, then giving a Finite Improbability Drive a cup of really hot tea. It shouldn’t work — but it does. (And it’s mathematically correct.)

And it turns out the Towers of Hanoi solution is even related to Sierpinski triangles.

Posted in Algorithms, C, Coding, Math | Tagged , , , , | Leave a comment