Final Project

For my final project, I want to make a laser cutter, except that instead of using a laser to cut things it puts sprinkles on cookies and cakes.

A sprinkler machine model sprinkling the word "Test"

During electronics simulation week, I modelled a movement system that takes a shape file from an SD card as input, posted here

During 3D printing week, I made a 2-axis control 3D print (with a detachable funnel!). Turns out that torque is a thing and one of the axis would need 2 motors. Posted here

During input devices week, I made a touchpad out of magnet sensors. I decided I want to include a drawing input method for the sprinkler machine, and this was a good place to attempt to make one. Posted here

Welp, I got very inspired by what I decided to do for BIG week, and now I want to turn that into a final project. Besides, no need to worry about food safety.

The basic idea is the same: a gear doing logic. This time, each gadget will have electronics involved in them such as lights to display the type of gadget and the state the gadget is in (for ones with states, such as switches) and sensors to detect the state that switches are in. (Unfortunately there will not be motors to move the switches because motors are expensive and this wouldn’t scale well.) The player gear is controlled by a motor that automatically moves it around the field. Each gadget is connected to a frame that carries electricity to it. (Or I could figure out connecting electricity between gadgets directly.)

My current plans for gears doing logic

Schedule:

• Experiment with train model, direct transmission of power (to player gear/train) via gadget grid, direct connection of adjacent gadgets (before 11/25)
• Build wire and switch gadgets and measure various parameters (power, current, etc.) to see how well they’ll scale (before 12/1)
• Scale, scale, scale up as much as possible

Getting Logical about Complexity

It turns out, though, that thinking about the many problems that came up (including microcontroller communication without overwhelming a microcontroller and powering the player gear), and also realizing that it takes way too many gadgets to simulate an AND gate, I decided to scale down and just make gadgets that take some inputs, do some computation with them, and output outputs. No worrying about player-gear-related stuff.

It takes way too many gadgets just to simulate an AND gate. Can't do much with that model

A plan for the types of logic gadgets that will be needed

The Logic of the Logic

The basic way this works is that each gadget is a square that has 4 inputs/outputs, one on each side. Some gadgets have additional inputs/outputs such as switches or displays. Each gadget is fed a clock signal from the master of clocks (the main board). On a clock rise, the gadget takes all its inputs, does some computation, waits a bit (so that all gadgets appear to read their inputs at the same time), and outputs the result.

LEDs are used to show progression of logic. A wire is a connection from a gadget’s output to the adjacent gadget’s input. Each side of the wire (output, connector, input) is lit with a separate LED. I went through several iterations about how to light up a wire properly.

(In the schematics below, all resistors are 5000Ω. This should keep the LEDs sufficiently bright while not consuming too much current. Assuming 3.3V input, an LED would then consume 0.66mA of current at most, making it take about 1500 LEDs to consume 1A.)

Some designs for using LEDs to light up wires.

• Left: one LED line for the output side (containing 2 LEDs) and one LED line for the input side. I decided not to go with this due to the lack of symmetry, which could cause the line of 2 LEDs to be darker than the line of 1 LED.
• Middle: one long LED line. This didn’t work. Turns out that I forgot that LEDs need their due voltage.
• Right: three parallel LED lines. And it’s nice and symmetric. The only difference between an input and an output is the color of the LEDs. This allows for making more general boards. (Unfortunately it requires more resistors.) This is the one I ended up going with.

Boarding the Logic

To actually make the boards, there are several considerations that need to be considered:

• Powering the boards through the network
• Timing the boards
• How outputs are connected to inputs
• The microcontroller that will be used (an ATtiny1624 because it has enough pins while not being too expensive)
• Current consumption

First, I started off with designing the OR-IIOO gadget (OR gate with 2 adjacent inputs and 2 outputs).

Design 1: Awkward Angles

Schematic of design 1

PCB of design 1

In this design:

• The microcontroller can take 5V or 3.3V depending on whether it’s connected to power directly (via the UPDI pin header) or through the network from some voltage-regulated board.
• Boards expose sockets (4 for each input, 5 for each output). Adjacent boards are connected using a connector (shown below) to connect their ground, power, clock, and output-input lines together.
• There’s an extra (white) LED that turns on when the result of the computation is “true”.

Schematic of design 1's connector. It doesn't have an LED. It was an older version of the left LED schematic when I was planning on using only 2 LEDs per wire.

PCB of design 1's connector

The connector just connects corresponding ports together, except that the line that went through the output LED gets connected to ground. This ensures that an output LED can’t light up if it’s not connected anywhere. In retrospect, this was a bad feature, because it would make debugging harder. I say “would”, because I didn’t actually make this board. The shape of the connector is even more awkward than the angles and just looks unwieldy and too long and thin.

Design -1: Generalizing the Board

I went through a few more iterations, including the LED schematics shown way above. I arrived at a nice symmetric pattern.

The schematic for the OR-IIOO gadget.

TODO

The new design changes several things:

• Inputs and outputs are symmetric, so I might as well name them like they’re symmetric. (They were technically symmetric in the first design too, but intermediate designs broke symmetry.)
• Outputs connect directly to ground after going through an LED. This means that an output LED can light up even if the output isn’t connected to anything.
• The holes are bigger. They’re meant to fit the bulky part of IC sockets. IC sockets are nice because the bottom part of an IC socket is a pin that can fit into the socket. If it wasn’t for that, I’d have to use surface-mount pins in the connector (unstable) or mill on the other (top) side of the connector (ew) or use vias (time intensive).
• There’s a fill-in zone. This will be talked about later.

