Category Archives: The Heavy Lab

Kwartzlab Radio: On Hiatus

But just for the summer. We’re retooling.

A very, very short episode to let you know just that.

One thing I don’t mention, if you have any feedback, if there’s anything you’d like us to talk about when we get back, or if you just want to say hi, leave a message in the comments.

Kwartzlab Radio Episode 5: The one with Jim Tigwell of Headshots from the Heart.

On another very special episode of Kwartzlab Radio, Darcy and I talk with Jim Tigwell of Headshots from the Heart.  Headshots from the Heart is a 24-hour game marathon that raises money for Child’s Play. It will be held at Kwartzlab on May 18-19. We go into detail with Jim about how it works, how it got started, why they chose Borderlands 2 for the game they play, and other activities that will be going on during the marathon.

Enjoy!

Kwartzlab Radio Episode 5

Kwartzlab Radio Episode 2: Interview with R.J. Anderson

This upcoming week at Kwartzlab during our Tuesday open night we are celebrating the launch of R.J. Anderson’s new novel Quicksilver. In the lead up to this event Darcy had an interview with Rebecca over Skype. Darcy and Rebecca talk about the book and her research. Rebecca also gives a reading from her book when her protagonist ventures to a maker space that may sound a bit familiar.

 

Kwartzlab Radio Episode 2

Kwartzlab Radio Episode 1

Kwartzlab Radio is here!. Inspired by the recordings done by Robert “Gus” Gissing with other members of Kwartzlab which was called “The Heavy Lab”. Kwartzlab Radio will continue with our members and artists-in-residence talking about the things that they are interested in and working on. It’s a get to know us kind of show and I hope you will enjoy.

In the first episode Darcy Casselman and I talk about the formation, culture and history behind kwartzlab.

Kwartzlab Radio Episode 1

LPKF Board Mill, Part 3

We seem to have run into a wall again with the board mill.
Just before last week’s TON I had a bit of an epiphany which cleared up a little mystery but we are otherwise at a standstill again.

The epiphany relates to the relationship between the various microswitches (sensing open covers, tool crib position, and presence of an adequate supply of compressed air) and the value read from “register 6″ on the HF board. When I had been manually sending read commands for this register while actuating the various switches, I at first started jotting down numbers like 0226C, which seemed to map the switches combinatorially, as if the register was returning some interpreted status rather than just 5 bits for 5 switches. Eventually I realized that the ‘C’ was just the command-completion letter, returned by the mill after completion of each command, but values like 0x236 still made no sense. The epiphany was to realize that the ‘C’ had got me thinking the number was hexadecimal, and that mindset remained even after realizing the ‘C’ was not part of the number.
Interpreting the results of the read-register operation as decimal values makes much more sense: the 5 lower bits map to the 5 switches, while the upper three bits are always on (as their inputs are unconnected other than a pullup resistor). So a value like 226 (0xE2) shows the three stuck bits and one microswitch open.

Other that that, not much has been determined. Tonight we looked into whether there was some other switch or interlock that was missing; this might explain the error message that we “had attempted to stop” the tool change. We traced the wiring from the header on the HF board to the known switches and solenoids, but found no place where some other switch might have been connected.

Maybe next week we will try just grounding the other three input lines to see if this makes any difference.

I still find it suspicious that the last command issued before the error message is a read of register 5 (not 6), which returns a zero value. Register 5 at the CPU level is the output bank used to drive the tool crib solenoids. The external wiring of these CPU pins does not provide for any input, so the value read would be whatever the CPU wrote to the solenoids. That just seems to be a strange thing to do… Perhaps some of the bits in this register have been programmed for their special purpose rather than GPIO. I will have to look at the processor documentation to see what special purposes these bits can have.