The Smell of Molten Projects in the Morning

Ed Nisley's Blog: Shop notes, electronics, firmware, machinery, 3D printing, laser cuttery, and curiosities. Contents: 100% human thinking, 0% AI slop.

Category: Software

General-purpose computers doing something specific

  • Fixed Point Arithmetic: Percentages

    Problem: increment or decrement a variable by a fixed percentage, without using floating-point arithmetic routines. This is the sort of problem that crops up in microcontroller projects, because there’s just not enough storage for the floating-point library stuff and your program at the same time.

    Suppose you want to increment the variable BaseNum by 10%. Using floating point, that’s just

    BaseNum = 1.1 * BaseNum;

    In fixed point, it would look like

    BaseNum = (BaseNum * 11) / 10;

    Similarly, to increment by 5%, you’d use

    BaseNum = (BaseNum * 105) / 100;

    The general idea is that you scale the operation to eliminate the fractional part, then chop off the scaling to get the final answer. The parentheses are vital: the multiplication must precede the division.

    The integer division operator truncates any fractional part, it does not round. This becomes a nasty gotcha if you’re expecting the final value to change.

    For example, incrementing 15 by 10% would look like

    15 ->  165 -> 16

    But incrementing 15 by 5% goes like

    15 -> 1575 -> 15

    For obvious reasons, you should make sure the multiplication can’t overflow. If you’re incrementing by 5% (multiplying by 105), then an int BaseNum can’t exceed 312, which might come as a surprise. Casting the operands to long int would be prudent for many problems:

    BaseNum = ((long int)BaseNum * 105) / 100;

    Suppose you want to increment BaseNum several times in succession, with that number stored in Ticks. With floating point, you could use the pow() function

    BaseNum = BaseNum * pow(1.1,Ticks);

    In fixed point, the same thing seems like it ought to work

    BaseNum = (BaseNum * pow(11,Ticks)) / pow(10,Ticks);

    Unfortunately, that idea runs out of gas pretty quickly: pow(11,9) falls just outside the range of a long int, so even if BaseNum is, say, 2, you’re screwed. It’s even worse for smaller percentages, as pow(105,5) is about 13e9.

    One solution, which works well for reasonable values of Ticks, is to iterate the process

    for (Counter = Ticks; Counter; --Counter)
    {
        BaseNum = ((long int)BaseNum * 11) / 10;
    }

    That won’t overflow in the middle. However, if the division truncates away the increment you were expecting, then the loop just whirs for a while and accomplishes exactly nothing.

    That could come as a surprise if you were expecting, say, five 5% increments to add up to a 28% boost: pow(1.05,5) = 1.276, right?

    Bottom line: when you use fixed-point arithmetic, always check the low end of the range for underflow and the high end for overflow.

    Hint: store the numerator and demoninator of the fixed-point percentage fraction in variables. You can’t decrement by the same percentage by just swapping the numerator and denominator, but it might be close enough for human-in-the-loop knob twiddling adjustments.

    Memo to Self: always check for underflow and overflow!

  • Reading a Quadrature Knob

    Most analog projects will benefit from an adjustment knob; the notion of pressing those UP and DOWN arrows just doesn’t give that wonderful tactile feedback. These days “knob” means a rotary encoder with quadrature outputs and some software converting digital bits into an adjustment value.

    Sounds scary, doesn’t it?

    This is actually pretty simple for most microcontrollers and the Arduino in particular. The Arduino website has some doc on the subject, but it seems far too complicated for most projects.

    A quadrature rotary encoder has two digital outputs, hereinafter known as A and B. The cheap ones are mechanical switch contacts that connect to a common third terminal (call it C), the fancy ones are smooth optical interrupters. You pay your money and get your choice of slickness and precision (clicks per turn). I take what I get from the usual surplus sources: they’re just fine for the one-off projects I crank out most of the time.

    How does quadrature encoding work?

    On each falling edge of the A signal, look at the B signal. If it’s HIGH, the knob has turned one click thataway. If it’s LOW, the knob has turned one click the other way. That’s all there is to it!

    Here’s how you build a knob into your code…

    Connect one of the outputs to an external interrupt, which means it goes to digital input D2 or D3 on the Arduino board. The former is INT0, the latter INT1, and if you need two interrupts for other parts of your project, then it gets a lot more complex than what you’ll see here. Let’s connect knob output A to pin D2.

    Connect the other output, which we’ll call B, to the digital input of your choice. Let’s connect knob output B to D7.

    Define the pins and the corresponding interrupt at the top of your program (yeah, in Arduino-speak that’s “sketch”, but it’s really a program):

    #define PIN_KNOB_A 2			// digital input for knob clock (must be 2 or 3!))
    #define IRQ_KNOB_A (PIN_KNOB_A - 2)	//  set IRQ from pin
    #define PIN_KNOB_B 7			// digital input for knob quadrature
    

    The external circuitry depends on whether you have a cheap knob or fancy encoder. Assuming you have a cheap knob with mechanical contacts, the C contact goes to circuit common (a.k.a, “ground”). If you have a fancy knob with actual documentation, RTFM and do what it say.

    The two inputs need resistors (“pullups”) connected to the supply voltage: when the contact is open, the pin sees a voltage at the power supply (“HIGH“), when it’s closed the voltage is near zero (“LOW“).

    Ordinary digital inputs have an internal pullup resistor on the ATmega168 (or whatever the Arduino board uses) that will suffice for the B signal. Unfortunately, the external interrupt pins don’t have an internal pullup, so you must supply your own resistor. Something like 10 kΩ will work fine: one end to the power supply, the other to INT0 or INT1 as appropriate.

    With the knob connected, set up the pins & interrupt in your setup() function:

    attachInterrupt(IRQ_KNOB_A,KnobHandler,FALLING);
    pinMode(PIN_KNOB_B,INPUT);
    digitalWrite(PIN_KNOB_B,HIGH);
    

    The first statement says that the interrupt handler will be called when the A signal changes from HIGH to LOW.

    The Arduino idiom for enabling the chip’s internal pullup on a digital input pin is to define the pin as an input, then write a HIGH to it.

    Set up a variable to accumulate the number of clicks since the last time:

    volatile char KnobCounter = 0;

    The volatile tells the compiler that somebody else (the interrupt handler or the main routine) may change the variable’s value without warning, so the value must be read from the variable every time it’s used.

    The variable’s size depends on the number of counts per turn and the sluggishness of the routine consuming the counts; a char should suffice for all but the most pathological cases.

    Define the handler for the knob interrupt:

    void KnobHandler(void)
    {
        KnobCounter += (HIGH == digitalRead(PIN_KNOB_B)) ? 1 : -1;
    }
    

    KnobHandler executes on each falling edge of the A signal and either increments or decrements the counter depending on what it sees on the B signal. This is one of the few places where you can apply C’s ternary operator without feeling like a geek.

    Define a variable that will hold the current value of the counter when you read it:

    char KnobCountIs, Count;
    

    Now you can fetch the count somewhere in your loop() routine:

    noInterrupts();
    KnobCountIs = KnobCounter;	// fetch the knob value
    KnobCounter = 0;		//  and indicate that we have it
    interrupts();
    

    Turning interrupts off while fetching-and-clearing KnobCounter probably isn’t necessary for a knob that will accumulate at most one count, but it’s vital for programs that must not lose a step.

    Now you can use the value in KnobCountIs for whatever you like. The next time around the loop, you’ll fetch the count that’s accumulated since the previous sample.

    Even if you RTFM, apply painstaking logic, and wire very carefully, there’s a 50% chance that the knob will turn the wrong way. In that case, change one of these:

    • In the interrupt handler, change HIGH to LOW
    • In the attachInterrupt() statement, change FALLING to RISING

    There, now, wasn’t that easy? Three wires, a resistor, a dozen lines of code, and your project has a digital quadrature knob!

    If you have a painfully slow main loop, the accumulated counts in KnobCounter could get large. In that case, this code will give you a rubber-band effect: the accumulated count can be big enough that when the knob starts turning in the other direction it’s just decreasing the count, not actually moving count to the other side of zero. Maybe you need some code in the interrupt handler to zero the count when the direction reverses?

    But that’s in the nature of fine tuning… twiddle on!

  • Changing the Arduino PWM Frequency

    The default PWM frequency for PWM 3, 9, 10, & 11, at least for the Diecimila running at 16 MHz, is 488 Hz. That’s OK for dimming LEDs where you’re depending on persistence of vision, but it’s much too low when you must filter it down to DC.

    The relevant file is hardware/cores/arduino/wiring.c, which is buried wherever your installation put it.

    Turns out that the Arduino runtime setup configures the timer clock prescalers to 64, so the timers tick at 16 MHz / 64 = 250 kHz.

    You can fix that by setting the Clock Select bits in the appropriate Timer Control Register B to 0x01, which gets you no prescaling and a 62.5 ns tick period:

    TCCR0B = 0x01;   // Timer 0: PWM 5 &  6 @ 16 kHz
    TCCR1B = 0x01;   // Timer 1: PWM 9 & 10 @ 32 kHz
    TCCR2B = 0x01;   // Timer 2: PWM 3 & 11 @ 32 kHz

    If you’re finicky, you’ll bit-bash the values rather than do broadside loads. However, it probably doesn’t matter, because Timer 0 runs in Fast PWM mode and Timers 1 & 2 run in Phase-Correct PWM mode, so WGMx2 = 0 in all cases.

    Fast PWM mode means Timer 0 produces PWM at 250 kHz / 256 = 976 Hz. However, the Arduino runtime runs the millis() function from the Timer 0 interrupt, so changing the Timer 0 prescaler pooches millis(), delay(), and any routines that depend on them.

    Phase-correct PWM mode means that Timers 1 & 2 count up to 0xff and down to 0x00 in each PWM cycle, so they run at 250 kHz / 512 = 488 Hz.

    Adroit TCCRxB setting can prescale by 1, 8, 64, 256, or 1024. Or stop the Timer stone cold dead, if you’re not careful.

    Before you fiddle with this stuff, you really should read the timer doc in the ATmega168 datasheet there.

    Memo to Self: don’t mess with Timer 0.

  • Drilling Eagle Printed Circuit Boards

    I use Cadsoft’s Eagle for schematics & circuit board layouts, then build the boards in my basement laboratory using Pulsar’s laser toner transfer and ferric-chloride etching. My Sherline CNC milling machine pokes the holes in the board, which means they actually wind up in the right places. I don’t mill the outline into any fancy shapes, generally using a tin snip and maybe a little filing; glass-fiber dust is a nuisance.

    AXIS hole-drilling screenshot
    AXIS hole-drilling screenshot

    My Eagle ulp routine (in the Useful Stuff page) extracts the holes from the circuit board layout, sorts by drill size, then visits each hole in nearest-neighbor order. It starts by touching each hole with a center drill, which probably isn’t necessary, but it makes me feel good and provides a last-minute check that everything is lined up properly.

    Figuring the tool path is obviously the traveling-salesman problem in disguise, but a strict nearest-neighbor order is close enough for boards of this size. You could probably optimize it by brute-force exhaustion and that would be appropriate for production use, but I rarely make more than one version of each board.

    Eagle’s standard part libraries use a weird set of hole diameters, which my routine rounds off to the nearest mil. I don’t have a vast array of drills, so I don’t pay much attention to the differences between, say, 0.024, 0.025, and 0.027 inch drills. Tool changes are strictly manual and I don’t have to change the drill if I don’t want to!

    Got a bunch of teeny carbide drills as resharps from DrillBitCity a long time ago.

    I double-stick-tape the board (center and corners) to a flycut sacrificial plate, which makes it flat enough for these purposes.The pic below shows a 60-mil board held down with masking tape; it’s the same layout as in the screen shot above.

    Tool changes use a 2-inch block (plus a sheet of paper) as a height reference. You can tweak the ulp file for your setup.

    My board layouts have a giant via at each corner, with the lower-left corner at (0,0). Drilling doesn’t require any fussy alignment, because I etch the board after drilling: the holes serve as bright lights to line up the pads & vias. I’ll have more to say about this elsewhere.

    Speeds and feeds are on the sissy side; I crank the 10k rpm head up to a dangerous chattering whine and feed the drills at 5 inches/min (call it 125 mm/min). Both of those are far too slow, but work OK.

    Run a shop vac to suck up the dust as you drill! I doubt that a typical shopvac filter removes the fines, but it’s better than letting all the dust settle on the mill and in my lungs.

    Circuit board drilling
    Circuit board drilling

    The clamps are these, mounted on studs screwed into the tooling plate.

    Incidentally, the Sherline mill’s throat depth and Y-axis travel limits the board to about 4 inches along the Y axis; yes, with the spacer block installed. That’s just about exactly the maximum size the low-end version of Eagle can produce, so it’s a nice match.

    There are other ways of doing PCBs. I haven’t tried trace-isolation milling, but PCB-Gcode looks like the ticket if you want to generate a breathtaking amount of glass-fiber dust. My quick check shows that it inserts semicolon-delimited comments into the tool-change commands, which EMC 2.2.8 promptly chokes upon, but that’s probably a quick configuration tweak and will change with EMC 2.3 anyway.

    If you’ve got the scratch, there are commercial solutions: Chris Daniel (who was also at the Cabin Fever EMC booth) uses a T-Tech gantry router at work.

    Memo to Self: Expect a call from a patent lawyer either telling me that I’m infringing somebody’s Nearest Neighbor Algorithm claims or asking me for my design notebooks to establish me as the Prior Artist.

  • Stepper Motor Idle Current

    The motor driver box on my Sherline mill started out as a stock unit, but I’ve tweaked the circuitry to improve the analog performance. Those adventures formed the basis of my Above the Ground Plane columns in Circuit Cellar magazine columns for August & October 2004.

    Because the firmware for the PIC microcontrollers wasn’t available, I wrote a clean-room version so I could show how it all worked for the column. My code won’t run on a stock Sherline board, though, so it’s not a drop-in replacement for the stock firmware.

    One of the reasons I attacked the controller was to reduce the audible noise coming from the motors. That’s an inescapable part of chopped-current stepper motor drive circuitry, but the noise was modulated by all manner of things that shouldn’t have affected it; just touching the box shouldn’t make any difference at all. The fact that it did meant the circuit board had some, well, infelicitous layouts.

    Although the final result was much more stable, I decided to turn off each motor if it didn’t move for at least five seconds; that’s a simple firmware tweak when you write your own code. As a result, the shop was quiet when I wasn’t actively milling.

    Solar Measurements Circuit Board - Top Side
    Solar Measurements Circuit Board – Top Side

    Now, having a motor be completely turned off while milling is going on isn’t generally a good idea, because milling forces from the other axes can push the table against the leadscrew and, perhaps, turn the screw against the unresisting motor. I figured that on a Sherline mill, what with the sissy little cuts I take, that wouldn’t be a problem.

    And I was right for the better part of four years!

    A benefit of turning the driver circuitry off was that I could easily twist the knobs by hand to fine-tune the XYZ position during setup. That worked out really well.

    However, drilling the seemingly simple circuit board pattern you see here (for my February 2009 CC column) produced exactly the right collection of forces (while drilling? Huh?), vibration (maybe) and motor pauses (for sure) to introduce an absolutely repeatable positioning error that Went Away when I tweaked the firmware to keep the motors enabled at all times.

    I’ve since made another tweak that reduces the current to an idle level after five seconds. That both reduces the audible noise and drills the board correctly, so I’ll keep an eye on it for a while before declaring victory.

    The PCB has a few unused (in my code, anyway) chip-to-chip connections that I could employ to let them all decide when nobody’s moving. I think turning the motors off 20 seconds after the last axis stops moving should work Just fine; my G-code doesn’t wait around that long except for manual tool changes.

    Update: More on PCB drilling there.

  • Fairing Arcs

    In CNC machining, at least the kind I do on my Sherline CNC mill, you can’t mill around acute inside corners: a round milling bit doesn’t fit into a straight-sided angle. You must add a fairing arc that smoothly connects the two sides; the catch is that “smooth” means it’s tangent to the sides. And EMC2 is really, really fussy about smooth, to the point where you can’t just wing it with a calculator and type in the numbers.

    Fairing arc doodles
    Fairing arc doodles

    There are nice analytic geometry methods for finding the intersection of two line segments, then laying in the arc that connects them, but this example weighs in at over two pages of G-Code. Mostly, what I need is an arc that connects a vertical or horizontal edge to an angled edge, so some simplification is in order.

    Herewith, the quick-and-dirty…

    The cutter enters from the left side, moving horizontally to the right, and will depart along the line toward P1, which might be the next corner of the part. The two material edges meet at P0, the vertex of the angle. The fairing arc is tangent to the two edges at PA and PB, centered at PC, and with a radius R.

    We know the coordinates of P0 and P1 and the arc radius. That radius must be larger than the cutter radius, as you can’t tuck a fat cutter into a narrow corner.

    The problem is to find PA, PB, and PC, so that we can write the G-code commands that travel along the sides & the arc.

    The first step is finding Φ (Phi), the angle between the outgoing edge and the X axis:

    Φ = arctan Δy/Δx = arctan (P1y – P0y) / (P1x – P0x)

    I’m pretty sure if you use a 4-quadrant arctan, as shown in the doodle, all the angles will work out perfectly on either side of the axis, but it’s easy enough to fake the signs to get the right answer in any specific case. If you wanted a general solution, you’d have a two-page subroutine, right?

    You’ll need the complement of that angle, hereinafter known as Theta:

    Θ = 90 – Φ

    Find the distances between various points using good old trig and right triangles:

    • CBx = R · sin Φ
    • CBy = R · cos Φ
    • P0PBy = R · (1 – cos Φ)
    • P0PBx = P0PBy · tan Θ

    Then the coordinates fall out thusly:

    Plastic Spring with Faired Corners
    Plastic Spring with Faired Corners
    • PCy = P0y + R
    • PBy = PCy – CBy
    • PBx = P0x + P0PBx
    • PCx = PBx – CBx
    • PAx = PCx
    • PAy = P0y

    Remember, you do not figure all this out with your calculator and plug the numbers into the G-code, not if you have any sense. If you have just a few corners, write the commands directly, otherwise gimmick up a little subroutine. Earlier versions of EMC2 used numbered parameters (#100), but now that you can have named parameters (#<_Fairing_Radius>), what’s holding you back?

    For example:

    #<_CBy>	= [#<_Fairing_Radius> * COS [#<_Phi>]]	(Y distance PC to PB)

    If your edge doesn’t come in from the left, then manual 90 degree rotations apply.

    0: (x,y) -> (x,y)
    90: (x,y) -> (y,-x)
    180: (x,y) -> (-x,-y)
    270: (x,y) -> (-y,x)

    If you’re using a CAD program to lay out your parts, all this is largely irrelevant. I hammer out the G-code for the simple 2-1/2-D parts I make by hand, so rounding off a few corners comes in handy.

    Because the lines & arc define the material edge contour, you can mill on either side of it and use cutter radius compensation to make the answer come out right. Works like a champ!

    For what it’s worth, the arc is tangent at PA and PB, making the line from PC to the corner (a.k.a. vertex) P0 the bisector of angle Φ. That’s not directly useful here, but keep it in mind when you solve similar problems.

    Update: As of mid-January, the newest trunk version of EMC2 can automagically insert fillets when cutter comp is turned on. That’ll be in the stable version in a while, after which I’ll need this math only for decorative fillets. That’s fine with me!

  • Oscilloscope Screen Shots

    A long time ago I got an HP54602B oscilloscope with a serial port data link. HP provided a sample app that snarfed screenshots & data from the scope, but it wasn’t really ready for prime time and, besides, I vastly preferred to use OS/2 (!) and then Linux rather than Windows.

    Here’s my Kermit script to fetch screenshots. All the software comes more-or-less standard in Ubuntu Linux and (I presume) in most others. If you’re running Windows, you’re on your own.

    Scope Setup

    HP54602B Serial Setup Screenshot
    HP54602B Serial Setup Screenshot

    The oscilloscope’s HP Plotter setting spits out bog-standard HPGL commands in flat ASCII. I’ve always meant to investigate what HP Printer does, but …

    I wish the scope ran faster than 19200 b/s, but that speed works reliably over generic USB-to-serial converters (and the scope can’t feed data that fast, anyway). The other choice, back in the day, was HPIB / GPIB; I’d have had to buy three or four different adapters to suit all the PC data buses since then: ISA, EISA, VLB, PCI …

    Xon/Xoff flow control (a.k.a. handshaking) works better than hardware flow control, simply because the cable’s easier to build.

    The Factors setting adds a bunch of text to the end of the data stream that’s not useful, except for the fact that an HPGL LB instruction follows all of the useful data and gives the Kermit script something to look for. Otherwise, the only way to detect the end of the stream is to time out after a looong time.

    I haven’t the foggiest idea what Resolution does, but High seems appropriate.

    Hardware Notes

    The scope requires a Null Modem in front of a standard DB-25 to DB-9 cable. I’ve been meaning to rewire my standard cable to eliminate the Null Modem, but …

    Adding an LED breakout / monitoring adapter to the serial port loads the signals too much and can lead to puzzling errors. Maybe it’s just my adapter: YMMV.

    I’ve run the cable all the way across my basement lab with no problem. This is, after all, good old RS-232, not some high-falutin’ USB or Firewire interconnect.

    Taking the Shot

    Get a picture you like, poke the Print Screen button, then quick like a bunny run the script. The scope copies the current screen into an internal buffer, then sends out a torrent of HPGL commands. The script will capture the data and eventually spit out a PNG file.

    You may want to Stop the trace, rather than leave it running.

    In XY mode, the scope seems to have trouble copying the entire trace. I tap Auto Store twice, then Stop, then Print Screen. It’s fuzzier, but copies the whole thing.

    What Happens

    The script captures the incoming serial data into a log file, processes that text through the hp2xx program to get an Encapsulated Postscript EPS file, then runs that though convert to get a PNG file. The bank shot off EPS results in better-looking output, for reasons I don’t understand.

    The 240-second timeout value for the Input command seems long, but it takes a lot of plotter commands to define a four-trace plot. A too-short timeout chops off the tail end of the HPGL stream and prompts bizarre error messages from hp2xx.

    The parameters for hp2xx and convert came from protracted and tedious twiddling. The ‘scope image is 512 dots across and 300-some-ish vertically; the output mimics the not-quite-square graticule aspect ratio on the actual screen. If HP thinks it looks good, then it looks good to me.

    The active (bright) traces use Pen 2, which I’ve set to Blue (color 4). The graticule, annotations, and stored traces all use Pen 1, which appears as Black (color 1). Tweak -c 14 as you wish.

    The pen widths (set by -p 34) don’t actually seem to do very much, although I vaguely recall that using the default width of 1 makes the output entirely too faint.

    The PNG has a transparent background that turns white when you actually use it in a document; I suppose you could overlay it atop a background image if you wanted to get cute.

    When the dust settles and the smoke clears, you get PNG images like this. It’s an XY plot, so the blue section appears as a bright trace on the oscilloscope’s screen.

    BH curve for LC0263-A coil
    BH curve for LC0263-A coil

    Kermit Script

    #!/usr/bin/kermit +
    # Fetches screen shot from HP54602B oscilloscope
    # Presumes it's set up for plotter output...
    # Converts HPGL to PNG image

    set modem none
    set line /dev/ttyS0
    set speed 19200
    set flow xon/xoff
    set carrier-watch off

    # Make sure we have a param
    if not defined %1 ask %1 {File name? }

    set input echo off
    set input buffer-length 150000

    # Wait for PRINT button to send the plot
    echo Set HP54602B for HP Plotter, FACTORS ON, 19200, XON/XOFF
    echo Press PRINT SCREEN button on HP54602B…

    log session “%1.hgl”

    # Wait for end of data stream
    input 240 lb

    echo … got final lb command

    close session
    close

    echo Converting HPGL in
    echo — %1.hgl
    echo to PNG in
    echo — %1.png

    # without labels = no terminating lb info
    #run hp2xx -m png -a 1.762 -h 91 -c 14 “%1.hgl”
    #run mogrify -density 300 -resize 200% “%1.png”

    # with labels = terminating lb
    run hp2xx -q -m eps -r 270 -a 0.447 -d 300 -w 130 -c 14 -p 34 “%1.hgl”
    run convert -density 300 -resize 675×452+2+2 “%1.eps” “%1.png”

    echo Finished!

    exit 0