Phoxtane

The new sensors arrived about a week ago, but I've only just now gotten around to getting a comparison of them. Interestingly enough, the new sensor has all of its labels in English, whereas the old sensor had the labels for its LEDs in Chinese. In addition, the silkscreen labels for the new sensor are no longer underneath the right-angle headers, making it much easier to figure out which pin is which once the cable is attached. The position of the pins is reversed compared to the old one as well, but that shouldn't be a problem - just swap the leads around and it should be a drop-in replacement for the old style sensor. The LDR on the new module should be much better at detecting the ambient light level, whereas the old module is very directional. Thinking about it now, the old module could be used as a sort of light gate - maybe I'll set up something on a straight section of track that can measure the train's speed through that section? That'd be fun! The next step here is to integrate it into the landscaping on my layout, and test it in its actual working environment. I'm also assuming that the behavior of this sensor is more or less exactly the same as the older one, given that they appear to use the same comparator IC, but I really should test it to find out first.

I'm taking the knowledge I learned from a class last semester and applying it to my long-term layout. The devices pictured here form the basis of a block-occupancy detector system that will be placed within my long-term layout to facilitate some autonomous functions, such as signals, automatic level crossings, and remote switching. To start with, let's have a quick look at the FPGA development board I'm using for the controller. This is the Basys 3 Artix-7 FPGA Trainer board, sold by Digilent. The Artix-7 FPGA chip used here has 33,280 logic cells divided into 5200 slices (each slice containing four 6-input LUTs and eight flip-flops). It runs off of a 5V power supply, delivered either through USB or an external power jack. There are four 2x6 'PMOD' connectors (standard spacing, thankfully), one of which also acts as an analog input. There is also a VGA connector and a full-size USB as well. In addition, there are 16 switches and five pushbuttons available, as well as 16 LEDs that can be accessed by the user. It uses the Xilinx Vivado Design Suite for programming. Next, we have the sensor I'm currently using. ...Or at the very least, something very similar to it. It's one of those fairly generic designs that's copied by everybody and sold for very little, so it doesn't really matter which one you get so long as it looks the same. This, however, is not the final sensor I'll be using - this design is extremely directional, in that it's only sensitive enough for my application when the light source is in front of the module. It turns out that the version which has a photoresistor as its light-sensitive element is much better at detecting the ambient light level, and is actually somewhat cheaper. These type of sensors will run happily on anything from 3.3-5V, and have two outputs: an analog output, which will vary its voltage from 0V up to the voltage of the supply, and a digital output, which operates in the reverse of what you'd typically expect - that is, it outputs a high signal (high being the voltage of the supply) when the light level is below the trigger point set by the potentiometer, and outputs a low signal whenever the light level is above the trigger point. There is one power LED and an LED that reflects the opposite state of the digital output. In my first picture, I have attached the VCC pin of the sensor to one of the VCC connections on the Basys 3 - pins 6 and 12 on the PMOD connectors act as 3.3V supplies, with pins 5 and 11 acting as a ground, and pins 1-4 and 7-10 acting as signal lines - and the GND pin on the sensor to one of the ground connections on the Basys 3. The digital output (DO) on the sensor is connected to one of the signal lines on that same PMOD connector, and the analog output (AO) is left unattached (if I connect AO to a ground connection, the sensor acts as if a bright light is in front of it no matter what). Next, we have to write the code that defines the behavior of the controller! FPGAs are interesting because rather than a microcontroller executing commands, the code written actually tells the FPGA to re-wire itself internally to produce hardware-only logic that provides the desired behavior (this is where the name Field-Programmable Gate Array comes from). As such, the code isn't written in C or Java, but in Verilog and other Hardware-Descriptive Languages (HDLs). The code files can be treated as individual 'blocks' of logic, and can easily be combined together to produce much more complex behaviors than we see here. This is the only Verilog module that runs the system currently: module bodsensortest(led,bodsensor); output led; // Goes to some LED on the Basys 3 input bodsensor; // Comes from AO on the sensor board assign led=!bodsensor; // Oddly enough the AO output is an inverse output - it goes LOW when the light level is above the trigger point endmodule Here I'm defining a module called 'bodsensortest', with the output 'led' and the input 'bodsensor'. Then I tell the Basys 3 to set the output 'led' to the opposite state of 'bodsensor'. In addition to building the actual logic, it's advised to write a testbench module that hooks up to your first module and allows you to simulate it before sending the code off to the board: `timescale 1ns/100ps module tb_bodsensortest; reg tbodsensor; wire tled; bodsensortest dut(tled,tbodsensor); initial begin $dumpfile("tb_bodsensortest.vcd"); $dumpvars(0,tb_bodsensortest); tbodsensor=0; #40 // Default should be sensor 'uncovered' tbodsensor=1; #40 // Sensor now 'covered' #20 $finish; // total sim time: 100ns end endmodule Here I define the units of time that I'm simulating in, the module, and inputs (reg) and outputs (wire) for the testbench file. Then I tell the system to create a .vcd (timing diagram) file, and in that file examine ALL variables within the testbench file. Then I toggle the state of tbodsensor off and on to simulate something passing over the sensor, with some delays. Finally, I add in a 20ns delay to round it to a nice number. Lastly, in order to actually make this work on the board, I have to play with a constraints file that tells the board what I/O pins to look at and what variables they correspond to: ## This file is a general .xdc for the Basys3 rev B board ## To use it in a project: ## - uncomment the lines corresponding to used pins ## - rename the used ports (in each line, after get_ports) according to the top level signal names in the project ## LEDs set_property PACKAGE_PIN U16 [get_ports {led}] set_property IOSTANDARD LVCMOS33 [get_ports {led}] ##Pmod Header JA ##Sch name = JA10 set_property PACKAGE_PIN G3 [get_ports {bodsensor}] set_property IOSTANDARD LVCMOS33 [get_ports {bodsensor}] Here I'm telling the Basys 3 that one of the LEDs on the board is the output from the first module, and the input for that module comes from one of the PMOD connections. After this, I plug these files into the Vivado software, and generate a file that's sent to the board. Because FPGAs are volatile, I also told the software to generate a configuration file that's saved in flash memory on the Basys 3 so it can automatically re-configure itself every time I turn it back on, rather than having to reprogram it with a USB. Otherwise, I would only be able to run this program until the Basys 3 was turned off! All of this makes a little LED on the board turn on and off Also, I've actually got the function backwards - I want the module to follow the backwards behavior of the sensor, as I want there to be a signal whenever a train is passing over the sensor (it makes more logical sense to me that way). However, so far I'm quite pleased with what I've accomplished as we didn't really do much with outside inputs during the class - we stuck mainly to the switches and buttons provided!

