Phoxtane

Is it still fine to reply to this topic regarding Brickficiency 2.0? Or should we start another one?... I'm getting an error today from Brickficiency 2: Error loading settings... using defaults (System.InvalidOperationException: There is an error in XML document (0, 0). ---> System.Xml.XmlException: Root element is missing. at System.Xml.XmlTextReaderImpl.Throw(Exception e) at System.Xml.XmlTextReaderImpl.ParseDocumentContent() at System.Xml.XmlReader.MoveToContent() at Microsoft.Xml.Serialization.GeneratedAssembly.XmlSerializationReaderSettings.Read3_Settings() --- End of inner exception stack trace --- at System.Xml.Serialization.XmlSerializer.Deserialize(XmlReader xmlReader, String encodingStyle, XmlDeserializationEvents events) at System.Xml.Serialization.XmlSerializer.Deserialize(Stream stream) at Brickficiency.MainWindow.loadWorker_DoWork(Object sender, DoWorkEventArgs e) in D:\github\Brickficiency2\Brickficiency\Main.cs:line 328)Loading... From there, I can play with the various drop-down menus in the top, but I can't actually do anything (e.g., I can open 'Import' but I can't actually select a file to import as the options are grayed out).

I know my classmates use sewing machine oil for the bearings on their longboards. Don't know if it's any lighter or not.

Ah, if I had known the inner diameter I wouldn't have bothered - looks like the ones McMaster-Carr carries in the 5/64" ID are limited to 1/4" OD. The nice thing about the ebay bearings is that they are ZZ (double shielded) bearings, so in theory they'll be plenty resistant to any ABS dust or grit that will accumulate. Actually, another issue that may present itself is whether or not these bearings are lubricated. They may have more rolling resistance if they're lubricated, but they will last much longer because there isn't nearly as much metal-on-metal grinding action. If I had to guess, maybe the reason why some bearings roll more freely than others is because they weren't properly lubricated (or weren't at all to begin with). I'd be curious to see someone tear apart one to see whether or not these are lubed.

I'd be worried about the adhesion of the paint to the 3D printed plastic over time, as well as the tiny added thickness that a layer of paint gets you (messes with tolerances even more than 3D printing currently does). Be sure to update us in a few months as the parts are handled so we can see how well it holds up with pieces connected/disconnected to them! I like the idea of the dyeing method mentioned above, since that's putting the color INTO the material rather than ON it - and for my setup, it would mean that I could connect tiles and various other pieces to the track (and the track to other pieces) without getting paint ground onto the surfaces, or having parts stuck together because of the paint's thickness.

I had a quick look on McMaster-Carr, and found some ball bearings with a 4.8mm (3/16 in) OD: http://www.mcmaster....arings/=148m2ci They'll probably be more expensive than the ones you can get off ebay, but my guess is the quality will be a lot more consistent between each bearing as well as between each order. And, you can get them in all sorts of types: shielded, not shielded, greased, plastic, hex-shaft ID, and so on... According to the blurb at the top of the page, I would suggest going for double-shielded bearings if possible, since they are more resistant to various contaminants - and I imagine right around the tracks, especially at shows, is going to be particularly bad in terms of dust and grit. Apparently, ZZ stands for a double-shielded bearing, with a ZS indicating a removable shield (so a ZZS would be a double-shielded bearing with one of the shields removable).

Do you know what functions will change or be upgraded, what may be removed, and what may be added with this new forum software?

That design works really well - I just mocked it up with the parts I had lying about, and the pins with the bar through them have enough friction to keep the door in place on its own. I'll have to test their holding capacity later. By the way, if your friend isn't on Eurobricks, they should be; I would love to see more of their work!

I want to build up a set of hopper cars for use at my LUG's next display, and it just so happens that I have six of the 6x28 train bases in orange from my Horizon Express teardown. Even better, they have a couple of 2x2 holes in each to allow cables to pass through, which means I can potentially use them as working hopper cars! Here's what I have so far: Having tested this with a small hopper built out of random bricks and the 1x1 round transparent plates drawer in my collection, the pieces should flow out quite nicely. The problem is the mechanism that will keep these closed and then allow them to be opened again once the hoppers are to be unloaded. So far, I have a device that will keep the doors closed with one of the red Lego pulley bands: ...But that's not really the solution I'm looking for. I'd like something that will operate both doors at once, and lock in either the open or closed position. In addition, I'd also prefer that it operates with as little force as possible, and doesn't require the removal or insertion of any pins - I'd love something that can be pushed over an unloading pit and automatically dump as it passes over, then close up again where it can be taken to the loading station. Oh, and I'm limited to a 4x8x3ish space as well, due to the wheelsets. Shouldn't be too hard for someone with more experience than me, I think... Any ideas?

