Archive for Quick Tips

Power management in battery applications is pretty tricky. There are a lot of different situations, and a lot of different strategies. In the past, for the topic of this conversation, single cell Lithium polymer batteries, I’ve used a pair of Schottky diodes to automatically “select” the highest voltage feeding the system. That will be either 5V USB power, or 3V-4.2V LiPo battery.

It was suggested to me to use the body diode of a P-Channel MOSFET, but I dismissed that as unnecessary: the body diodes have no lower voltage drop than a Schottky, around 0.2V. Here is one of the more readily available results for battery/wall-power switchover:

That thread doesn’t make a good case for the FET solution over the diode, but the initial suggestion to me indicated that, once “on”, MOSFETs will conduct current in either direction. This breaks my understanding of how they work, but it warrants more research.

Stack Exchange posts don’t make for good engineering, though. This calls for a simulation!

Initial results check out! Those output waveforms on V(out) and V(out2) should be identical, if the current through M1 was purely through the body diode.

Simplifying this even more, we can do this:

That results in the following waveforms. You can clearly see the shoulder in V(out3) (blue), where the MOSFET transitions from conducting through the body diode, to conducting through the transistor junction itself:

That’s pretty conclusive. It’s weird to find gaps in my understanding of basic electronic building blocks at this point, but I’m always on-board with more education.

So now this is a documented solution at handling the power switching circuitry between USB and lithium batteries.

In the future, I should put together a written record of the strategies for charging the LiPo batteries in the circuit, and also low-voltage cut-offs to avoid over-discharging and permanently damaging the batteries.

Some investigation revealed that in MPLAB 8 and before, they didn’t used to properly check for “correct” voltage before attempting to continue programming. Which is great! But they fixed that.

Here’s the message it displays:

PICkit 3 is trying to supply 3.250000 volts from the USB port, but
the target VDD is measured to be 2.875000 volts. This could be
due to the USB port power capabilities or the target circuitry
affecting the measured VDD.
The target circuit may require more power than the debug tool
can provide. An external power supply might be necessary.
Connection Failed.

Cracking open the case reveals that it’s made by Sure Electronics, and there was possibly some nebulous licensing deal with Microchip to sell these, and then they got cloned and the deal evaporated. Or something. It’s hard to tell.

I had a sneaking suspicion that there was a bad voltage divider somewhere that was causing ADC readings to come back too low.

Before having to properly poke around, this post confirmed my suspicions and made things super easy.

Near the linear voltage regulator, the AMS1117, there are two resistors named R17 and R24. They are 470 and 680 ohms, respectively.
Swapping the 680 ohm resistor with a 750 ohm is recommended. I didn’t have one, so I desoldered one leg and put a 50 ohm resistor in series, making kind of a tower on my board. Results in 730 ohms, but it seems to work. My PicKit can provide power again!

A lot of the switch-mode power supplies I’ve built have relied on Skyworks Technologies controllers. This is because they are very cheap, and seem to go obsolete almost immediately after purchase.

This is a quick story of bringing up a new switch-mode circuit from a different manufacturer to test its viability in some battery-powered devices.

I’m using a Richtek RT6150A buck-boost controller.

For a 3.3V output, buck-boost topologies are necessary when the input is a LiPo battery. The ~3.0-4.2V safe voltages for charge and discharge are perfectly bracketing the 3.3V target in a way that is about as inconvenient as possible.

Other than cost, the reason that I selected this chip was that it seemed marketed towards this exact application. Battery technology is written in the advertising materials, and the datasheet shows this:

Oh yeah, perfect! An undervoltage cutoff. That should be good for LiPo protection.

so I drew a schematic like this:

And then sent it off as a one-off PCB through OSHPark.

It costed about a dollar.

I got it back, soldered it, and did a quick bench-test. Instead of cutting off at 3.3v like I intend, it didn’t turn on until close to 5v.

No good!

So I pulled out the scope and checked the voltage at VINA:

