Ask Hackaday: Auto Bed Leveling And High Temperature Force Sensitive Resistors

March 19, 2014 by Brian Benchoff 39 Comments

FSR

[Johann] over on the RepRap wiki has an ingenious solution for making sure a borosilicate glass bed is completely level before printing anything on his Kossel printer: take three force sensitive resistors, put them under the build platform, and wire them in parallel, and connect them to a thermistor input on an electronics board. The calibration is simply a bit of code in the Marlin firmware that touches the nozzle to the bed until the thermistor input maxes out. When it does, the firmware knows the print head has zeroed out and can calculate the precise position and tilt of the bed.

Great, huh? A solution to bed leveling that doesn’t require a Z-probe, uses minimal (and cheap) hardware, and can be retrofitted into just about any existing printer. There’s a problem, though: these force sensitive resistors are only good to 70° C, making the whole setup unusable for anything with a heated bed. Your challenge: figure out a way to use this trick with a heated bed.

The force sensitive resistors used – here’s a link provided by [Johann] – have a maximum operating temperature of 70° C, while the bed temperature when printing with ABS is around 130° C. The FSRs are sensitive to temperature, as well, making this a very interesting problem.

Anyone with any ideas is welcome to comment here, on the RepRap forums, the IRC, or anywhere else. One idea includes putting an FSR in the x carriage, but we’re thinking some sort of specialized heat sink underneath the bed and on top of the FSRs would be a better solution.

Video of the auto bed leveling trick in action below.

Continue reading “Ask Hackaday: Auto Bed Leveling And High Temperature Force Sensitive Resistors” →

Retrotechtacular: Breaking Atoms To Break The Ice

March 18, 2014 by Mike Szczys 20 Comments

retrotechtacular-lenin-nuclear-icebreaker

This documentary from 1959 gives a satisfyingly thorough look inside a nuclear powered icebreaking ship called Lenin. This actually set a couple of world’s-firsts: it was the first nuclear powered surface vessel and the first civilian vessel to be powered thusly.

The ship was built to clear shipping paths to the northern ports of Russia. Testing of both ice and models of the ship design point to the ability to break ice layers that are two meters thick. This requires a lot of power as ice-breakers generally use their hull shape and gravity to break the ice by driving up onto it to bend the ice to the breaking point. The Lenin achieved this power using its nuclear reactor to heat steam which drove electric generators. The energy produced drove three screws to power the vessel.

Of course this was back in the day when control panels were substantial, which you can get a peek at starting half-way through the twenty-minute film. This includes a demonstration of the ship’s network of radiation sensors which alert the control room, and sound a local alarm when they are triggered. During it’s 30-year operational life the vessel had a couple of accidents stemming from refueling operations. You can find more on that over at the Wikipedia page, but stick with us after the jump to see the vintage reel.

Continue reading “Retrotechtacular: Breaking Atoms To Break The Ice” →

Hackaday Links: March 16, 2014

March 16, 2014 by Mike Szczys 10 Comments

Tape decks are fertile hacking ground. In this offering from [Erich] the speed of the motor has been turned into a MIDI instrument. Drive it faster and the pitch rises, slower and it falls. There are all kinds of other magnetic tape hacks around here, this tape delay is a classic.

[Dbever] needed a reason to use a big 7-segment display module. He opened up the drill press at his Hackerspace, Pumping Station One, and added a sensor which shows the RPM of the drill on the display. Hackaday was lucky enough to be invited for a tour of the space last fall.

There’s a lot of hype about 3D printing… and rightly so since it’s the radest; which is even better than being “the most rad”. But if you don’t have access to one that shouldn’t stop you. Here’s an example of making robot parts using polymorph instead of 3D printing (or laser cutting) them.

If you’re living in the east-coast metroplex and are unable to travel to Maker Faire Bay Area this Spring you can still get in on some live hacking. Check out MassHack which takes place the same May weekend but in Boston instead of San Fran.

Blimps; not as cool as quadcopters but orders of magnitude less likely to go down in flames (as it were). Draw some inspiration for your own build from silent_runner. The graceful travel of these lighter-than-air-craft make for an interesting camera platform. Here’s a POV video inside of a church, and some shots from the ground while in the woods. [Thanks Oliver]

We try not to pimp crowd-funding campaigns just for the sake of getting them to the goal. But we hope you’ll agree that the Gamebuino we saw a few months back makes a strong argument for backers. Their Indiegogo for the Arduino-compatible handheld gaming rig is over half-way there after just a couple of days.

Developed On Hackaday: Security And Arduino Compatibility

March 16, 2014 by Mathieu Stephan 56 Comments

Some of our readers noticed that the Hackaday community open-source offline password keeper (aka Mooltipass) has two incompatible characteristics: being secure and Arduino compatible.

Why is that? Arduino compatibility implies including a way to change the device firmware and accessing the microcontroller’s pins to connect shields. Therefore, some ill-intentioned individuals may replace the original firmware with one that would log all user’s inputs and passwords, or in another case simply sniff the uC’s signals. The ‘hackers’ would then later come to extract the recorded data. Consequently, we needed a secure tamper-proof Mooltipass version and an Arduino-compatible one, while allowing the former to become the latter.