I'd suggest for hiding the wires to cut a slit down the length of a short piece of hard tubing, then pass the wires into the inside via the slit.

These ones are hidden quite well: http://www.eurobricks.com/forum/index.php?showtopic=49749 There's another one I've seen but haven't come across yet where there's a large linear actuator hidden in the lower frame of the locomotive, which does more or less the same thing. I'd go for this version though, because you already have a hard stop in place so that the wagons don't roll off the end of the dumper. All you'd have to do to your current setup is to get the spacing just right with the wagons and the hard stop so that the magnets align over the joint. I'm thinking that even if the axis of rotation isn't aligned with the magnets, they'd get pulled apart by the action of the dumper alone, and then automatically re-couple once the dumper is done with its cycle... whether or not this would work would depend on if the locomotive is heavy enough to not be pulled off the track when the magnets are pulled apart.

I highly doubt the Eagle 5 from Spaceballs will have any chance at being an Ideas set - it IS a Mel Brooks film after all. Which reminds me, I need to get my Ideas proposal for a Blazing Saddles set posted.

Thanks! I've always thought Brickficiency is the better program to use over Bricklink's new system, it's a lot more helpful when something goes wrong and it's much easier to use.

Apparently Brickficiency is now being maintained by another person as Brickficiency 2: https://github.com/WindmillHelix/Brickficiency2 Thing is, I can't seem to figure out how to get the program to run. The original Brickficiency folder I have has a .EXE file that I run to start the program, but I can't find one of those in this new Brickficiency.

An inverted corner modular doesn't make sense, given how the rest of the line makes up a city block. Given how well that seems to have worked out for them, I'd expect them to continue with the traditional full-facade buildings.

I've soldered up a board for testing purposes: It's not perfect, especially on the chip and the diode, but it's certainly workable. About the only thing I would change would be to use some through-hole diodes instead of the ones I have on hand, since the legs are so hard to access when soldering, especially when I have to hold it with tweezers. It'll mean yet another board respin, but the time saved soldering that component will be worth it.

It'll happily roll over the flex track, but they won't pass power. If you wanted to create separately powered blocks of track, that'd be one way to do it - but your train would have to have enough momentum to keep rolling over the flex track section. A better way would be to just slip some paper in between the track segments you want isolated.

The new version of the PCB for this project arrived in the mail just now! I've scanned in both sides of it, as well as a comparison to the old version, and the collectible sticker I got in this package: High-Res Image: http://bricksafe.com/files/Phoxtane/automatic-lego-train-control-with-fpga/EPSON002.jpg I actually have the next two days free, so I'll be working on making sure all of the traces and connections are electrically sound, as well as soldering it up. Here's another image that shows the scale of the components I'm working with... We have the .1 inch spaced pin header that the board connections use, the SOIC chip that makes the board work, the SOT-package diode that I'll be using for polarity protection, and finally the 0805-package capacitors and resistors. We also have a 1x1 round Lego plate to give a sense of scale. Tweezers are a must-have tool! I'll probably have to get some practice in with the 'learn to solder SMD' kit before I try them out on my shiny new boards; I don't want to have to wait another two weeks before I can try again!

I've seen it used for the approaches on ramps and bridges.

I'd also like to know where you're getting your Arduino Nanos for a few cents apiece. The cheapest I've found on Amazon is three dollars apiece, and that's only in packs of five, with a knockoff USB-to-serial converter that required some obscure driver magic, and I still had to burn a bootloader onto them... Not only do I save on I/O connections with these, I have to do exactly zero programming to them to make them work - they're peripheral devices for some sort of controller, essentially.

I'll be using Verilog, but as I understand it VHDL isn't too far removed. I'll be sticking with Verilog for the moment since it's what we covered last semester... not sure if we'll continue with that in the upcoming semester, or if we'll do a bit of both, or whatever. I can say, however, that the way Verilog was taught to me makes much more sense than when I tried to learn some other languages.