The input voltage was completely stable, so that wavy portion in the middle of the voltage divider wasn’t coming from the input.

Going back to the datasheet:

This was ambiguous, but hindsight tells me it’s not actually intended to be a voltage cutoff. This is just the power for the control circuitry itself.

What was happening was that the internal control circuitry was drawing enough current that the voltage at the middle of the divider sag enough that it hit its cutoff, and turned the chip off, making the voltage rise enough that it turned on again, etc.

This chip is advertised in Richtek’s appnotes as being good for LiPos because of that cutoff, I assumed, but it doesn’t actually work!

So, I bodged VINA to VIN, and now it works, albeit at the full range of the chip. That’s not exactly what I want.

The other thought is to use EN as the cutoff.

It’s supposed to shut the chip off at “logic level low” whatever that means for a wide input voltage chip.

Logic level is anywhere from 1.4 to 1.8v, which is annoyingly wide.

But I gave it a shot.

Some test results:

Channel 1(Yellow) is output, 2(Teal) is the EN pin, and 3(Purple) is the input voltage.

At 1.11V input, output is still disabled.

At around 1.59V, the output springs up to 3.24V:

Weirdly, as the EN pin gets closer to the theoretically 1.55-ish point where it’s supposed to turn on, output noise starts to hugely increase:

Until right at the logic level high point, the output voltage has almost a full volt of non-periodic, constant noise:

It’s possible that it’s not a coincidence that is right when the controller switches from boost mode to buck mode.

So again, let’s bodge this back into a manufacturer-recommended specification:

Replacing R3 with a 0-ohm resistor (or: a wire) gets this back into spec:

In this case, the output (teal) is still disabled until the input(yellow) starts to hit 1.50V.

From there, there’s a sudden switch-on at 1.56V to 3.2V output:

And it quickly rises to a 3.3V and stays there for the full range, up to 5V input:

Output ringing is a periodic 1V peak-to-peak for about 20ns, every 1us or so. This gets a little lower when the output is loaded and provides some damping.

So the moral of the story is that the Richtek RT6150A works quite well, but only when the datasheet is closely adhered to. Anything “interesting” in the design leads to unacceptable noise or unpredictable results.

In the meantime, the RT6150A seems to be on the way to phasing out. Stock on Digikey is 0, with a 16 week lead time for new parts. The catalog not-so-subtly hints at using the RT6150B variant, and the datasheet is almost identical. The glaring differences are a few added lines in the marketing copy on the first page saying that fixed 3.3V operation is possible by tying the feedback pin directly to the output.

Anyway, that’s my debugging story. Nothing was particularly novel or unusual, but it was a good process to document irregularities while abusing the chip.

TLDR: I wrote an Inkscape extension to make my life a little bit easier when designing assemblies with laser cutters.

For the most part, I avoid using 3D printers while rapidly prototyping. Until very recently, they have been little better than toys; unreliable, inaccurate, and high maintenance. The laser cutter, however, is a tool. By cutting and joining multiple sheets, three-dimensional objects are still faster and often better than 3D printed parts.

Additionally, when I’m trying to build something really fast, I find it much quicker to sketch out profiles in Inkscape than CAD them up. Inkscape is totally rad open-source vector drawing software, if you’re not familiar. Being able to see assemblies in 3D is nice, but I can do that in my head for quick and dirty projects.

One of the bottlenecks in this process that really messes up my flow is hand-drawing box joints. It’s tedious and error-prone to copy mating profiles that are dimensionally accurate.

But wouldn’t it be great if it only took two seconds?

So this is QuickJoint. It’s a simple Inkscape extension that will add box joints to selected objects.

This first version can do male tabs or female slots. The tabs by selecting a path, and then in the menu choose which side (and direction) to tabify.

The slots will use a single line as a guide, accounting for the laser’s kerf.

