The Living Computers museum in Seattle has a Xerox Alto, the machine famous for being the first to sport a mouse-based windowing graphical user interface. They received it in working condition and put it in their exhibit, but were dismayed when a year later it ceased to operate. Some detective work revealed that the power supply was failing to reach parts of the machine, and further investigation revealed an unlikely culprit. Electromigration had degraded the contacts between the supply pins and the backplane traces.
This one just doesn’t pop up very often. But in the case of the Alto, an under-specified power distribution system caused a lot of current to flow through too few solder joints. Those joints were left without enough metal to make a decent connection, so they failed.
The fix came with a set of sturdy busbars freshly soldered to the pins, but the interest in this piece comes more from the unusual phenomenon that caused it. That soldered joints can seemingly flow away defies belief. It’s still something most of us will never encounter, but like tales of ball lightning it’s one for the “Fancy that!” collection.
All the cool kids are doing it these days, or more like for many years now: you can get a laser cutter for a song if you don’t mind doing your own repairs and upgrades — you know, being a hacker. The downside is that some failures can really ruin your day. This is what [Erich Styger] encountered with his cutter that is just a bit more than a year old. This Fail of the Week looks at the mysterious death of a CO2 laser tube.
This is the infamous K40 laser cutter. Our own [Adam Fabio] just took one on a couple of months back and [Erich] even references Hackaday coverage of the K40 Whisperer project as what pushed him over the edge to make the purchase. We’ve followed his blog as he acquired the cutter and made upgrades along the way, but after an estimated 500 hours of use, a horrible teeth-gnashing screech sprung forth from the machine. [Erich’s] reaction was to hit the e-stop; that’s certainly why it’s there.
Chasing down the problem is a story well-told, but as is often the case with these FotW articles, in the end what caused the failure is not entirely known. We’d love to hear what you think about it in the comments below.
The investigation began at the power supply for the laser, but that didn’t yield any answers. Next he moved to the tube itself, noticing that the wire connection to the tube’s anode wasn’t soldered. The anode is an unknown material he suspects to be graphite and he found a video showing the “soldering” process for connecting a wire. (We added quotes to that as the video he linked doesn’t actually solder anything but the wrapped wire strands themselves.) The solution he found is a great tip to take away from the story. It’s a socket by TE Connectivity to which he soldered the wire. Assuming it’s power rated for the task, and won’t fall off during normal operation, this is a great way to do it.
But we digress. Even with the connection made, the old tube had to be replaced with a new one. It’s also notable that the portion of that anode inside the bad tube is orange in color when a new tube would be black like the part on the outside. Does this hint at why that tube died, and could this have been avoided? If you have insight, help us learn from this failure by leaving a comment below.
A few weeks ago an incredible video of an engine exploding started making the rounds on Facebook. This particular engine was thankfully in a dyno room, rather than sitting a couple of feet away from a driver on a track. We’ve all seen engine carnage videos before, but this one stands out. This diesel engine literally rips itself apart, with the top half of the engine flipping and landing on one side of the room while the bottom half sits still spinning on the dyno frame.
Building performance engines is part science, part engineering, and part hacking. While F1 racing teams have millions of dollars of test and measurement equipment at their disposal, smaller shops have to operate on a much lower budget. In this case, the company makes their modifications, then tests things out in the dyno room. Usually, the tests work out fine. Sometimes though, things end spectacularly, as you can see with this diesel engine.
The engine in question belongs to Firepunk diesel, a racing team. It started life as a 6.7 liter Cummins diesel: the same engine you can find in Dodge Ram pickup trucks. This little engine wasn’t content to chug around town, though. The Firepunk team builds performance engines — drag racing and tractor pulling performance in this case. Little more than the engine block itself was original on this engine. Let’s take a deeper look.
NYC beaches are where tropical beaches addicted to meth go to die. So says [Vije Miller] in his write-up for his Arduino sand matrix printer. It’s a clever idea, five servo-operated cardboard plungers that indent a pattern of dots in the sand as the device is pulled forward, resulting in something not unlike a dot matrix printer that can write messages in the sand.
He’s submitted it to us as a Fail Of The Week, because it doesn’t do a very good job of writing in the sand, and it’s burned out a servo. But we feel this isn’t entirely fair, because whether or not it has delivered the goods it’s still an excellent build. Cardboard isn’t a material we see much of here at Hackaday, but in this case he’s mastered it in a complex mechanism that while it may have proved a little too flexible for the job in hand is nevertheless a rather impressive piece of work.
You can see a brief video below the break showing it in action. He tells us his motivation has waned on this project, and expresses the hope that others will take up the baton and produce a more viable machine.
If you are a regular at creating printed circuit boards, it is likely that somewhere in your shop there will be a discard pile of boards on which you placed a component in the wrong orientation such that it would not work. It’s easily done, and don’t be shy to admit it if it’s happened to you.
[Bill] was making his own ARM developer board, taking inspiration from the ARM Pro Mini. He produced his PCB design and sent it off to the board house, and in due course received and reflow soldered a batch of beautiful dev boards. On power-up though, something was wrong! No USB device detected on his computer, a disaster. A lot of studying board and schematic led to the discovery that his push-button switches had been placed at 90 degrees to the orientation it should have had, leaving them in a permanently “on” position.
The PCB bug makes this is a Fail Of The Week post, but he transformed into a win with some experimentation with the switch outline in KiCAD before finding a way to mount the switches on the pads at 45 degrees, covering three of the pads. Well done, and well done for admitting the error.
[Editor’s note: been there, done that. One way to prevent the error is to only connect to diagonally opposite pins of the tact switch, so the rotation doesn’t matter.]
Having earlier asked others to come clean with their PCB mistakes, it’s probably appropriate to admit that Hackaday scribes are just as fallible as [Bill] when it comes to PCB layouts. Somewhere there may still be a board on this bench with a QFN microcontroller bodged on at 90 degrees to its original orientation, with cut tracks and tiny wire runs.
Museum exhibits are difficult to make, and they’re always breaking down; especially the interactive ones. This is a combination of budget, building a one-off, and the incredibly harsh abuse they take from children.
My first exhibit is an interactive laser show that turns waveforms from music into laser patterns, and different types of music have very different patterns. I knew from talking to the museum staff that industrial buttons were a necessity, but it turns out that industrial buttons are made under the assumption that tiny creatures won’t be constantly mashing, twisting, and (ew ew ew) licking the buttons. After a while, the buttons (and poor knob) were trashed.
The second exhibit is also interactive, but in this case it’s just a simple button that turns on a thing for a while, then shuts it off. You can read more about the Periodic Table of Motion on the project page. Here I thought; let’s use capacitive touch, put the sensor behind two layers of acrylic for protection, and then there won’t be any moving parts to break. I built a bunch of units, tested it for weeks, then installed it. Instant failure despite my diligence.
Something is different about the installation from my test environment. It might be the second layer of acrylic contributing. Maybe it’s the power supply and a strange ground issue. Maybe the room’s fluorescent lights are creating an electromagnetic field that is interrupting the sensor, or the carpet is causing static buildup that is somehow causing the midichlorians to reverse polarity and discharge through the base plate of prefabulated aluminite. In some of the cells, the button doesn’t work. In other cells it is extremely sensitive. In one column of the table (columns share a common piece of acrylic among 5 cells), a single touch will trigger all 5.
The circuit is an ATtiny with a 2.2M resistor between two pins, one of which connects via a short wire to a soldered connection to a piece of copper tape on the underside of an acrylic piece. The ATtiny is using the capsense library, which has features for automatic recalibration. Because of the way it is installed, I can’t reprogram them to adjust their sensitivity while inside the enclosure, so tweaking them post-install is not an option. I thought I could isolate the problem and use an existing capacitive touch sensor breakout of the AT42QT1010 hooked up to just power, but it had the exact same issue, meaning it’s either the power supply, the enclosure, or the room.
There are three paths I can go down now:
Find the problem and solve it
Switch to a photoresistor
Petition Hackaday for a better solution
Finding the problem and solving it will be a long and difficult path, especially since the museum environment is somehow and inexplicably different from the test environment. The photoresistor option has promise; when the user puts their hand over the paper button the light level changes. Some early testing indicates that it is easy to detect instantaneous change, and a trailing average and adjusting threshold make it robust enough for changing lighting conditions throughout the day. Further, it’s a simple change to the code, and the existing circuit board will accommodate the adjustment.
As for the third option…
What have you done for child-compatible touch interfaces that are robust enough to handle uncertain environments and harsh abuse? What buttons, knobs, and other interactive elements have you used?
Has work been a little stressful this week, are things getting you down? Spare a thought for an unnamed sysadmin at the GitHub-alike startup GitLab, who early yesterday performed a deletion task on a PostgreSQL database in response to some problems they were having in the wake of an attack by spammers. Unfortunately due to a command line error he ran the deletion on one of the databases behind the company’s main service, forcing it to be taken down. By the time the deletion was stopped, only 4.5 Gb of the 300 Gb trove of data remained.
Reading their log of the incident the scale of the disaster unfolds, and we can’t help wincing at the phrase “out of 5 backup/replication techniques deployed none are working reliably or set up in the first place“. In the end they were able to restore most of the data from a staging server, but at the cost of a lost six hours of issues and merge requests. Fortunately for them their git repositories were not affected.
For 707 GitLab users then there has been a small amount of lost data, the entire web service was down for a while, and the incident has gained them more publicity in a day than their marketing department could have achieved in a year. The post-mortem document makes for a fascinating read, and will probably leave more than one reader nervously thinking about the integrity of whichever services they are responsible for. We have to hand it to them for being so open about it all and for admitting a failure of their whole company for its backup failures rather than heaping blame on one employee. In many companies it would all have been swept under the carpet. We suspect that GitLab’s data will be shepherded with much more care henceforth.
We trust an increasing amount of our assets to online providers these days, and this tale highlights some of the hazards inherent in placing absolute trust in them. GitLab had moved from a cloud provider to their own data centre, though whether or not this incident would have been any less harmful wherever it was hosted is up for debate. Perhaps it’s a timely reminder to us all: keep your own backups, and most importantly: test them to ensure they work.