Olivier’s design, though completely closed, will have several thinner surfaces directly above the Arduino headers. As a compromise, we therefore thought of sending a bootloader-free assembled version to the people only interested in the password keeper functionality, while sending a non-assembled version (with a pre-burnt bootloader) to the tinkerers. The Arduino enthusiasts would just need to cut the plastic at the strategic places (and perhaps solder headers to save costs). The main advantage of doing so is that the case would be the same for both versions. The drawback is that each board would have a different firmware depending on who it is intended for.

What do our reader think? For more detailed updates on the Mooltipass current status, you can always join the official Google group.

Hackaday 68k: Gluing Architecture Buffer Maps

March 13, 2014 by Brian Benchoff 24 Comments

It’s time for more blatant advertising for Hackaday Projects, the best project hosting site on the Internet. Did we tell you it’s collaborative? That you and your friends can work on projects together? Want more encouragement to join? How about a contest with prizes that include oscilloscopes, FPGA dev boards, soldering and rework stations, Beaglebones and Raspberries and Spark Cores? Oh my!

Oh. We’re also developing a retrocomputer to show off the features of Hackaday Projects. This is the latest update, showing off the architecture of the entire system, the memory map, and the logic glue and buffers. The plan for this project is to have it host another awesome Hackaday site, our retro version, a small off-shoot of the main Hackaday site that’s specifically designed to be loaded by computers built before 1993. There haven’t been many retro successes in the Hackaday tip line recently, so if you manage to get a vintage computer to pull the retro site up, snap a pic and send it in.

For those of you wanting to catch up on the Hackaday 68k project, here’s the Hackaday Projects page, and here’s all the front page updates. Click that ‘Read more…’ link for the update.

Continue reading “Hackaday 68k: Gluing Architecture Buffer Maps” →

Fail Of The Week: Unconnected Nets In KiCad

March 13, 2014 by Mike Szczys 15 Comments

fotw-unconnected-net

From the title and the image above you surely have already grasped this Fail of the Week. We’ve all been there. Design a board, send it to fab or etch it yourself, and come to find out you’ve missed a connection. Automatic checks in your software should prevent this, but when making small changes it’s easy to overlook running the checks again. This is exactly what [Clint] did with this board; leaving a net unconnected in the schematic, which made its way through to the board layout and into the OSHPark boards.

Okay, so fix it with jumper wire which is clearly what he did (white wire in the lower left image above). But since this is rev3 of his PCB it’s pretty upsetting that it happened. The meat and potatoes of the fail is the missing software feature that led to it. KiCad doesn’t have a pin swap tool in the board layout. Really? We use KiCad frequently and didn’t realize that the feature was missing. Needing to simplify his board layout, [Clint] went back to the schematic to swap some resistor network pins by hand. He pushed the change through the netlist and into the board layout, not realizing he had left an input gate unconnected.

A bit of searching proves that pin swapping may be coming to KiCad soon. It’s on the CERN roadmap of features they plan to add to the open source PCB layout software. We remember hearing about CERN’s plans quite a while ago, and thought we featured it but the only reference we could find is [Chris Gammell’s] comment on a post from back in December. It’s worth looking at their plans, these are all features that would make KiCad a juggernaut.

EDITORIAL NOTE: We’ll soon be out of story leads for this series. If you have enjoyed reading weekly about fails please write up your own failure and send us the link. Of course any documented fails you find around the internet should also be sent our way. Thanks!

Fail of the Week is a Hackaday column which runs every Wednesday. Help keep the fun rolling by writing about your past failures and sending us a link to the story — or sending in links to fail write ups you find in your Internet travels.

Developed On Hackaday: Coding Conventions And GitHub Pull Requests

March 12, 2014 by Mathieu Stephan 100 Comments

The Hackaday community is currently very busy coding the low-level libraries of our open-source offline password keeper project. And when many talented contributors work together on a common concept, interesting discussions take place. In our dedicated Google Groups, some of them were about the choice of naming/coding conventions and also how/when to approve GitHub pull requests. But don’t leave already… this topic is actually more interesting than it sounds.

The age difference between the older and younger firmware contributor is guessed to be approximately 30 years… and many things can happen in such a time frame. Even though our coders are writing in C, most of them code in other programming languages at school/work. They also use different text editors on different operating systems. Understandably, each one of them therefore has its preferred coding / naming convention and indent style. The Mooltipass conventions were selected based on majority voting, and after many emails we settled on an Allman style convention with camelCase:

main(void)

{

if (foo)

{

functionCall();

}

else

{

foo = 0;

anotherFunctionCall();

}

}

– 79 characters line length as a soft requirement

– 4 spaces, no tabs

Most of the contributors believe that it is the best compromise between code clarity and cross-platform compatibility, but we would be curious to know our Hackaday readers’ opinions on this particular topic.

The second matter is a bit more of a management one. What is the best strategy to manage and review code changes made to a main GitHub repository, when a project is at its infancy and composed of (more or less) non-remunerated contributors?
It is perfectly understandable that interest, spare time and willingness to contribute may vary over time. Perhaps some of our readers may already be familiar with Agile software development, a group of software development methods based on iterative and incremental development, which promotes adaptive planning, evolutionary development and encourages rapid and flexible response to change. Do you think this can be applied to the Mooltipass project?

We would be curious to hear similar experiences on these topics, as we gladly accept constructive criticism. You may also want to join our dedicated Google group to check out the different discussions that already happened there. On a side note, we are also currently looking for capacitive wheel / touch button footprints libraries for Kicad.