AncientJames

This is a mechanical bitmap display I've just built. Currently putting together an LDD file for it.

Here's a device I've built which implements Conway's Game of Life:

I built another row, and made some improvements to the sequencing system. It's now big enough to run a cycle of a glider:

I just built a cell from that model, and I discovered a few errors. Most importantly, it has two of the angled connector #3, where it should be using #5. I'll upload a fixed version, but look out for that if you do try building from the original model.

I've uploaded a model of the cell mechanism to bricksafe here. I used stud.io this time, but I can export it as something else if that's not generally convenient. The chassis and control unit will take a while to model, but will eventually appear in the same place. The cell is a pretty easy build - apart from making sure the moving parts move freely, there's no finessing or calibration needed. Just snap it together and it works. I couldn't get the rubber bands right in the model. It should be obvious where they attach. Knock the red lever to make it count. Push the orange liftarms up to make it flip. I haven't actually built one from this model, so consider it untested. Please let me know if you try building one and it doesn't work.

Oh yes, I was really excited when I saw your cellular automaton! My device does have a restriction on its rules that any given neighbour count can only flip in one direction. You can't, for example, have a rule where 3 neighbours will cause a dead cell to be born and cause a live cell to die. I'd like to try different rules, but Life has always been the one I come back to. You can implement the von Neumann neighbourhood by replacing the probe at the back with a shorter axle. An interesting possibility, since each cell carries its own copy of the rules, is to have different rules in different places. Using lower neighbour counts along the edges might help counteract the small size of the matrix.

I only finished this iteration of it at the weekend, so I don't know about long term reliability. It hasn't jammed or miscalculated yet. With a 3x3 matrix there isn't really any long sequence - I cranked the handle on a blinker until I got bored. There's a lot of building to do to get it up to the next grid size. Bonus build timelapse: http://www.youtube.com/watch?v=LtFyHihO5Cg

Vertically it would grind to a halt pretty soon, but horizontally, you could put a motor on each column and stack them indefinitely.

There's a fair bit going on here, and I'm still making the LDD files for it. The principle is pretty straightforward. In order to implement Life, you need a matrix of cells. At each step, each cell needs to count the number of live neighbours, and then change its own state based on that count. 3 live neighbours will cause a dead cell to come to life. 2 or 3 live neighbours will allow a live cell to stay alive. Any other count will result in the cell dying or remaining dead. Each cell is identical. At the front is the display, which can show alive (orange) or dead (black). At the back is a turntable which is used to poll its neighbours. At the heart of each cell is this setup: As the turntable revolves, each live neighbour it encounters knocks a lever which pulls on the axle on the right. This moves the blue linkage, which pushes the grey rule block up by one tooth. After a full revolution, the red pieces on the left are pushed in, and depending on whether they hit a tile or a gap in the grey rule block, push a rod on the left or the right of the mechanism. This sets the state to alive or dead. The block then drops down back to its starting position, and the cycle starts again. It's all modular, and given enough Lego you could make an arbitrarily large matrix. You can also swap out the rule block if you want to run a different cellular automaton.

I've just discovered bricksafe, so I've uploaded a little web app for programming the cards: http://www.bricksafe.com/files/AncientJames/flipdot/card.html

Awesome! Did you do it by hand, or is there a tool that automatically flips? Either way, thank you. The three blue 1x1 plates should be a single 1x3 plate, but LDD considers that to be illegal. The floating piece is something I've gone back and forth over - it goes on the steering arm at the bottom, replacing the 2L axle with a bar. This provides a little bit more play in the connecting rod to the press mechanism, which affects how smoothly it all runs. My current build doesn't use it, and I should have removed it from the file.

I've shared the LDD file for this display here: http://1drv.ms/1bSM59J This first version doesn't show the full construction. The missing pieces are all just mirror images of the other side, so all the information you'd need to build one is still there. I'm not sure whether it's more work to manually fill in the other side, or to write a tool to do it automatically. Some parts aren't currently available in LDD, and I've had to make substitutions. Where I've done this, I've coloured the substituted parts in pastel blue. The missing parts are:

