Sintering Sand WIth A Laser Cutter

We are all used to Fused Deposition Modeling, or FDM, 3D printers. A nozzle squirts molten material under the control of a computer to make 3D objects. And even if they’re usually rather expensive we’re used to seeing printers that use Stereolithography (SLA), in which a light-catalysed liquid monomer is exposed layer-by layer to allow a 3D object to be drawn out. The real objects of desire though are unlikely to grace the average hackspace. Selective Laser Sintering 3D printers use a laser on a bed of powder to solidify a 3D object layer by layer.

The laser creating a ring.
The laser creating a ring.

While an SLS printer may be a little beyond most budgets, it turns out that it’s not impossible to experiment with the technology. [William Osman] has an 80 W laser cutter, and he’s been experimenting with it sintering beach sand to create 2D objects. His write-up gives a basic introduction to glassmaking and shows the difference between using sand alone, and using sodium carbonate to reduce the melting point. He produces a few brittle barely sintered tests without it, then an array of shapes including a Flying Spaghetti Monster with it.

The results are more decorative than useful at the moment, however it is entirely possible that the technique could be refined. After all, this is beach sand rather than a carefully selected material, and it is quite possible that a finer and more uniform sand could give better results. He says that he’ll be investigating its use for 3D work in the future.

We’ve put his video of the whole process below the break, complete with worrying faults in home-made laser wiring. It’s worth a watch.

Continue reading “Sintering Sand WIth A Laser Cutter”

Akiba: Shenzhen in 30 Minutes

Multi-talented hacker extraordinaire and electrical engineer [Akiba] is based in Japan, and this makes it just a hop, skip, and a jump over to Shenzhen, China, the hardware capital of the world. He’s led a number of manufacturing tours aimed at acquainting hackers with the resources there, and now he’s giving you the benefit of his experience in a 30-minute video. It’s great.

Continue reading “Akiba: Shenzhen in 30 Minutes”

Official: Pebble Ceases Hardware Production

Today Pebble has announced that it will cease all hardware production. Their outstanding Kickstarter deliveries will not be fulfilled but refunds will be issued. Warranties on all existing hardware will no longer be honored. However, the existing smartwatch service will continue… for now.

This isn’t unexpected, we ran an article yesterday about the all-but-certain rumors FitBit had acquired Pebble (and what led to that). Today’s news has turned speculation about Pebble 2 and Pebble Core Kickstarter campaigns into reality. You won’t get your hands on that fancy new hardware, but at least backers will have the money returned.

Perhaps the most interesting part of today’s blog post from the founder of Pebble, Eric Migicovsky, is about how this impacts more than a million watches already in the wild. Service will continue but (wait for it) “Pebble functionality or service quality may be reduced in the future.”

It’s not like this is a unique problem. Devices purchased by consumers that are dependent on phoning home to a server to function is a mounting issue. Earlier this year [Elliot Williams] coined this issue “Obsolescence as a Service” which is quite fitting. Anyone who still has a functional first generation iPad has enjoyed reduced quality of service; without available upgrades, you are unable to install most apps. It’s zombie hardware; electrons still flow but there’s no brain activity.

One of the perks associated with FitBit acquiring Pebble is that they have decided to keep those servers running for watches in the field. A cynic might look at the acquisition as FitBit reducing competition in the market — they wouldn’t have let hardware production cease if they were interested in acquiring the user base. At some point, those servers will stop working and the watches won’t be so smart after all. FitBit owns the IP which means they could open source everything needed for the community to build their own server infrastructure. When service quality “reduced in the future” that’s exactly what we want to see happen.

Assembly Required: Subroutine Calls and the 1K Challenge

The first computer I personally owned had 256 bytes of memory. Bytes. The processor in my mouse and keyboard both have more memory than that. Lots more. Granted, 256 bytes was a bit extreme, but even the embedded systems I was building as part of my job back then generally had a small fraction of the 64K bytes of memory they could address.

Some people are probably glad they don’t have to worry about things like that anymore. Me, I kind of miss it. It was often like a puzzle trying to squeeze ten more bytes out of an EPROM to get a bug fix or a new feature put in. I though with the 1K challenge underway, I might share some of the tricks we used in those days to work around the small memory problems.

I Can’t Help You…