This is a work in progress. Fine tuning with how kerf computation works will be tweaked. Slots/tabs may be changed to autodetect so that everything can be done at once. There are a few more changes, for sure.

It’s been tested on Inkscape 0.91 and 0.92, but there was a breaking change in how units are translated in earlier versions, so if you get an error that references self.unittouu, then upgrade your copy of Inkscape! Feel free to submit other issues, with example SVGs.

For a two-minute primer on writing extensions for Inkscape, read on!

Everything is based out of the Inkscape/share/extensions folder.

The recommended method to get started is to find a similar extension to the final project, and use it as a starting point.

Two files are required: A .py and a .inx

The .inx is an Inkscape extension dialog file. There’s a reference here, but for simple stuff, that’s not needed. There are plenty of decent examples in the extensions folder. You’ll start by modifying the dialog options, and then setting the self.OptionParser.add_option of the Python script to match.

For the Python portion, there is a little bit of magic.

Most of the files in the extensions folders are just that: extensions. A few of the files in that folder are special helper files, though. They’re listed here. Inkex has the main Inkscape helper functions, and I used simplepath for SVG writing.

One of the key concepts is that Inkscape mostly gets out of your way while running the Python script. You’re parsing and handling the SVG files directly, with the assistance of those helper scripts. It’s not so bad, SVG is a really simple format – In this case, I only needed commands relating to straight lines, listed full SVG spec.

When Inkscape calls your function, it runs YourExtensionClass.affect(), inherited from the Inkex module, which then calls YourExtensionClass.effect(). Yeah, not a typo. It’s a little bit silly.

From there, the “Live Preview” checkbox in the extension dialog is your friend. The .inx only gets loaded when Inkscape starts, so changes to the dialogs don’t get updated, but the .py gets re-run every time the extension renders.

Jumping off from my last post about getting images into Altium Designer, it was surprisingly difficult to do in CircuitMaker.

After three days of attempting a few different approaches, I have one that I’m quite happy with. Conveniently, this is pretty good at getting images into EAGLE as well. At least as good as the built-in ULP.

If you’re just here for the solution, scroll way down and read the paragraph about the brd-builder.py script.

This is the story of how I arrived at a robust method of importing bitmaps into arbitrary layers in EAGLE cad or Altium CircuitMaker.

The first approach I started with, after drawing some pretty pretty pictures, was to attempt to load them into Altium Designer in the same fashion as described earlier.

These images were way larger and more complicated than the previous experiment, however, and the Delphiscript chewed on it for three or four hours before silently failing. Even if it had worked properly, I’m not particularly happy about being dependent on the expensive professional tool to work with the hobbyist one. So I delved deeper.

Here are the options and approaches I took:

Importing DXF files directly in Circuitmaker is possible, but largely unsatisfying. The CM importer splits up the original paths into discrete arc and line segments. This is great if you want to draw outlines, but that’s it. Lack of fill options or the ability to merge these objects make it inadequate for my purposes.

Using CircuitMaker “region” objects. Going into the property menus of one of these objects reveals a list of points and coordinates, and import/export options. I wrote a converter to massage SVG files into the proper CSV format. This is svg-parse.py. It’ll take an SVG file, and convert each individual object into a CircuitMaker-compatible CSV file. From there, you can create a region in CircuitMaker, open its properties, and import one of the CSV files.

This is pretty good, and results in native objects that are speedy to move around. There are some caveats, however:

You must do this for each object, making it labour-intensive for complex canvases

Curves are not supported, so it is first necessary to follow the “Add Nodes” and “Flatten Beziers” steps in Inkscape, described in the import-dxf EAGLE plugin.

Attempting to hijack the clipboard was the next experiment, read-clipboard.py. Region objects can be copy-and-pasted between documents, so I wanted to take a look at what that data contained, and maybe silently insert my own. This never really worked properly, and I abandoned it quite quickly. It was a hacky approach, anyway.

