Several years ago I tinkered around with making mechanic logic gates, so the LEGO Answers question: Is it possible to build simple logic gates with LEGO mechanics? caught my interest.
Keshav Saharia blog post Mechanical computation from Lego bricks was interesting, but I was not quite satisfied with his NOR gate. First of all the OR gate in it looks rather shabby in my opinion but most importantly it does not reset its state. It starts out in the TRUE position, but when an input becomes TRUE and the output becomes FALSE it will stay FALSE even it the input changes back to FALSE again. So I wanted to try making my own version based on Keshav´s design and the result is shown below:
(CAD file available, I just can’t upload it to WordPress and Brickshelf appears down at the moment.)
My version is a bit smaller as the frame is 6×8 instead of Keshav´s 6×10, but it does use a few more pieces. I’m not quite satisfied with my OR gate either as I’m not sure how much force it can transfer before becoming unreliable.
A rubber band have been added so the gate properly resets itself however it does create a new problem, more force is needed to go through the input in order to operate the gate. This is not a problem with just one gate, but imagine 10 of these stacked together and this force will become rather large.
So I believe that the axle approach will always be limited with that, because while most gates pushes, insert a NOT gate and it will start pulling which could pull the axle out of what might be connecting it.
I tried making an AND gate where the NOT gates are combined with the NOR gate (in order to make it smaller) but I didn’t succeed in making up a good design for the combined double NOT and OR gate. But inspiration have struck me and I have an idea how to make a XOR gate which will end up being about 6×12 and about 5-6 stud high. This will be my next goal.
I haven’t posted anything for a while since I’m currently busy with finishing my exams projects. So I brought up a little thing from the past. Quite a few years actually (so I’m sorry about the dust ;) ).
Back in the days I loved the platform game “Toy Story 2: Buzz Lightyear to the Rescue” (from 1999). In the third level (video here) there is this toy plane which I happened to like even though I hated the level of some reason. So I made a small scale model in normal Lego:
LDraw file (with steps) is available from my Brickshelf account. (direct link)
I haven’t really made a lot of small scale models (and therefore certainly don’t have any skills with it yet) however this is the only type of Lego other than Technics/Mindstorms that still interests me today. For example this model of Suiseiseki from Rozen Maiden is just fascinating. (Well, perhaps I just don’t want to admit that I don’t have enough Lego…)
I just recently got my hands got my hands on a SLR camera however since I’m quite new to this I didn’t manage to get the depth of field correctly. Well, I will figure it out someday… EDIT: someday was apparently the day after that as I found out how to change the setting by accident…
As I’m planning on writing a LDraw parser and viewer I read the LDraw.org File Format Version 1.0.0. However I find it rather vague so I’m sharing my comments on it.
“All LDraw files are plain text based. A specific character set encoding (UTF-8, ISO-LATIN1, US-ASCII7, etc) is not defined and software authors are free to use whatever encoding is appropriate for their target platform(s).”
I really don’t think it is a good idea not to specify any restrains on the character encoding. Just imagine a parser expecting ISO-LATIN1 getting a file encoding in UTF-16… But a file encoded in UTF-8 with BOM can be enough to cause parsing errors. My suggestion would be to enforce ASCII (8-bit) compatible character encodings and recommend UTF-8 (without BOM) if ASCII isn’t sufficient. What about newlines? For better “cross-platform portability” it should be defined which ways of defining newlines are allowed (in order to make sure parsers support them). Because if the parser doesn’t detect the newlines properly, it can’t read the file at all…
The whitespace characters allowed for keyword and parameter separation include spaces and tabs.
Include? Does this mean that other whitespace characters are allowed?
When describing the format (for example “0 !<META command> <additional parameters>”) spaces are used for separating keywords/parameters. I guess this means one or more whitespace characters?
“0 // <comment>”, whitespace is required between “//” and the comment? (I guess I’m just not used to having whitespace there…) “<META command> is any string in all caps”, may there appear whitespace in the command? In an example in “Adding New META Commands” there is: “0 !LDPARSER EXAMPLE”, however I prefer that whitespace is not allowed as it makes separating the command from the parameters easier.
For the file parameter there are several directories included, in which order should these be checked (in case of identical filenames)?
Many of the original commands are described by how they affect the original LDraw program and in my opinion this doesn’t belong in a spec for the file format. It should focus on the intended purpose instead of describing an implementation. The “LDraw.org Official Library Header Specification” seems to describe how to describe a file with meta-commands in order to include it in the official library, it doesn’t really specify the commands. Yet this document is the only documentation for several commands… On a side note, “0 Name: Filename.dat” and “0 Author: RealName [UserName]” are both not written in uppercase entirely and include a ‘:’ before the whitespace though this isn’t included in “List of Official META Commands”? According to the spec it can surely not be a META command since it isn’t in uppercase, but the LDraw team apparently treats it like that anyway?