home..

Week 06 - efab

group page // repo source files // objectives

Contents

• hero
• projects
• COB LED workflow - Altium
• comBadge LED workflow - leadframe-crafting

hero >

projects >

• cob led board/stamp (altium)
• comBadge_led (solidworks/altium)
• xiao rp2040 (kicad)

COB LED workflow - Altium >

Altium -> mods -> ugs -> Lunyee

I ran through the entire efab workflow last week during ecad. Here is the rest of that documentation:

gerbers - files for fabrication >

After designing your pattern in Altium and running DRC checks, I exported gerbers, which is necessary whether you’re sending the design off to a fab or machining it on a desktop mill.

Altium -> generate gerbers -> export bitmap -> convert to png + post-processing -> mods

• Altium
  • validate design using DRC (tdr)
  • file -> fabrication outputs -> gerber files
  • enable mechanical layers (specifically board outline, which I have as layer 99/board), then click apply
    • note that my bottom layer is being used as a throughhole layer for TH header pins; this was an arbitrary but convenient decision for 1-layer boards
  • for the following pairs of layers, export as bitmap set to 1000 DPI (feb) (we keep board on for all of them to make sure registration between layers is consistent)
    • top and board
    • bottom and board
    • board
• paint.net (or a script)
  • for all files:
    • resize canvas to add 10px margin to each side
    • change DPI to 1000 pixels/in
  • for top.bmp:
    • invert colors
    • apply a 25px wide black border on the canvas
  • for th.bmp:
    • apply a 25px wide white border on the canvas
  • finally, for each of these files, export as .png into the same directory.

mods - generating cam tool paths >

With .pngs generated and post-processed, I opened the mods workflow for the Lunyee. Mods is a useful data-flow oriented tool that enables the user to mix and match a variety of functional blocks to do a variety of things. Here, we use it for machine interfacing. I created some .nc files using this workflow.

mods -> machines -> g-code -> mill 2d pcb -> export .nc files (gcode) -> ugs

• mods
  • with the mill 2D PCB workflow, run each file through the workflow. This will be the same order the CNC should be run in, approximately:
    • th.png (tabs disabled)
    • top.png (tabs disabled)
    • board.png (tabs enabled)
      • for this Junyee vacuum setup, tabs are necessary to avoid the boards from being sucked into the vacuum
      • Neil made a mods module for this, though I found a bug with including the north south directions. proceed w/ caution for the time being and make sure to check the cut route before running

ugs - communicating with the machine >

Finally, we open the .nc files in UGS and prepped the machine to run them.

ugs -> open .nc -> find new zero -> z-probe -> send job to Lunyee

• ugs
  • find a place on the stock that will likely fit your pattern
  • reset soft zero to make sure CNC starts pattern in right place
  • install correct endmill (in this case, 1/32 for th.png and board.png, 1/64 for top.png)
    • make sure to use tools to tighten; hand tightening only usually leads to disaster
  • clip alligator to endmill
  • (MAKE SURE TO CLIP ALLIGATOR)
    • note: Quentin has since improved the mill to use a magnetic connection
  • …and zero using Quentin’s macro
  • install the foot brush thing
  • load the first file (th.png in this case)
  • press run
  • listening to first ~5 seconds of milling
  • turn on vacuum
  • turn on/put on ear protection
  • wait, rinse, repeat for each tool change/layer

soldering >

for the passives and ICs, I used my Pinecil soldering iron (USB-C powered and awesome).

for the COB… normally, you’re not supposed to solder FR1 boards using hotplates or reflow ovens; they’re not as flame retardant as their FR4 cousins. However, the COB LED I was working with has a nice metal heatsinking surface on the otherside; I tried applying solderpaste to the board and soldering through that heatsinking surface and it worked!

comBadge LED workflow - leadframe-crafting >

I fabricated some leadframes a few weeks ago for my final project/research; I applied similar principles for this week. For this pattern, I played around with long features and observing how they affected rigidity; long thin features severly compromise rigidity, which is why I switched from 0.2mm copper stock to ~1.0mm copper stock.

cad >