A quick search on reverse-engineering Altium’s file format brought up this primer (by way of Hack-A-Day). Although very abbreviated (the goal of that guide is to teach a methodology, not to completely reverse the file format), the page was more than enough information for me to write a Python script that opens and dumps the contents of the CircuitMaker-formatted OLE document. So in ole-extract.py, I got as far as grabbing a library document and extracting and splitting header/data information into a folder. Realised at this point that the libraries I was using would have a difficult time repacking the streams into one OLE document. Not to say it isn’t possible – it totally is – it’s just rabbit-hole I don’t particularly want to go down at this time. This is still interesting in that it should be a working Altium and CircuitMaker file reverse engineering effort in Python, which hasn’t been done before.

Importing EAGLE files works really well. They’re XML-based, and very well documented. First, I imported an EAGLE file that contained an image, which looked and worked great in CircuitMaker. I poked around with how that image was created in EAGLE, and it looks like it was just made with the built-in “Import Bitmap” ULP. How it works is that it scans along each horizontal line, creating a one-pixel-high rectangle in the filled area. Repeat for the entire image.

Okay cool. That sounds really simple. Problems with that:

It doesn’t alleviate my allergy to using 3rd-party software as an intermediate step

So what I did instead, is take a dummy EAGLE file, and stripped it to the bare-necessities required to load. This particular brand of XML is the fourth file format I’ve had to parse in this whole process, but it wasn’t too hard. With this dummy file, my final and greatest script, brd-builder.py, grabs a bitmap file, converts and then injects it directly into the EAGLE file, giving you a proper EAGLE file, with no size limitations and no EAGLE install required. CircuitMaker can then easily import this via the File->Import menu.

Input images need to be a 1-bit BMP file. In Photoshop this is done by converting to grayscale in Image->Mode->Greyscale and then converting to bitmap in Image->Mode->Bitmap. In GIMP, this is done through the menu in Image->Mode->Indexed. Then save as BMP.

Before running this script, open it up and then modify the desired variables – inFile, outFile, layer, and scale. They should be fairly self-explanatory. Scale in my application was found by guessing until it fit my board, due to the resolution I drew my image at.

This was a fun detour. Fun is good, because spending time to make tools for your tools can be very frustrating. The last tool in particular works great for me, but If I were to develop a robust system designed for anyone to use, there are a few more avenues I would attempt to pursue first:

In the Hack-A-Day link posted above, one of the comments mention being able to just open OLE. They turned out to be using 7zip, which supports that format natively. Coincidentally, I found a portable 7zip executable in the CircuitMaker folder. It’s possible that they’re using this for encoding their documents. It would be fun to write an executable shim with the same filename that invisibly passes arguments to the original 7zip program, but logs it to file as well. Will also look into better methods for doing this – Static analysis using X64_DBG or IDA is an obvious candidate here.

Failing that, writing and testing code to modify the OLE document stream and then repack it into a format that CircuitMaker can read

The native importers in the CircuitMaker all have IWZ extensions, and from the binary data seem to be x86/64 executables. Google says these might be installer files. Along the same lines as the executable shim/wrapper above, figuring out how these work and writing my own would be fun.

I’ve been a really big fan of PCBModE for a long time. Designing beautiful PCBs is a seriously difficult skill, and a serious abuse of the PCB board houses. Saar Drimer of Boldport has done a great job, and anyone reading this should definitely check out his stuff.

Where it falls down, though, is doing complicated and electrically correct circuits – No DRC/ERC rules, and not even a schematic view. I use Altium for my main PCB package, but it’s pretty tricky in it to get images into the PCB. It is possible, if a little convoluted, so here is my method.

Part of the problem is that I’m using Altium Designer 10 – Newer versions are better with this, it seems.

This process uses the CreateRegionsFromBitmap script. On my machine, it’s located in:

Instead of trying to fix it (I don’t got time for that), it was replaced with:

GrayWidth :=0;