Not only is this a learning project, but even with my FPGA controller the number of I/O connections I have available is limited. This helps me get the most out of whatever controller I go with. I've also really enjoyed working with Verilog in my class last semester, so the FPGA is a good choice for me! EDIT: Forgot to mention the scale of the project - it's likely I'll end up with ten, or twenty signals across my layout when completed. Even if the signals are synchronized to each other (for a single track main line), that's still twenty I/O pins used for signals alone - and I'd still have to connect the various sensors as well. Without this device, the number of pins needed to drive all of those signals would triple!

I came home from work yesterday to discover that the first version of the PCBs for this project had arrived! Looks like there's still some tabs from the panelization process that the PCBs go through. I'll have to remove those with a set of pliers, and maybe do some file work in order to smooth down the edges. Here's a scale shot with the DIP-16 version of the chip I used for prototyping, its SOIC-16 packaged counterpart that will be used on the board, a 1x1 round stud, and the board itself. This board version is 24mm by 32mm, or exactly 3x4 studs; the final version is a nice square 4x4 studs. There's just one problem, however... I can't actually use these boards for testing purposes, as when I assigned footprints to each component in KiCad, I assigned the wide version of the SOIC-16 (~8mm) footprint as opposed to the normal SOIC-16 (~4mm) footprint. As such, it's far too wide for me to actually solder the chips I have on hand to, and I'm not about to attempt bodge wires with the stuff I have on hand... I also did a high-resolution scan of the PCBs on our scanner, just so I could inspect them properly. I'll link in the high-resolution image, as well as embed a forum-friendly preview. http://bricksafe.com/pages/Phoxtane/automatic-lego-train-control-with-fpga As you can see, there's not much in the way of labels - if I didn't have the schematic on hand, I'd have a very difficult time figuring out what wire connects to what pin. Thankfully, board version 2 solves these problems, and board version 2.1 improves upon board version 2. Correcting the footprint issue freed up some space for better label placement, and I made use of the empty back side of the board to add some design information and a graphic. I'll update the first post with these images as well. I've also made the decision to run this board off of 5V exclusively; it's the most common voltage that any entry-level Arduino or other sensor runs off of. So far, the only 3.3V logic device in my system is the FPGA master controller, and I can just use some logic level shifters for the signals running in and out of it. I haven't done the cost calculations yet, but I suspect the board will actually remain at around the same price as before, even with its larger size, since now it only uses one value of resistor throughout the design due to increasing the supply voltage.

Power functions to power the bus, and I believe a train magnet on the steering followed a wire taped to the underside of the baseplates.

I've clipped some of your reply here so that it's not excessive. I think I may have done a poor job of explaining, unfortunately. However, Signal A and Signal B can operate entirely independently of each other! Signal A is tied into one of the IC's decoder units, whereas Signal B is tied into the second decoder unit. In this way, assuming that 'A1' means 'the first light in Signal A' and so on, you can have both signals displaying different colors; Signal A could be red, whereas Signal B would be green, and so on. While it's not actually possible to have two lights on the same signal lit at the same time, it's still possible to make it look like that's the case. All you have to do is tell your controller to switch between the two lights, but very quickly. While both lights will never actually be on at the same time, to the human eye it'll look like they are. Here's a really great example video of the process: It's called 'multiplexing' and it's a very common trick used, especially with the type of display shown above. Technically, you can only have one of the four characters turned on at a time, but the microcontroller steps through displaying each one quickly enough that the eye (or in this case, camera sensor) doesn't notice it. You can see a bit of a flicker sometimes if you're moving around the device in question, but I don't think that will be much of a problem since you'll only be stepping between two devices (maybe three at a maximum). Also, while it's not present in the 3D model generated by my PCB software, there is a polarity protection diode present on the board; that should keep the board from blowing up if you plug it in backwards. Otherwise, all of the magic blue smoke that makes it work would be let out, and that's no good. It's very difficult to put that back in once it's been let out (impossible, really).