the following flow results in some weird scale conversions that were hard to explain(problem has since been solved, TL;DR I missed the units setting. Original documentation below preserved for history). I initially encountered these conversions due to how solidworks handles exporting splines and arcs as dxf’s (hint: it doesn’t). in an attempt to simplify geometry, I ran artwork through cadquery and inkscape to get to something usable.

solidworks -> altium -> solidworks -> cadquery -> inkscape -> fabcreator -> fablight

the solidworks through cadquery loop is fairly consistent dimensionally; mm translates to mm. after cadquery, I think the artwork shrunk from 69.522mm to 37.883mm (possibly due to how I configured the svg export settings; projectionDir: (0,0,0.5) could be a half scale factor but 69.522/2 dne 37.883…

anyways, in inkscape I resize from 37.883mm back to 69.522mm and lock aspect ratio so everything else scales correctly.

export as dxf (R14, later tried R12 as well but the geometry comes out very rough).

open in fabcreator (in mm, for some reason inch hangs indefinitely)*.

in fabcreator, the width of the leadframe went from 69.522mm in inkscape to 194.518mm, which appears to also be the case on the fablight afterwards.

from prior work, exporting in inch is ok, and shouldn’t affect dimensions (in fact, necessary if you want to work with copper, as mm doesn’t have a copper preset).

---

attempted fixing this by trying R12 (as mentioned); terrible rough artwork.

viewed in edrawing to confirm that dimensions were off.

attempted reverting to previous value (37.883mm); no success.

next try will be applying a scale factor (knowing input is 69.522mm and output is 194.518mm) new value = 69.522 / 194.518 * 69.522 = 24.847615562570044931574455834421 = ~24.848 ended up getting 70.417

---

oh my god, I’m really dumb…

---

I just noticed that R14 has a “base unit” setting, and it was set to “pt” by default… just set it to “mm” and everything appears to be correct now…

a lesson in reading all of the dialog boxes before assuming bug ***

simplifying paths - reducing nodes and avoiding crashing programs >

*I initially had to go back to inkscape and manually simplify some of the paths due to the extraneous number of nodes generated from solidworks exporting; only possible to use simplify command in a useful manner (not destroy the artwork) if I pass it through cadquery for svg export first, by doing so I can selectively simplify rather than everything at once. wondering if this is due to how the paths are joined; if everything is part of one long path, simplify may attempt to “drift” the corners, resulting in more curves but destroying the art in the process. if paths are disjoint, then simplify optimization can run on everything (but disjointly), resulting in sharp corners still and retaining the artwork.

this whole workflow reinforces the need for more robust vectorized operations for optimized path planning to enable more complex CAM work, especially for machines like the fablight that have limited “hackability” and too many annoying quirks.

fablight >

lessons >

a lot of progress is hacks sometimes; this was one such week.

• dxf (as mentioned) is a weird format w/ weird history
  • multiple standards that seem to have changed from year to year
  • though people have mentioned that one standard is the “best”, that really depends on the program you’re exporting from. for this particular application
    • Inkscape: DXF R14 = good, R12 = bad (no options)
    • Solidworks: DXF R12 = good (change options)
    • Rhino: appears to have DXF R12
  • Fablight only accepts .dxf through fabcreator
• fablight is seemingly arbitrarily finicky with geometry (as reinforced by Alfonso and others in the lab, but also from first hand experience)
  • weird issue where some paths won’t work as cut paths, but will work as engrave paths; in this situation, leave paths in categories that work, but change the engrave settings on the fablight itself to match cut
• fablight will be sad if there isn’t material under its toolend for extended period of time
  • this period of time appears to stay constant, which becomes a bigger problem if you slow down cut rate (easier to trigger machine pause)
  • I used some copper tape to get the laser to register material and continue program
  • if you attempt to resume twice w/o solving the missing material problem, the job will cancel (careful)
• fablight tabs are pretty useful and can help prevent workpiece from falling into the void
  • I’ve also paused the job before finish and used tape to retain the part on the stock
• slowing the cut rate to make sure piece falls out results in much better results for fine artwork