Second error was a missing function. This was fixed by copying LayerComboBox.pas from the PCB Logo Creator script into the working CreateRegionsFromBitmap script directory and project tree.

Then hit Run, and a dialog box pops up!

My workflow here was to identify what different shades I could get on the PCB, and the best ones for my image.

Here is a list of portions that contain wildly different shades:

Bare FR4

Copper

Soldermask

Soldermask with copper underneath

Silkscreen

Predictably, that means that images with 5 or fewer colours (including backgrounds and outlines!) work best. For a non-commercial practice piece, Dr Seuss was the clear choice.

First step is to pull the desired image into Inkscape and separate all the component colours.

The way Inkscape handles colours masking each other – like the yellow layer being the “background” and relying on it being blocked by the colours on higher layers – doesn’t really mesh with the way they show up on PCBs. After some fudging around (as quickly as possible), this is what I came up with.

And here’s how the PCB turned out in OSHPark Purple.

The thing is super small, so you can see how the soldermask pools up against the raised copper and causes weird bubbles.

I didn’t spend a huge amount of time trying to fit the best colour scheme to the image. But what I’ve done since then is scanned a few PCBs that I have kicking around, and created this handy palette for a various soldermasks!

The best method for using these is probably to ignore the PCB aspect entirely at first, and draw a pretty picture in your illustration application of choice, using just those colours. Translating that to PCB is the secondary concern, and much easier. Something to note is that the “copper” colour of the DirtyPCBs palettes is HASL tin grey on top, and the OSHPark scheme is ENIG gold on top. Both of those are shiny.

Another technique worth trying is crosshatching. That might work out really well, in the same way that it works for laser cutting.

I’ve written recently about machining my own custom pen because, much like lamps, they are a “form over function” project where the end result can be gorgeous as well as useful. Aesthetically pleasing to everyone, not just techie people. And they don’t take up a lot of space!

Initially, my design for the first pen was sketched out in notebooks, and then modelled in CAD, then back to the notebooks when I was in the shop. This helped me get a general feel for what I wanted, but many style, material, and mechanical considerations had to be redesigned on the fly as I found techniques that didn’t work, and others that did.

A lot of the dimensions of final product came down to how they felt in my hands, as I was building. That’s fine for a one-off, but I’d kinda like to parameterize basic measurements so that I have some guidelines on what works for future pens.

So here’s a pretty generic pen, modeled in Solidworks.

Here are a few pens I had within arm’s reach.

Starting at the top, I named these 1-4, and made some basic measurements based on the generic model:

Now I’ve got a good baseline for what makes a comfortable writing utensil, a recommendation for critical dimensions to stay within, and some language (or at least letters) to be able to intelligently discuss the anatomy of a pen.

This is a pretty rare combo: using a premium PCB package with the budget board house.

Kinda funny.

Generally these small run PCB houses provide DRU and CAM files for EAGLE design rule checking and Gerber outputs, respectively. Because I’m using Altium, I had to make it up as I went along.

It gets much easier when you understand what Gerber files are. While we’re all used to standard, unified output formats that contain all of the data we need, Gerbers are very much still a holdover from manufacturing in the 80s.

When you export these, a whole bunch of files get generated. This is intimidating, but don’t panic! They all have different extensions like GBO, GTL, etc. These are all the same type of file.

As I’ve said, while you’re used to unique file extensions being different formats, these are a holdover from 80s manufacturing and the PCB industry still hasn’t caught up. That means that by changing file extensions, you can play around with different layers doing different things.

So here’s how you generate the appropriate Gerbers. I used a mostly the default rules for this, I’m not pushing the limits. Maybe next time I’ll generate the proper rule sets.

Read and understand these directions before you start. They require some forethought.

Start out with your finished PCB.

Do the thing.

The resolution options matter here. There’s no way Dirty PCBs can handle the higher res, so turn it down a notch.

In the next tab, this is where you’ll have to do some thinking. Every project is slightly different. So for this one, I want the top overlay (silkscreen), top solder (gaps in solder mask for your pads), and top layer (copper). Same thing for bottom.