Oh, hey, I might actually be able to put my high school German classes to use!

They never really worked properly for me; they either hurt my finger or got stuck halfway out whenever I tried to use them properly. Apparently the best way to use them is to not flick them with the tip of your finger, but to push on them quickly from the end instead. Still don't work properly though.

Bad things - but since it's the only choice out of four different positions for the switches that doesn't work, I imagine that avoiding that particular setting would become second nature quickly.

I think this is the best response to a model I've posted in a while! I get about twice the capacity in mAh (according to the datasheets) out of AA batteries as opposed to AAA, and I have quite a few more of them than I do AAA battery boxes. In addition, I can use rechargeable AA batteries which ends up being much cheaper than the Lego rechargeable battery box. Very much so. I still haven't managed to pack in nearly as many details as yours though. I haven't been able to test that yet, but power is provided by two PF train motors. The model itself weighs about 2.2 pounds (a tiny bit under one kilogram), so my guess is that it'd happily pull a full Horizon Express (or something equivalent in terms of weight and rolling resistance) without too many complaints. Based on the above, I did some quick calculations - If each AA battery I use has a (minimum) capacity of 1900mAh, and each PF train motor consumes 380mA at 9V under load (sourced from Philo's website), then under load this locomotive will pull 760mA. Since batteries in series increases the voltage, but not the capacity, I have 1900mAh available at the 9V that PF equipment uses - which means I should get about 2.5 hours of running time on this locomotive before I have to charge up the battery pack again. Of course, the stall current would be higher, but I have a V2 PF receiver installed that should prevent it from tripping out, and is a bit more efficient as well.

I just want other modelling programs to have the collision and snap-to connection features, as well as the overall polish that LDD has compared to its third-party competitors. The ease of use is what allows me to quickly throw something together to see if I like the shape, as opposed to doing so in LDraw (which looks like it came out of the 90s still!).

Is anyone going to have a go at reverse-engineering his six-axis robot arm? I can't see it being much use in a GBC module, but I desperately want a 6-axis robot arm to play with. There don't seem to be any cheap kits (that are reliable, and actually come with controllers and software), and everything tends to be expensive! Apart from the mechanics the hard part would be the inverse kinematics software to run on the EV3s to get the smooth motion that this robot arm can manage.

I've successfully completed my first 7-wide locomotive! Power is provided by two PF train motors, which are attached to the frame via Technic plates. The first version of this design was used at my LUG's display this year, but I changed up the internals quite dramatically based on performance issues; namely, it was very slow and couldn't keep up with standard 9v trains, and kept jumping off the track at the curves. The overall looks were improved drastically as well, in my opinion. I'm quite pleased with how this turned out, and I hope to build more locomotives in this style in the future!

No it's not. As for the green plates, I'm using 4x4 green plates. However, I'm forbidding you from buying any until my project is done, just so there's enough.

Disaster strikes! I built a test piece in order to compare various water effects against each other as well. At this point I'm leaning towards dark tan as the shoreline color, but can't decide between the blue or black as the deep water color. Any thoughts or preferences? I added a small trackside equipment box for something different. I'm not sure if I'll stick with the double-wide ties, because those examples look so nice, but this method is a lot more hassle-free; I don't need to put anything except tiles under the curves, and I don't need to use a dark gray ballast color in order to hide the two-wide Lego track ties under single-width ties. It's also a bit cheaper due to less pieces used. I'll have to put more curves down before I commit to one or the other. The only downside is that this method takes up a lot of 2x2 bricks, but given how common they are I can't imagine anything but the more exotic colors amounting to any real cost in quantity. As for the outside border... ...I went ahead and changed my border to black as well. Surprisingly, I appear to be running out of black bricks in the 1xN sizes that I need to continue this! I've also blurred out part of this picture due to not wanting to reveal another project before I'm ready to get nice pictures, and because I'm too lazy to move it out of frame. Consider this a teaser. My next steps are to wait (im)patiently for my order of ten baseplates from Lego to arrive, as well as rummage through my 1xN brick drawers and extract as many 1x4 Technic bricks as I can find so that I can integrate the new baseplates as soon as possible.

The last of the 4x4 green plates from the second order of this lot arrived today. I filled in some of the remaining empty space, and the day before I completed the hill in the corner. The benefit to raising each module up by a brick means I can add in depressions as well as hills, but I want to add some more baseplates and figure out where the rest of the track is in relation to this corner before I lay down any more landscaping. I've placed some plants as well. I also ordered a hundred trans-dark blue tiles in order to play with water effects for a section that's further down on a part of the layout that hasn't been built yet!

I need to add plates for a more natural slope, but here's an in-progress shot.

Work continues, especially now that I'm on my winter break. At this point I've run out of baseplates, so I'm considering whether or not to pull the trigger on an order of ten from Lego (unless anyone feels the need to get rid of some?). I'm also waiting on some Bricklink orders to arrive, which are taking FAR longer then they should have, as the highways were closed for a couple days due to excessive snow. I've also expanded my building space by commandeering the second folding table, and I now have room for multiple projects at once, one of which is parting out my Horizon Express sets into my general parts collection after three years in service! I've used up all of my red 2x2 bricks and have moved on to my second-most numerous color of that part, yellow; you can see exactly where I ran out of red and switched over. I also realized that I have quite a few yellow 1x4 Technic bricks which I could be using at the joints on each module, so once I run out of the gray ones that came in this Bricklink order I'll use those up next. I'm also considering adding a small slope in the corner next to the curve, on the outside edge, in order to give myself something to do while parts arrive and add some visual interest to a rather empty layout.

Another piece with the part number seemingly missing:

I'm taking a page from UrbanErwin's book and building my own large, detailed layout, based upon my 'Perfect Loop' track design and the MILS standard discussed by Hispabrick Magazine. Each 32x32 baseplate contains 1x4 Technic bricks at the corners as well as a lime green 2x2 brick (the 'identifier' as discussed in the MILS standard), with the aim being that each baseplate can be separated from the rest without too much hassle. This provides the flexibility to move the layout around as needed as construction progresses, or if I decide to take it to displays. It turns out it's actually cheaper by a fair amount for me to buy 64 green 4x4 plates instead of four 16x16 plates, 16 8x8 plates, or even 128 2x4 plates - as such, the supporting structure in each module consists of a grid of 2x2 bricks in the most abundant color I have, with 1x2 bricks on the edges to maintain the spacing without crossing over into another module. While I can avoid using these plates underneath the straight sections, I can't really avoid that for the curves, as the tiles need to attach to something, so I've only plated over the sections that I absolutely need to for now. Here's a demonstration of how the modules split apart. Since this photo was taken, I've moved over two having two Technic pins for each connection (for a total of four pins between any two module edges) and it's helped them stay together much better. The straight track is actually stuck down to the modules, unlike the curved track. I assume that it's one of the features of the setup that won't change too often, so hopefully it won't be a pain to deal with. Overall, the entire setup is projected to be 6 baseplates wide by 11 baseplates long - however, due to the shape of the track, I won't be filling in the whole rectangle; overall I need 49 baseplates for this project, of which I have seven. This is about 5 feet (1.5 meters) by 9.2 feet (2.8 meters), so it's going to take a while! The other big advantage to building in this manner is that I have the freedom to create depressions in the landscape as well as holes, without having to fill up the the entire module with bricks. In addition, the empty space below means that I can potentially run wires underneath everything - if I wanted a 9V loop in the future, the power drops would pop up right where I want them.

From The Oatmeal. I felt it was relevant. I dunno, maybe put at the beginning of each video from now on a flashing red screen with air horns going off at the background, and text saying "No, this MOC is not for sale, especially not to you", with the angriest voiceover in Polish that you can manage? What I'm more confused about is the logic (of which there is none, but whatever) behind the statement that you're not giving back to the Lego community? Because you're not selling builds or instructions or t-shirts or condoms with your logo on them, just some books on building techniques?

I finally decided that I had enough track to try and set something nice up for myself, so after a bit of LDD work and the assistance of this webpage, I came up with this: I knew what I wanted was something that felt big, that had long straights, and track that wasn't just going at perpendicular angles to itself. The best part is, this track all lines well enough that LDD only has a small fraction of a stud of offset from the two 'ends' where the track connects back to itself - which is close enough that LDD let me place the track pieces intersecting each other with no issues. As an added bonus, there's lots of land space included in the right-hand loop, so it can house fields, houses, churches, more houses, warehouses, housing supply stores, etc.. This layout only really works because of some special numbers - seriously, read this page if you haven't already, because it's super useful: http://www.brickpile...ayout-geometry/ It's worth noting that the baseplates he shows in his examples are 48x48, but that won't really matter much if you're using 32x32 unless you insist on your track always being exactly four studs away from the baseplate edge. Starting from the left and working around in a vaguely clockwise fashion: The light blue segment is six straight pieces, the purple segment is the standard four curves for a 90-degree turn, the top green segment is 14 straight pieces, the orange segment is another 90-degree turn, the pink segment is one straight piece, the dark green segment is FIVE curve pieces, the red segment is 12 straight pieces, the minty-green segment is eight curve pieces, the pinkish-purple segment is one straight piece, the blue segment is another eight curve pieces, and the orange-yellow segment is three more curve pieces. In total, to build this, you'll need: - 34 straight tracks - 32 curved tracks For organizational purposes: keep two straight pieces separate, and connect the rest into a six-long segment, a 14-long segment, and a 12-long segment. Then you'll want to build three 90-degree curves, and two 180-degree curves. With the four remaining curves, attach one curve to one of the 90-degree curves, and connect the rest into a three-long segment and connect that to one of the 180-degree curves. Connect as shown to build this layout. I believe it's possible to extend the loop by adding pieces in certain strategic locations, but I haven't got the space to do so - however, good places to do so would be adding track into the middle of the light blue segment and into the 'middle' of the minty green curve (where it comes closest to the light blue segment), at both ends of the dark blue curve (extending how far out the curve reaches), or at the end of the orange segment and the corresponding parallel section of the dark green curve. Adding pieces into the middle of the orange segment and the red segment will throw off the alignment, according to the webpage I've linked twice so far (if you do this, add track segments in multiples of 12 only!). Anyway, this is my perfect loop.

I'd imagine that the Education branch of Lego has a slower turnover than the standard consumer-facing main branch, so probably not for a while. Also, it's worth pointing out that the pack from Lego Education is $35 for a large gray plate and three (two green, one blue) 32x32 plates, whereas getting those from Lego SAH individually would run ~$39 (1*14.99+3*7.99) - so there IS a small cost savings! I'd be looking at this myself except I want exclusively 32x32 plates (for me, the color doesn't really matter), so the Education pack includes a plate that I wouldn't be using much, if at all. Sadly, Lego themselves are the cheapest source of baseplates in quantity, after I've relieve my non-LUG friends of theirs. 42 baseplates isn't going to be cheap no matter which way I slice it.

I'm sure that'd go over well with about nobody - if anything, they likely wouldn't be selling it as LDD 5.0, but under a different name. I can't imagine that they'd be selling the 5.0 update, but rather a new piece of software, which WOULD explain the lack of updates on LDD. Meanwhile:

I can't seem to find part numbers molded on to these parts - the top part is dark red, the one in the lower left is light gray, and the two on the right are both dark gray.

It was the grouping thing - I was grouping them under Bricks, not Model!

I'm having issues with the template; for whatever reason, I can't run the script that applies the shaders to the model, and the colors are all weird because of it. I can't seem to figure out how to NOT make this happen, as it was working fine yesterday. It says to check the console when the python script fails, but I'm not seeing a console anywhere...

Well, I've just completed my first Blender render - any word on when edge bevels will be built into the materials/shader pack to render the Collada files with? I already want them to be just a tad better...

The trick is to not step on them in the first place - I've gotten really good at avoiding pieces on the floor over the years. I usually leave a few spots clear on the floor so I have places to step anyway.