Making the Board

Then came actually making the board.

The board (the first of many, many boards) was milled with an Othermill V2 with

• a 1/64” end mill, 24 in/min, 0.15mm stepdown, 45% stepover (nicknamed [1/64” Please Step Over])
• a 1/32” end mill with default settings

To help with deburring, there’s an aforementioned fill-in zone. It turns out that the 1/32” end mill tends to cut better when climb cutting than conventional cutting. It climb cuts traces. But in doing so, it slots, and therefore leaves a conventional-cut edge exposed and ready to wreak copper-string-shaped havoc. The fill-in zone (clearance 1mm) ensures that no place on the board is farther than twice the tool diameter away from a trace, ensuring that there are no conventional-cut edges. Except that if the space between traces is the tool diameter, you get climb-cut edges intersecting with conventional-cut edges and they don’t get cleaned up. So I still have to deburr, because I don’t feel like messing with all the wires that I so carefully placed with 0.8mm spacing to pack wires while minimizing the use of the 1/64” tool.

Speaking of which, the [1/64” Please Step Over] was made because the default settings are unnecessarily slow, doing 2 passes with 0.1mm stepdown and a very inefficient 15% stepover.

Assembling the Board

Then came assembly. When the board and connectors are assembled, then before any adjustments, the end result should look something like this:

Sketch of the connection design. Colored rectangles are LEDs. Vertical thick blue lines represent connectors that elevate components. Notice that all LEDs have the same elevation.

All LEDs have the same elevation, which is important. So I need to figure out how much to elevate the orange LED above the connector board, and use that, and the elevation of the connector board above the gadget board, to figure out the elevation of the other LEDs above the gadget board.

Let’s first take a nice look at an IC socket.

TODO: IC socket

Oops, it turns out you can’t just plug in LEDs in series because they have voltage requirements.

Assembling boards takes forever Don’t have a hole straight though a trace. It makes soldering more annoying Add a little space in connectors for clearance (0.1mm total) Make holes bigger than pads to avoid stray copper circles Connector indent thickness: 0.9mm Getting dangerous with powering 0-delay wires with a logic line

FreeCAD importing SVG doesn’t import polygons with holes correctly. More differences. Lots of time spent processing the complex shapes of gadgets

• Fusion crashed >=2 times

Forgetting to check a connection before putting the microcontroller on Defective connectors Joint hell with milling (moving to laser cutter / 3D printer for different reason: the waiting line. Also, the Lunyee machine broke 3 1/32” end mills)

Not using 2-56 screws because their heads are the annoying 2-spoke type and there’s barely any nuts

https://medium.com/@damien.martin.guillerez/multi-filament-print-with-a-single-extruder-using-prusaslicer-2e0746348cdd (multiple colors with 1 extruder in Prusa) Elephant foot compensation with multiple colors Broken 3D printer (filament apparently made a hook inside the extruder and wouldn’t move in either direction)

Holes were the wrong size

TODO: The CAM process

• Time optimization

Elevation difference between gadget and connector…

16.38mm - 7.54mm - 4mm

https://forums.autodesk.com/t5/fusion-support/fix-dimensions-of-imported-svg/td-p/7481059 (Inkscape to Fusion scale factor when transferring SVGs: 3.77953) Items

Prototyping the player

• friction
• torque
• prototype 1
  • inward feet
  • track width parameter needs to be tiny
  • friction caused by torque is too high
• prototype 2
  • wheel feet

Acrylic flatness

• thickness tolerance

Frame Board

• support gadget rotation
  • first iteration didn’t

Gadget Board

• lot of complications
  • supporting the pins (sockets?) to the frame
  • programming the ATtiny
    • only 1 I2C interface
    • bidirectional muxing is hard
  • connections to track lines
• communication
  • I2C is hard
    • Arduino doesn’t have an easy read-from-register function
    • Giving each gadget a unique address is hard (Hall sensor flashbacks)
  • multi-master is hard
    • race conditions
    • every gadget requests an identifier from the main board at the same time
• neighbor-neighbor communication
  • receiving from 4 places is hard without hardware support
• first double-sided board
  • asked about good hole size, got 39 mills
  • climb vs. conventional milling (climb good, conventional super burry)
• stars
  • they’re chiral! Beware the orientation
• programming
  • lots of settings to set: programmer, port, board
  • fast-switching diode ≠ Schottky diode. (thanks https://github.com/SpenceKonde/megaTinyCore/issues/545)
    • used 4.7K Ω resistor instead
    • make sure to select the exact chip!
  • assembly
    • https://forum.arduino.cc/t/progrsmming-arduino-with-assembly/397708/6 (gotta have that capital S file extension)
    • clocks might be a bit too varied…
  • interrupts
    • https://www.ojisanseiuchi.com/2024/03/03/a-quick-word-on-attiny-1-series-interrupts/
  • message queue
    • receiving is hard
    • possible deadlock if you try to transmit multiple messages before dequeueing a message from the receive buffer
    • timing of message receiving is important
  • probe connected to message clock trace at startup kills interrupt-at-start bug.