You also need a board outline. Older versions of Altium don’t have a dedicated “outline” layer, although I believe newer ones do.

So what I did was change the board outlines to Mechanical 1, and now I’m exporting that.

A couple more notes:

If I wanted to create a solder paste stencil, I would also export the Paste layers.

If you want through-hole slots, you will need an additional layer. This includes slots that allow you to panelize. Export them on another mechanical layer, and I’ll talk about it a little later. I’ve done this before, DirtyPCBs does a great job of this.

All of the other tabs in this dialog are kept at default values. Don’t mirror the bottom layers as shown. I did that and it was Wrong.

I lied a little bit above. Of the exported files, there is one that is not like the others. The drill file (.TXT in this case) requires it’s own export.

Do the resolution thing again, and everything else is default.

Okay! Now we’ve got all the files we need, let’s make sure they’re in the order they need. Here’s the key on the DirtyPCBs website.

As you can see, it’s super similar to what we have. The top 6 are exactly what we exported, and the drill TXT, too. The outline is the only thing that’s not quite right.

We exported it this time as mechanical layer 1. Easy fix, just rename the GM1 file to GKO. If you’re doing internal slots or self panelizing, you’ll also have exported another mechanical layer. Say, GM2 or GM15 or anything you like. Rename this to GML and include it with the others.

And there you go! Zip up all of these files, and they should turn out alright. GD1 is the Gerber drill file that this board house doesn’t use, just ignore it.

An important step: Check your files.

CircuitPeople is an excellent and simple online Gerber viewer. Look at all your layers and make sure nothing is terrible.

And you’re done! Send it off and enjoy your boards.

If something screws up in the order, I’d like to hear about it, but I take no credit. These steps have always worked for me, but this particular company probably won’t tell you if anything is wrong with the files. They’ll just manufacture it and send it on.

Side note: A summary of something I’ve been using for many hardware hacks in the past while.

A lot of commercial machines use gears for transferring forces. Well, duh. It’s often necessary to change gearing around, though, and it’s nigh-impossible to find commercial solutions with appropriate ratios, tooth profiles, and mounting options. So usually I laser cut my own.

The easiest way to generate a gear that meshes with an unknown is to use Inkscape’s Gear extension. It needs circular pitch, which you find by:

Measuring the gear’s outer diameter, OD

Counting the teeth, N

Getting diametral pitch: (N+ 2) / OD

Calculating circular pitch: Pi / Diametral pitch

For the pressure angle, it’s a little more complicated. You need the base pitch:

Use your digital calipers to measure right down in the gaps of two teeth

Measure three teeth

Subtract the two-teeth measure from the three-teeth one to get a single tooth

Do the same for 5 and 4 teeth

Take an average result of those to get an approximate base pitch measurement

Base Pitch * Diametral Pitch = Pi * Cos(Pressure Angle)

Of course, that looks difficult and error-prone but generally you’ll only run into pressure angles of 14.5 or 20 degrees, so only do rough measurements pick the closest one.

For mounting holes, you’ll need to know how far apart to space them. Pitch diameter is what you need: Teeth / Diametral pitch

This is a quick summary of everything you need to know. There are a lot of dimensions associated with spur gears, and it’s good to know what’s what, but these are the only ones you actually need to make your own. All of these formulas are unitless, so pick and choose, as long as you match the same unit in Inkscape. I uses inches for these, but I tend to switch back and forth to metric with impunity for everything else.

Like many (many many) engineering types, I have a goal of easy workbench PCB fabrication. I think I’ve done more research than most, however, and in this case, sharing the wealth means everybody wins.

I’ve posted this up here in its original form, but an updated version will live at the VHS wiki so that everyone can join in. So, without further ado, here are avenues I have approached, intend to approach, or discounted.

Objectives

To design a machine, method, or process to generate one-off printed circuit boards with the following conditions:

Time from finished PCB layout to physical board must be less than 3 hours excluding setup.

Two layers must be supported and properly aligned with minimal frustration.

Board quality must be consistent and dependable.

Minimal tool changes or chemicals.

Methods

Traditional

Toner Transfer

Works. Not well.

The traces are laser-printed in reverse onto some sort of glossy paper (e.g. magazine or photo paper), then transferred to a copper-clad board using a hot clothing iron or t-shirt press. The traces transfer to the board and act as an etch-resist.

Issues:

A dedicated clothing iron is required

Inconsistent transfer (i.e. gaps in solid areas)

Multiple layers are difficult to align

UV Exposure

Works. Not well.

The traces are laser-printed onto clear acetate, then overlayed on a copper-clad board and exposed evenly to UV light. The board is then washed in developer solution that either washes away the exposed portions of UV-sensitive chemical, or wash away then unexposed portion, depending on chemical process used. The traces that remain on the board act as an etch-resist.

Issues:

UV chemicals are required to coat the board OR

Presensitized boards must be used, which are:

More expensive

Inconsistent from different manufacturers both in exposure time and development time

Require handling in a darkroom

Require rushing the process so as not to allow ambient light to ruin process.

Laser Cutter

Spray Paint

Has potential.

The board is evenly sprayed with a single coat of paint. After drying, the laser cutter vaporizes the paint along where the traces should go. Remaining paint is left as an etch resist.

Issues:

Laser power/speed must be fine-tuned to vaporize paint layer with excess copper heating (cut paths widen when copper acts as a heat-sink).

Paint layer is undesirably thick. May not be an issue?

Paint layer is difficult to apply evenly.

Vaporized paint leaves a residue that interferes with etching. Clean it with hydrogen peroxide or very very mild acetone bath?

Sharpie

Has potential.

Copper-clad is covered in Sharpie (permanent marker ink). Laser appears to “burn in” sharpie layer and make it resistant to acetone. After acetone bath, burnt in layer is left as etch-resist.

Issues:

Layer evenness is very difficult to achieve. Ink bath and rubber rollers will be attempted.

Acetone bath dilution must be tweaked.

Sugar

Laser printer toner is effectively sugar as a binding agent and carbon as a colourant. Because colour is unnecessary, sugar alone was attempted to be used as an etch mask.

Doesn’t work.

Laser cutter has “air assist”, airstream designed to push slag through the workpiece as it is cutting. It blows the sugar off the copper instantly.

Using water to form a paste, still difficult to consistently achieve thin traces.

Printers

Inkjet

Typical inkjet ink is a dye as opposed to a pigment and is water-soluble. Ink cartridge must be filled with special MISPRO pigment:

Expensive.

Messy to refill.

Runny/blurry edges.

Double sided boards have alignment issues.

Laser

Works. Not well.

Laser printer can be modified to print directly onto copper-clad. Use as etch resist.

Issues:

Larger printed areas have inconsistent fill/gaps.

Alignment issues for 2-layer boards and multiple passes to fill in gaps.

Wax Inkjet

Works. Current status unknown.

Jeff Gough had some success with this. A piezo inkjet head (as opposed to a thermal inkjet head) used by Epson printers can be modified with a heated reservoir to print directly with wax.

Issues:

Print heads eventually had clogging issues.

Dye-Sublimation

Has potential.

Dye-sub is now available for the consumer market with Canon’s Selphy line of printers. It works through a thermal print head sublimating wax or resin into a gas, then allowing to to solidify onto the print medium. It should work as an etch resist.

Potential issues:

Sublimation results in soft edges, may lead to improperly etched traces if print resolution is too low.

May rely on special coatings on print medium for ink to bind properly.

Water insolubility may rely on final clearcoat layer that is printed.

Thermal Transfer

Has potential.

Similar to dye-sub.

Issues:

Printers are expensive, niche, and difficult to find in appropriate sizes.