And Kotaku: http://kotaku.com/mechanical-lego-display-is-another-level-of-awesomeness-1699666287

I just used that 16L link in my latest MOC! I got 8 of them in 1999 with the Y-Wing, and I hadn't used them for 15 years. It was a joyous moment when I found I needed a link of (almost) exactly that length.

The old scrolling version would probably be less of a headache at a show - you just turn it on and leave it going. The new one, you spend most of your time restacking the hopper. I'll have a go at attaching the LDD file for it. (edit: Looks like that didn't work.) There are some changes that would make it neater and more robust (I basically abandoned this version when I had the idea for the new one), but the big advantage is that you can make it as wide as you like.

You should totally build one! I'd love to see how well it works connecting two together.

I'm probably bringing it to Christchurch, but still dithering at the mo. I haven't bought the 8880.

This is great! Making a playable one (with an unpredictable sequence) would be a lot of fun.

My previous attempt used a continuous loop, although it was a bit slow and rickety: My goal with the new one was to make it update the whole screen in one go, do it quickly enough that I could display animations, and have a compact way of storing the data. If I do another one, looping will be at the top of my list.

There's no reason it couldn't be motorised. Recycling the cards is something it really should do. I decided not to attempt that for this version because I figured it was going to be tricky enough getting it to work at all. It's something that would probably be too cumbersome to retrofit, and at some point I'll probably have another go from scratch. It would work best if the cards came back out the way they went in, rather than passing right through the mechanism.

No, it's used as a shiny gold half-width spacer!

Here's a static picture of the display, showing the letter R, and the card used to program that pattern. I used white and black cones to make it a bit clearer how the pattern on the card corresponds to the pattern on the display. Here's a quick overview of how it works. Each pixel looks like this: The vertical axles at the back are the inputs. Raising the black axle pushes the red axle over to the right; raising the white axle pushes it over to the left. This flicks the blue angle piece up or down, showing or hiding the white disk. It takes very little force, and the transition is satisfyingly quick and positive. (I recommend building one and having a play with it.) There are 25 of these in a grid, and they sit above a matrix of push rods. The rods progressively crank inwards, to bring the 19 stud span of inputs down in to 11 studs, so they can be driven by a 6x12 plate. (I put cones between the plate studs, so it has 5x11 bits, and I leave the middle column empty to keep things nice and symmetrical.) The push rods use axles with stops at the bottom. This lets me pull them down between presses - if I leave it to gravity, they sometimes get stuck in the raised position and jam the mechanism on the next press. The fun part is the crazy pile of linkages. Here they are colour-coded to make them clearer: The blue linkage is Chebyshev's lambda mechanism. It moves in a straight line for about half the cycle, then drops down out of the way for the return stroke. This is the bit that carries cards from the feeder (on the right) into the mechanism to be pressed up against the push rods, and simultaneously takes the card that was in the mechanism, and ejects it out the front. The green linkage is a dwell mechanism. It remains stationary for most of the cycle, then raises the press when the card is in position, and lowers it back onto the feed rails for ejection. The purple linkage is just raising and lowering the plate at the bottom of the push rods in a roughly sinusoidal motion, to tamp them back down between presses. Everything's driven from the same crankshaft, so there's no annoying timing adjustments required. The press mechanism looks like this: It's a straightforward rack and pinion (I wanted a design with no gears at all, but this seemed the simplest solution). I'm really including this picture because it uses my favourite technic element that isn't: The One Ring. Four of them, in fact. I'll update later with some more video.

It's a lot more reliable than I expected it to be, but could still do with improvement. "Everything" took two takes because of a stuck pixel. I do need to do a proper writeup of it. I came up with a very satisfying pixel mechanism, and it sort of snowballed.