Unfortunately, optimization at this level very often requires specific solutions and no one can help you unless they know exactly what you are doing. Often, the best ways to save memory involve either changing your algorithm or using CPU-specific features. For example, if you are storing a lot of strings but don’t need a lot of characters, perhaps you can pack your strings. On the right CPU, you might spend two bytes writing:

MOV B,#0

This presumably clears hypothetical register B and usually takes two bytes of encoding (one byte for the MOV with a bitfield that indicates the B register, and another byte for the literal zero). However, if available, an XOR instruction probably takes one byte:

XOR B,B

This also zeros register B since the XOR of anything with itself is zero. A subtract could do the same thing, if that’s available.

These are all specific to your project and platform, though. So for those sort of things you are on your own.

But, Some Things are Universal

One of the easiest ways to change your program involve subroutines. Most CPUs have some facility for call and return (although my 256 byte computer didn’t, oddly). The first rule is to use them. If you have four or five instructions being repeated, that’s a good candidate for a subroutine. Common sense, right? But there are a few other tricks involving subroutines to keep in mind.

The first idea is to look for items you can move into a subroutine, even if it requires a little tweak somewhere in the code. To illustrate this (and some other ideas) I went to this online assembly language simulator. It has a simple assembly language that is similar to real CPUs. The ability to be able to step through the code in your web browser is nice, too. Of course, you’ll have to apply the concepts to your specific CPU.

Below is a simple program to read a four-character ASCII string that represents a decimal number and puts it in a 16-bit register. So the string “255” will turn into 00FF in the register.

; Simple example
; Convert decimal # at istring into 16-bits in B:C
   JMP start

start:
   CALL convert
; more interesting things happen here
   HLT
convert:
   MOV B,0
   MOV C,0  ; answer in B:C
   MOV D, istring    ; Point to var
   CALL decdig  ; convert each digit
   INC D
   CALL decdig
   INC D
   CALL decdig
   INC D
    CALL decdig
    RET

shift16:
   MOV A,0
   SHL C,1
   JNC shift16a
   INC A
shift16a:
   SHL B,1
   ADD B,A   ; output carry is meaningless
   RET

decdig:
   CALL shift16; *2
   PUSH B
   PUSH C
   CALL shift16; *4
   CALL shift16    ; *8
   POP A
   ADD C,A   ; 8X+2X=10X!
   JNC decdig0
   INC B

decdig0:
   POP A
   ADD B,A
   MOV A,[D]
   SUB A,'0'
   ADD C,A
   JNC xret
   INC B
xret:
   RET

istring: DB "1924" ; input
         DB 0 ; String terminator

end:

This assembles into 89 bytes. Not much, but we can do better. The first thing to notice is that the D register holds the address of the string. The program loads it at the start and after each call to the digit conversion subroutine, there is an increment to point to the next character. One obvious way to save some space is to factor the increment instruction into the subroutine. You can put it towards the end, or–if it makes more sense–load the address minus one (most assemblers can figure that out at assembly time). In this case, it doesn’t really matter, but either way will get you to 85 bytes. I put the POP D instruction after the xret label and the convert routine now looks like this:

convert:
MOV B,0
MOV C,0 ; answer in B:C
MOV D, istring ; Point to var
CALL decdig ; convert each digit
CALL decdig
CALL decdig
CALL decdig
RET

Notice those last two lines. You can shave a byte by changing the final CALL into a JMP. The return at the end of decdig will go back to the original caller. You can save even more space by rearranging the code so that decdig appears right at that spot:

CALL decdig
CALL decdig
CALL decdig
decdig: ...

You can apply this even more. Notice that you have 4 calls to decdig which could be considered two groups of two. So you could write:

CALL decdig2
decdig2:
CALL decdig
decdig: ....

You might have to think about that for a minute. The first call executes two operations and the return goes back to decdig2 where you do two more operations. At the end, the return goes back to the original caller.

Readability

That’s not very readable, I’ll admit. Comments are free, so you should use them if you aren’t writing a blog post around the code. In particular, any time code depends on being in a particular location, you ought to document it:

CALL decdig2:
; **** FALL THROUGH
decdig2:

This prevents you from accidentally moving it or inserting code and breaking things. Now we are at 80 bytes. You can pull the same trick with the shift16 subroutine, but since it is only called once, there’s no real savings in this case.