As part of my quest to control my Lego train layout with an FPGA controller, I decided that I would want some railway signals that would change as the train passed by. I then realized how much of a mess that would be with wires running to and from each LED in the signal and the control board, so I thought to myself: "I wonder if there's something I can build that will help with this problem?" I'm curious to see if there's enough interest in this gadget for me to be able to make and sell them, so that's the main point of this post. Here's the result: EDIT 8-2-2016: Board version 2.1 images In addition, here's a video of one of the first versions of the circuit, before I had even started on designing a PCB. This demonstrates the basic functionality of the controller with a single three-aspect 'signal'. Description: This board can drive up to two three-aspect (light) LED train signals with as few as two I/O pins on the chosen microcontroller. It can be run off of either 3.3V or 5V supplies* a 5V, and will interface with logic signals of the same voltage. If you'd like to drive the two signals independently, it will take four I/O pins. Dimensions: 4 studs by 4 studs, not including the male header pins. As I have yet to receive the prototype for this board, I don't know if the mounting holes fit a typical Lego stud, or if they line up with the corner studs on a 4x4 space - however, I should be able to adjust this without too many problems. The header pins are the standard 2.54 mm/.1 inch pitch popularized by Arduino microcontrollers. Technical Specifications: Supply voltage should either be 3.3V or 5V* be 5V. Absolute maximum current draw should be ~85-90mA, typically ~41mA**. Operation: The IC used to make this board work is the SN74HC139DR, a two-line to four-line decoder. There are two decoder units in each chip, and as a result this board will happily drive two signals at a time, either independently or synchronized together. The A0 and B0 connectors are the least significant bit of the two-bit signal, with A1 and B1 being the most significant bit. There is also an active-low 'Enable' pin for each decoder, which is not broken out to a header; it is permanently tied to ground so that the board is always ready to change the signal. If the value sent to Signal A is 00 (A1=0 and A0=0), all of the LEDs in the signal remain off. If the value sent to Signal A is 01 (A1=0 and A0=1), the green LED will turn on and remain on as long as the 01 signal is applied. If the value sent to Signal A is 10 (A1=1 and A0=0), the yellow LED will turn on (and remain on as above). If the value sent to Signal A is 11 (A1=1 and A0=1), the red LED will turn on (and remain on as above). Signal B works in the same manner. If you want to set both signals to the same light, simply tie A0 and B0 together, as well as A1 and B1 together. If you want to drive the signals independently, don't do that Cost: My calculations for the cost of the components, the PCB, and the time it takes for me to assemble and test each board tells me I should be selling these for $21.99 (USD) apiece. If I was to have these mass-produced, it'd likely be cheaper - however, I'd have to be buying them in quantities of 100, or 1000, and there's no guarantee I could sell them all. As such, I would prefer to take orders from anyone who's interested in buying these and essentially produce them on-demand so I don't have to keep inventory around. Sales Pitch: You should buy this device because it reduces the amount of I/O pins required to drive two three-aspect signals by 33% (four pins instead of six for independent operation) or even 66% (two pins instead of six for synchronized operation). This reduces the amount of programming work that has to be done by the user. In addition, the board is thin enough that it can fit in a single brick's height; as such, it can easily be hidden under some landscaping or even placed under the ballast for a section of track! Moreover, it comes in a lovely purple color with a gold plated finish, thanks to the company who I get my PCBs from. <~~~~~~~~~> *The only change that this would require would be different values for the resistors; I currently have resistors on hand for a 3.3V version, as that is what my FPGA operates at. Typically, Arduinos operate at 5V, so I could potentially offer either variant to suit your needs 5V supply only! More will burn out LEDs and resistors, less will cause undervoltage problems. **The LEDs I prototyped with (and will use on my layout) have a maximum current draw of 20mA apiece, with the IC drawing ~1uA. If there's a problem with floating inputs, it is possible for two LEDs on each signal to be lit at a time, resulting in double the current draw. I have yet to see all three LEDs on at the same time! Now, having read all of this above: Would you buy this gadget? If so, how many do you think would buy, and how much would you be willing to pay for each one? As sad as it is to admit, I'm not able to compete on cost with cheap PCB assemblers in China. Another question: Would you want mounting holes on the board, similar to what I've show here? If so, would you want them to fit a Lego stud? Finally, just to make this clear: I'm not ready to sell these yet. I still have to receive and assemble my prototype, which isn't even the board pictured above (it is functionally identical, just without the helpful pin labels and slightly cheaper because it's a tad smaller). I'd be thrilled to be able to sell these to people once I've verified that it works and doesn't explode, however!