Saving 9 bytes doesn’t seem like much, but it is about 10% of the original code. Sometimes that’s all you need. You could probably optimize the algorithm, too.

Return Conversions

On some CPUs, you can do  conditional return (that is, like return on zero or RZ). But on other processors, you can only do a branch or jump on a condition. This leads to code like this:

JNZ nextinst
RET
nextinst:

However, you probably have a return somewhere in your code already (like the xret label in the example program). That means you can write:

JZ xret

There you’ve saved another byte. Like pennies, they all add up.

Your Turn

What’s your favorite space-saving trick? Share it in the comments unless you want to save it as your secret sauce for the 1K challenge. You have until January 5th to squeeze out those extra bytes.

 

Arduino Laser Pinball is On Target

Have you ever wanted to roll your own pinball machine? It’s one of those kinds of builds where it’s easy to go off the deep end. But if you’re just getting your feet wet and want to mess around with different playfield configurations, start with something like [joesinstructables]’ Arduino Laser Pinball.

It’s made from meccano pieces attached with standoffs, so the targets are easy to rearrange on the playfield. [joesinstructables] wanted to use rollover switches in the targets, but found that ping pong balls are much too light to actuate them. Instead, each of the targets uses a tripwire made from a laser pointing at a photocell. When the ping pong ball enters the target, it breaks the beam. This triggers a solenoid to eject the ball and put it back into play. It also triggers an off-field solenoid to ring a standard front-desk-type bell one to three times depending on the target’s difficulty setting.

The flippers use solenoids to pull the outside ends of levers made from meccano, which causes the inside ends to push the ball up and away from the drain. Once in a while a flipper will get stuck, which you can see in the demo video after the break. An earlier version featured an LCD screen to show the score, but [joesinstructables] can’t get it to work for this version. Can you help? And do you think a bouncy ball would actuate a rollover switch?

This isn’t the first pinball machine we’ve covered. It’s not even the first one we’ve covered that’s made out of meccano. Here’s an entire Hacklet devoted to ’em. And remember when an Arduino made an old table great again?

Continue reading “Arduino Laser Pinball is On Target”

You Can Have My LM386s When You Pry Them From My Cold Dead Hands

Everyone has a chip-of-shame: it’s the part that you know is suboptimal but you keep using it anyway because it just works well enough. Maybe it’s not what you would put into a design that you’re building more than a couple of, but for a quick and dirty lashup, it’s just the ticket. For Hackaday’s [Adam Fabio], that chip is the TIP120 transistor. Truth be told, we have more than one chip of shame, but for audio amplification purposes, it’s the LM386.

The LM386 is an old design, and requires a few supporting passive components to get its best performance, but it’s fundamentally solid. It’s not noise-free and doesn’t run on 3.3 V, but if you can fit a 9 V battery into your project and you need to push a moderate amount of sound out of a speaker, we’ll show you how to get the job done with an LM386.

Continue reading “You Can Have My LM386s When You Pry Them From My Cold Dead Hands”

Turn cheap USB soldering irons in to tweezers

This is 2016, and almost every hacker dabbles with SMD parts now, unlike back in the day. This means investing in at least some specialized tools and equipment to make the job easier. One handy tool is the SMD soldering tweezers – useful not only for manual soldering of parts, but also for de-soldering them quickly and without causing damage to the part or the board. Often, especially when repairing stuff, using a hot air gun can get tricky if you want to remove just one tiny part.

smd_tweezer_04[adria.junyent-ferre] took a pair of cheap £5 USB soldering irons and turned them into a nifty pair of SMD soldering tweezers. The two irons are coupled together using a simple, 3D printed part. [adria]’s been through a couple of iterations, so the final version ought to work quite well. The video after the break shows him quickly de-soldering a bunch of 0805 SMD resistors in quick succession.

Earlier this year, we had posted [BigClive]’s tear down of these 8 watt USB soldering irons which turned out to be surprisingly capable and this spurred [adria] to order a couple to try them out.

The 3D printed part is modeled in SolveSpace – a parametric 2D and 3D CAD software that we blogged about a while ago. Continue reading “Turn cheap USB soldering irons in to tweezers”