Toastie

Wow! This is another and very comprehensive solution to train layout automation! Congratulations, this is very nice work. Must have taken some time to get all this going, particularly the software! Now you are mentioning that the product is not "commercially" available, but on your webpage listing of all the items one would need to get this going, the links point to the same shop. So with "product" you mean the entire suite of elements along with the software, you developed, right? And what product exactly is licensed? The hardware I guess not, as most of the items are also available elsewhere, right? Is it the software? Or the entire approach? Or do I miss something? Anyway: Beautiful and very impressive work! Best regards, Thorsten

I have never used LDD - I am having serious issues with all LEGO building tools not letting me get a brick where I want it - where it actually IS in my LEGO model. You know what? When it works in real life, I would not care the slightest bit whether or not a program tells you is it not OK. There were days when LEGO was around for decades, but programs apparently looking at illegal/legitimate connections weren't even invented. In those days, models were models you created. And that was perfectly fine. When LEGO models fall apart due to some paper thin gaps: Use pressure. ABS plastic is designed to do exactly that: Connect even better! No program or machine knows about that. Real life is what really counts. And this is why I am using MLCad/LDraw: Just put the pieces where you want. The hinges will never crack over time due to paper thin gaps. What will happen is that they stretch a tiny bit to adjust to your imagination. This is not esoteric wording - it is from a purely "chemistry of ABS" point of view. Just let your ideas roll and see whether or not the bricks like it. They'll for sure let you know. BTW: Your models and ideas are awesome!!! All the best, Thorsten

Hi kr1minal, oh my, hopefully they don't tell you not to bump old topics ... I'll put the instructions into my university cloud, give me a minute, need to find that stuff ... will edit this message with the links. OK, here you go - found them on my old WinXP Laptop - I knew that one is still of value: https://uni-wuppertal.sciebo.de/index.php/s/hwpJrxylYQggVKB Navigate to the "5 BR 23 Ben Beneke" folder. A couple of notes: LDraw files: The LDraw MPD files are with and without LSynth generated electrical wiring. Olaf Müller made the latter for me. When you open the files with MLCad, it will ask you whether or not you want to upgrade part to newer versions. Don't do that, just use as is, otherwise the model may get corrupted. You need to have the official, and unofficial files installed, including the BBB wheels. PDFs: There is a higher quality file of some tens MByte size as well as a rather small lower quality file. In these days (man, it is 7 years ago ...) there some (minor I remember) issues with the instructions. The instructions were made by hand in PowerPoint using PovRay renders of the individual steps. It is sure possible that there are some slight glitches. Let me know if this does not work for you. Best, Thorsten

Hey, nothing is wrong! And I did not want to be rude (!), I guess this is because I am sometimes teaching electrochemistry classes and alkaline vs NiMH chemistry is usually on the final exam. Both images are perfectly fine - with appropriate information, they entirely make sense and are reliable. Just look at this data sheet this data sheet provided by Duracell. You can find your original image (high constant current) as well as the one you updated (lower constant current). It just depends on how you would plot the data. And this is what people sometimes simply overlook. Or some people accidentally plot ... All is good. And you are right: The chemistry in NiMH does allow to draw higher sustained currents without significant voltage drop, provided current and cell capacity match. And yes, you are right: It appears as if the folks at Eneloop do very carefully design their products. Quality should always win, but then there is marketing. Best regards, Thorsten

OK, I guess we need to get this a little more into the clear. The discharge curve of the "eneloop" vs "alkaline" batteries as shown above is simply not true - with regard to the Alkalien curve. You can google "alkaline discharge curve" and you will see a rather flat profile for all alkalines - it is in their (chemistry) nature. Of course it depends on model and make and most importantly on their nominal capacity. There are so many different manufacturers. Some are reliable, some are not. The same holds true for NiMH cells. It does nor get any flatter on the sustained current drawing curve - provided you adapt your power draw to the cell capacity (or the other way around). Drawing current into 8 motors with poorly matched overall cell capacity will just - cause pain. I am using some China 2200 mAh NiMH cells - and believe me, they are doing very well. I guess I was lucky ... All the best Thorsten

They would work perfectly well - in fact the >cells< in the LEGO rechargeable LiPo box are less powerful. BUT: The thing is to charge them "intelligently". And this is very important - otherwise you may destroy the cell pack easily. The charging electronics is somewhat fancy. You can get that for relatively small money as well. But then you need to build your charging "infrastructure". To be quite honest: The LEGO LiPo is really expensive. But it is a beautiful piece of engineering. I have tested that thing extensively and simply could not break it; here are some of the results If I were you, I'd save some money, go on BrickLink and get the LEGO rechargeable battery for a decent amount of money. Did that a couple of weeks ago ... Best Thorsten

... and even nicer, when people do you proper grammar ... "LGEO library extensions" was meat of course ... sorry.

That is exactly what this is about ... trains run on tracks ... on tracks that are carefully aligned to "let" the mighty trains do what they have to do. This is about the alignment ... and folks who accomplish that. Thanks, Zephyr! All the best, Thorsten

Emanuele ... breathtaking. The V200 was, is, and will always be my favorite German Diesel engine. There is nothing that comes close. The colors, the shape ... ... and your LEGO rendition. Perfect. Beautiful. I need one ... seriously thought I have enough engines ... but no. With this one I will but not without. You are a true master builder! All the best, Thorsten

You know, I feel so much better now - I entirely (every word that is) agree with Blakbird's comment. And for years I thought MLCad/LDraw is my absolute favorite because: I am old. And simply not smart enough to figure out how the "new" modeling tools work. I tried them all ... just to get completely lost because a part does not stay where >I< want it to be ... but that is the core of the matter I guess. Now with regard to rendering: There is export from LDView, from Stud.io, from LDCad (...) to PovRay. And then PovRay needs to be tuned of course. Then there is Blender with the "read LDraw files" add-on - I don't see why LDraw and rendering don't work - particularly when installing Darat's LEGO library extensions ... Thanks a lot and best regards, Thorsten

Thank you very much, JopieK! I really appreciate your judgement, knowing that you do so many really cool and advanced things in class as well as professionally! Video should be online (I am always a bit fuzzy on YouTube; but since it shows in the post, I believe it is there). Quality is a bit crappy. Best Thorsten

Dear All, there are numerous contributions on electrifying LEGO train switches, including those here on EB. All-LEGO solutions, all-custom solutions and “everything in between” has been presented. One issue for my layout was: How to control about 30 electrified switch points on a fairly large and rather congested layout with many areas not readily accessible – in a purist solution? Using individual cables going from one single “control center” to the switches would result in some considerable cable mess. Alternatively, PF receivers may serve as remote controllers on “PF layouts” – manipulated via IR light from the center. That is a very elegant solution, however, there are only 4 x 2 IR channels (or 8 x 2 in extended mode with a mandatory custom remote control program), which is not enough on my layout, particularly when running several PF controlled trains eating up channels as well. One approach is a fully LEGO based solution using LEGO programmable bricks (PBricks). With such PBricks one can use a variety of motors on the drives and also some fairly flimsy switch drives because of power and timing control of the drive train. Furthermore, with some software development (e.g., NQC, RobotC, NXC, NXT-G …) the controllers may get their own “address” and operation software. However: Cost may become an issue: You need 1 NXT or 1 RCX for each set of 3 switch drives, or 1 Scout for each pair of 2 drives (in case the drive is operated with one additional MicroScout, the Scout can also operate 3 drives) … More recently, LEGO compatible 3rd party switch drive controllers have become available: The 4DBrix (https://www.4dbrix.com/) varieties are extremely nice! What I find particularly intriguing is the control software. The entire product line from switch drive, controller, to full software integration is the best LEGO compatible solution I became aware of. Nevertheless, here is my all-LEGO “solution”: Brick-built switch drive controllers equipped with PBricks. Please don’t take this post too seriously. It was a lot of fun to build these – plus I like to see stuff moving and making noise (in addition to trains that is) on my layout. Since a video says more than 1000 words, here is the “visual summary” of the rather long write-up following below: And here are some more detailed descriptions ... Working principle The idea of this approach is rather old; in 2007 this article in Railbricks Issue #3, page 44 illustrated some details: The controllers serve more than 3 switch drives with only one PBrick by “mechanical address decoding” – or whatever you want to call it. At that time though I did not think about “simple” motorized switch drives; the ones I used then were all equipped with MicroScouts and were designed to run only with these. That limited the applicability of the controllers on my layout significantly: You need to turn on a MicroScout and put it into “P” mode to let it do what is expected from an electrified switch drive. However many of the switches are hard to get to – hiding behind bookshelves and underneath/within furniture. I have thus added mechanical switch drive controllers for operation with NXT, RCX, and Scout PBricks operating most of the LEGO electrical motors, including PF. So far I have electrified all my switches and bunched them up in “groups” using four such switch drive controllers. What are the controllers supposed to do? They serve as “local remote control hubs” for a group of switch drives. There is essentially only a purely mechanical “bricking” limitation on how many switches can be handled by each controller. The controllers have a dedicated address, for simplicity let’s say address 1, 2, 3; the individual switch drive is hooked up to the respective switch drive controller and has a local “address”, let’s say a, b, c, … The last bit of information required is the switch position, let’s call that “straight (s)” or “turn (t)”. The information sent to all the controllers on the layout is then “controller address + local switch address + switch position”, for example “2, d, t” means that switch “d” operated on controller “2” should go into “turn” position. As shown in these posts here and here, all communication on my layout is via the LEGO IR messaging protocol, mostly transported via RF. Figure 1 shows a “bare” Scout operated switch controller without any decorative stuff; Figure 2 a controller with an additional decorative brick structure remotely matching the Toy Story steam engine coaling station, Figure 3 a controller that is residing within a “building” remotely matching (if at all) the appearance the #10027 train shed – however with a rather “transparent” roof (in fact I got hold of 50+ of transparent #41750 pieces for free and all were left handed … what to do with them?). Figure 4 shows a more or less bare controller I built because I needed to serve 12 switch drives in locations under my desk and further away. All four work on the same principle, but use slightly different mechanical operating techniques. The Scout operated controllers in Picture 1 and 2 use the Scout’s Visible Light Link (VLL) terminal (“Output C”) to connect with MicroScout operated switch drives via an optical fiber link. In my opinion, TLC never really exploited the possibilities of the VLL link. They for example never produced optical fibers longer than about 20 cm, as far as I know. Rather cheap plain vanilla optical fibers (1 m for less than 1 €) are good enough. The controller in picture 3 runs with an RCX PBrick and uses PF switches to operate switch drives equipped with PF or 9V motors. It features a moving stage powered by a PF M motor and a Technic mini motor for actuating the lever throwing the PF switches. The controller in Picture 4 operates an almost identical stage. The stage drive is not mounted on the stage itself; the Scout drives the stage via Technic chain links (#3711) with a stationary #47154 motor and again a Technic mini motor (#43362) for switching. Common to all controllers is the “positioning” mechanism of the moving stage: In case of the optical controllers, VLL light from the Scout output needs to go through the corresponding fiber connecting with the MicroScout operating the switch drive. The fibers are simply pushed through Technic bushes into a Technic brick with holes, in other words they are always nicely lined up. So we just need to get the VLL light from the Scout to the corresponding hole. That is accomplished by either moving the entire Scout PBrick (see controller in Picture 2) or by moving the 20 cm long LEGO optical “fibers” (BrickLink ID x400c20). These are more or less plastic tubes that came with the ExoForce sets – finally I found a way to use them …) connected to the VLL terminal to the target hole, see picture 1. The Scout has a built-in light sensor; that one is used to detect when the VLL output diode is in line with a hole or somewhere in between by measuring the light intensity emitted from a LEGO light brick (9V or PF): When the light from that brick goes through a hole, the detector sees it “brightly”, when it is more or less blocked, it only sees a fraction of the “bright” light. When the “hole detection” mechanism is lined up with the fibers, we are done; this is readily the case when stacking Technic bricks with holes. Basically the same approach is used for the RCX controllers; here we need to get in line with the PF switch levers. When lining up PF switches directly next to each other, the levers are 3 holes apart, and we can use a simple optical positioning mechanism again to get to the right switch. The actuator of the moving stage for throwing the PF switches (see Figure 3 + 4 and video) is partly shown in Figure 6. Since the PF switch has three positions (“forward”, “0”, “reverse”) and the switch drive motor is turned on only for less than a second, the PF switch needs to be swiftly turned back to the “0” position. That is tough to do with powering the actuator motor accordingly. Furthermore, the lever needs to be straight up after switching, as the stage/actuator needs to freely pass the switches when moving to a new target. I have used the fairly tight 6.5L shock absorbers (#73129) to push the actuator back into “0” position after the switch was thrown. As mentioned, the switch is thrown with full torque of the Technic mini motor (PBrick output “full forward/reverse”) as the actuator has also always to push against one of the two springs of the shock absorbers. The output of the PBrick is then put into “float” rather than “stop” mode, so that the motor axle turns freely and the compressed spring of the absorber pushes both the PF switch lever as well as the actuator into “0” position. Programming the PBricks The programs running on the PBricks are rather straight forward. NXT, RCX, and Scout PBricks are all capable of multitasking. In my programs, one task is handling incoming messages. The moment an address is recognized by a PBrick as “my ID”, it listens very carefully for the next message(s) to come in; that one contains local switch address and desired position. The routine puts that message onto a stack, sends a “got that” reply and continues to listen for further messages to arrive. A second task watches the stack: Nothing here, nothing to do. Once there are messages on the stack it fetches one, analyzes it and drives the positioning mechanisms to the appropriate output, sends out either VLL light or briefly operates the PF switch by changing the driving Technic mini motor from “float” (off) to “forward” (or “reverse”) and then back to float. After completion it throws the message away and continues with the next one on the stack. How does each controller know, where the moving stage actually is? Upon startup, the stage is driven all the way to the right, until it reaches the “right limit” touch sensor. Then the light brick is turned on and the trolley moves all the way back to the “left limit” touch sensor. On this journey, the light sensor continuously monitors the light intensity. The brightest light value detected is then considered a “hole”; everything else “in between”. Then the trolley moves back all the way to the right touch sensor and on its way, holes are counted and each switch is thrown to get all switches into the “straight” position. Now we know how many switch points are present, we know they are all set to straight, and we know that we are at position “0”. Upon getting a message, let’s say “turn switch 5” it starts to move left and simply counts up holes. Once it arrives at “5” it stops and is automatically aligned with either a corresponding hole for the VLL output of the Scout or the lever of a PF switch. Then it either sends out the VLL forward/reverse command (Scout) for a given amount of time or it throws the PF switch (RCX/NXT), again for a given amount of time. The switch drive motors are turned on within a “hundreds of millisecond” time frame. This time is adjusted to the requirements of the switch drive. That is basically it. The VB6 program (I am old …) running on my laptop is showing my layout with all the track including switches. Basically the program is one database with some graphics and in/output around. Clicking on one of the switch symbols makes the corresponding real switch change its direction. The program searches the database and finds out which controller is assigned to this switch. Furthermore it finds out to which local output (a, b, c …) that switch is connected on the selected controller. Since the program knows the current status of the switch on the layout it composes a message as described above: Controller address + local switch address + new position and sends that out via the IR tower into RF space. There is a little more to it. To ensure rather secure communication between host computer and remote controller, there is a handshake protocol: The controllers acknowledge messages they understood. If there is no reply, the host control program repeatedly sends out the same messages. If there is still no answer for let’s say five consecutive attempts, a warning message tells that something is wrong. The controllers also have some safety routines – should the stage go beyond the end points it stops operating and sends an SOS message, and do on. Seeing this happen is real fun! However the SOS thing hardly happens at all … Another thing to notice is that MicroScouts go to “sleep mode” when not doing anything for about 10 minutes. So every 9 minutes or so, the stage is driven all the way to the left, then right, recalibrates the light sensor, and then back left, stopping at every hole and let each MicroScout play some sound. So they never fall asleep … and there is even more action on the layout. One thing I am somewhat proud of is that all that functionality is possible with 396 LEGO byte codes on the Scout controllers. The RCX PBricks have monstrous 8 kByte of storage space – I believe you could use an RCX to successfully fly to the moon, land there, play soccer, and safely return. These TLC folks are ingenious. And if you don’t want to run a clumsy computer based control program – learning remotes work also very well for easily controlling more than 30 switch drives. This was already discussed in this post. The number keys “1” through “9” correspond to switch drives 1 to 9. I first press one color key (ID), addressing a particular controller and then swiftly a number key. The controller that recognizes the address operates the corresponding switch drive and puts the switch to the “branch” position. Upon pressing the address and then number key twice, it goes to “straight” … Some files The LDraw mpd files for three controller types (Fig 1 – 3) are here along with the NQC programs here running on the PBricks. The controller in Fig. 4 is in the works). Please see readme files in the directories. Note that you need to have the official and unofficial LDraw parts libraries installed. When opening the LDraw files with MLCad, the program tells you that newer versions of some parts are available. Ignore that, otherwise the model may be corrupted. All LDraw files open correctly with LDView 4.2 and MLCad 3.5 Best regards, Thorsten

Hehe, yeap that could have fried them. But ... TINY MEMORY? On the RCX? That one is a memory monster as compared to the Scout, which has space for 396 LEGO "freely programmable" byte codes. And still can accomplish some serious tasks. And RobotC for the RCX - comes for free nowadays - has 100 power steps instead of 7. It is incredible, what an RCX (still) can do with RobotC. And with NQC. Will try to show that shortly. OK, point really is: I love RCX', Scouts, Spybots and MicroScouts as much as other folks love the wonderful 12V train line. Both are gone, but both are still incredibly fascinating. I am just frustrated, when the programmable LEGO bricks just come and go. Guess I am going off-topic here. All the best, Thorsten

The ship looks - sincerely beautiful. Much more importantly - the story is very compelling. Or better fascinating. Is it possible to sign up to join you on your journey? I'd love to be part of it ... Best Thorsten

Dear All, I don't think that PWM does any harm to the 9V train motors. All LEGO PF, RCX, NXT, EV3 devices use PWM for motor torque/power control. For all motors. The #4548 power regulator does not; this one provides constant DC voltages on the individual dial settings. However, I did not experience any problems even when using PID control using PWM as the power source. @zephyr1934 : Could it be that there were other issues you experienced, when you used the RCX? RCX PWM is tailored towards Technic mini motors (as they were available at that time) rather than 9V train motors. I am curious, as my trains partly run under RCX PWM control - so far - without problems. Thanks a lot! Thorsten

Sorry to bump this up ... this topic is rather important to me, simply due of the wealth of information available within this forum - and my own time constraints. It is hard to follow each and every relevant post to projects I am pursuing myself. When the "search" function does dig up things and they are relevant to me, then I do consider "bumping" as good thing, provided: It may be of value to others (and not just for me - that does not make any sense, PM is the way to go). That "maybe" bit is of course judged from my very own perspective - and this is where moderators come in. What else? Do I feel bad, when called to behave? No, not at all. It is >my< choice to behave and it is entirely the choice of the moderators to check on that. Otherwise I shouldn't be here. This is not about "doing what they want" - it is about "doing what they allow here". And all I can tell is that moderators allow a lot. I never saw any complaints from the moderators when a "Sorry for bumping" >and< a "good" reason was given. What is "good" or not is in the hands of the moderators, as we are just providing the reason. Moderating means exactly that: Here is a playground, do what you want, but don't play against the rules. The rules are fully visible to all players. I feel very comfortable posting on Eurobricks. And this is mainly caused by the way "Moderators" - aka individuals, people who do use their valuable time - and - who do care about the LEGO miracle - run this forum. Thank you very much for doing that. All the very best, Thorsten

I agree with JopieK: WD-40 and ABS go very well with each other; it will not hurt. The post freestorm is citing is most valuable, if that is the type of switch you are using. In that case, I would open the switch, inspect what the cause is: 1) dirt? 2) corrosion? 3) broken part? 1) I'd clean the area with sprays from the "contact" series (just an example from a German supplier). These are used in electronics for all kinds of things and there are as many spray types, just browse through the different types. Thee are many equivalents around the world. The cleaning sprays hardly affect plastics at all, they are mostly isopropanol-based or the like. Then there is a wash-off spray, which "blows" away any type of sticking cleaning fluid - there is also a harmless solvent in there, but that is very quickly drying off and mainly aiding in the mechanical impact of the spray to remove other stuff. 2) Corrosion - goes usually with 1). If the degree of corrosion is not too bad (and this is mostly the case) go either with WD-40 carefully restricted to the metal pieces affected - or use the "contact 60" spray or equivalent. Let the fluid work fro an hour, Blow off with the wash spray. Then apply "contact 61" for conservation. WD-40 is a one for all mixture it will also work on its own. But it likes to creep everywhere - even after weeks it may show up where it is not supposed to.. In that case: Clean off with isopropanol. There is no harm. 3) Broken part: ABS pieces are very nicely glued together with "super-glue", i.e. the cyano-acrylate based glues. I have used that stuff so many times with ABS - it works. Be careful though: It is "drying" (it is reacting) very fast and almost irreversibly. I would apply the glue with a (one-way) needle or the like. Let dry (max. 5 min ...) and that's it. Any purely mechanical issues are usually resolved with silicone based sprays - be careful though to not let the fluid reach the metal parts, as this type of spray is aiding electrical isolation, and is not what you want. Good luck! Best regards, Thorsten

Addendum to “Electrify your train switches” Dear all, much has been said and shown about ways to electrify LEGO 9V/PF train switches. Along with the EB electrify your train switches thread and some other posts on EB and elsewhere there hardly is anything interesting to add. But then … as said before, I am just wrapping up more than a decade of years of fun with my train layout. My switch electrification approach is far less driven by achieving “to scale modeling” or “most elegant solutions”, it is governed by “using as many diverse LEGO motors as possible” on a more or less standardized and simple drive base design “using as little parts as possible”. I simply like to make efficient use of the stuff in my LEGO boxes – since there are about 30 switch points on my layout. There are a couple of my personal design lines: Since some areas of the layout are rather “dense”, the footprint of the drive mechanism should be as small as possible A clearance that is a little greater as compared to the original configuration with the manual switch stand installed. The reason is that some of my rolling stock MODs/MOCs have a fairly large “overhang” in curves and thus need some additional clearance when passing switch points The switch drive should not fall apart even after prolonged operation as almost half of my tracks are hidden behind bookshelves and other furniture. No modification of the switch – this means that the force required to throw the switch is often considerable. The rendering below shows one very simple base design for my switch drives. It consists of a couple of Technic as well as plain bricks and plates. The rendering is already 5 years old – time is flying. This particular drive mechanism has one serious disadvantage: Operated with the full torque of the PF motors (e.g. with the PF bang-bang remote #8885) it falls apart after five or so cycles. This issue is rather easily overcome, when the torque of the driving motor is adjusted via power control and pulse timing using a programmable brick as for example an RCX or Scout. It took me ages to figure out how to accomplish that: Adjust the length (e.g. 0.3 s) and the power (on LEGO’s 0 – 7 range) for the motor “on” state. This LDraw file contains all the above varieties; the individual sub models combine to any of the drives shown. (Note that you may need to install the unofficial LDraw library as of 2016 to correctly load the files). Alternatively, paying more careful attention to the original EB switch point electrification thread entry (https://www.eurobricks.com/forum/index.php?/forums/topic/44821-electify-your-train-switches/&page=3) would have told me that Jonathan uses his NXT to do exactly that – and for long! The switch is thrown by a lever, which fits into the space between the two mounts for the manual switch stand. By small variations of the actual gear configuration, almost all typical LEGO motors can be attached. The geared varieties [e.g., PF M motor (#8883), Technic mini motor (#71427, #43362), Technic motor geared (#47154), or even the Mindstorms MicroScout PBrick (#32344] are driving the lever with none or low additional gearing ratios; the ungeared Technic motor (#2838) requires higher gear ratios to work properly. The advantage of this drive design is the footprint (as measured on the floor, not height!), which is 3(x6) studs for clearance and 5(x6) studs for the base = 8(x6) studs. The picture below shows two MicroScouts on the bridge operating the two switch points on the right. There are light fibers plugged into the MicroScout’s light sensors; these do transmit the VLL code generated by a Scout PBrick (not visible) to control them. MicroScouts operating as “intelligent motors” for switch drives are fun. The “forward/reverse” “switch” is somewhat unique: When the MicroScout is put into “P” mode it pays careful attention to its built-in light sensor. In this mode, the MicroScout understands some VLL (LEGO’s Visible Light Link protocol) commands such as “motor on forward” etc. In other words you can operate the switch using optical signals from a VLL source. The rendering below shows a Scout controller operating 4 MicroScout switch drives. This version of a switch drive has the smallest depth I could come up with to securely operate unmodified switch points: I used that one on my layout here: Here is the link to the LDraw file. In the mean time I have slightly modified the “RailBricks #9 challenge” drive (a number of ingenious train experts have contributed to this one – see the "Challenge reveal" article by Benn Coifman in RailBricks #12, page 37) and reduced the size to 5-wide at the base. This drive never falls apart, regardless how much torque is exerted on the driving axle. The design is simply amazing! I have retrofitted almost all of my switch points with this version. When a MicroScout is operating the drive, it should be oriented such that you can easily get access to the buttons (on/off, select, run). There are several drive versions to attach the MicroScout in such way that is does not interfere with the required clearance on the point and good access to the buttons. Here are some real world examples: This folder contains all LDraw files Best regards, Thorsten

Dear ALCO and gifinim, (heck, I don't know how to do that @user tag thing - do I just type @snoopy provided snoopy is a member here? I am too old for this, I guess) please let me know, what you need. Philo's homepage is a very good resource for all Mindstorms and particularly RCX related software - I believe I have also a good number of programs for you. Furthermore, if any of you want any type of NQC or whatever program, let me know. I am planning to make this all publicly available on my account, but time is an issue, has been an issue an will be. LT12V knows, what I am talking about. Best wishes Thorsten

Dear All, since 2001 I am working on this: LEGO train layout control from one single computer (trains, switch points, light, bridges, …) using as much as possible original LEGO hard- and software. Still WIP but getting close. Most of the LEGO stuff used here is – since long – not officially available anymore. But LEGO is LEGO and lasts forever … and now I am close to getting it all to work. This project has survived Win98, QBASIC, WinXP, VB6 (well not true, still using it, see below …). And as sPy pointed out correctly in his reply on my PF RF hack, all this is building on stone-old electronics hardware. But: All this stuff is still available today. BrickLink is very close to LEGO heaven, I believe. And because nobody really cares anymore about RCX’ or MicroScouts – they have become dead cheap. I recently ordered RCX’ 1.0 with power jack for less than $20 each. These are the best PBricks ever made by TLC … imho, of course. There are many powerful and elegant solutions for controlling PF operated trains as well as track/track side-related functions such as remote switch operation, lighting, train detection, and much more. Most of these are based on home-built (as for example the myriads of wonderful Arduino-based solutions) or third party commercial devices, e.g. SBrick, 4DBrix/nControl, PFx Brick, and increasingly more. And this is wonderful. This post is just another one in this line. The difference is that I tried to use exclusively original LEGO stuff. Based on IR communication, it works perfectly well, but only within a range of about 1 m, which is not that good for train/track control ... So there was “only” one but significant modification required: Changing from IR to RF communication. This post illustrated how to do that. And if you don’t want to break into your PF receiver at all but just an add-on, this works also perfectly well, but is somewhat more elaborate. The ultimate goal of this project is to control diverse LEGO devices (PF, RC-train, RCX, NXT, Scout, MicroScout, Spybotics) from one device. In my case from a program running on my computer. However this could also be any device that can generate LEGO Mindstorms IR messages (which were introduced with the RCX, as far as I know), for example: A computer with one of the LEGO IR Towers attached, running the Bricx Command Center (BricxCC) software, A computer with one of the LEGO IR Towers attached, running any other program, which has access to the LEGO IR Towers; this includes the various programming environments and languages such as NQC, RobotC, or any custom program that has access to either a serial port for the serial tower or the LEGO drivers for the USB tower. (Note that on 64 bit platforms, the USB tower does not work anymore, since TLC never updated the required driver for the tower. In that case the stone old serial tower attached to a RS232-to-USB converter has to be used and accessed via a free COM port, preferentially in the COM1 … COM8 range. Works like a charm. Some people have trouble to get BricxCC or the original RXC 2.0 Mindstorms software communicate with the RCX only caused by the missing driver. Some revert back to 32-bit or even Win98 … not necessary!) Any of the RCX, Scout, or Spybotics, NXT(+IR Link Sensor) PBricks, Any learning remote, that was trained with any of the above means of generating LEGO Mindstorms messages; I am usually using BricxCC for programming. For testing purposes on my train layout, the programmed learning remote is very handsome: On my home-office style train layout (yes, I do work here as well), there are currently running/installed 8 PF trains 1 RC train 2 RCX controlled trains In addition to 2 RCX switch controllers (one serving 7 switch points using PF M motors, the other 12) 2 Scout switch controllers (one serving 3 switch points using 3 MicroScouts, the other 7) 1 Scout train bridge controller, see below 2 RCX light controllers with 3 outputs each, see below Each of the PBricks (RCX, Scout, NXT) have their own "personal" ID they recognize and respond to; the PF and RC trains are handled by the NXT PBrick (equipped with the IR Link sensor from HiTechnic) serving as central “PF/RC-train communications hub”. The NXT recognizes a total of 3 (RC) + 8 (PF) = 11 ID’s and maps these to the 3 RC and 8 PF channels: The NXT is operated with standard LEGO firmware (V1.31) and the LEGO NXT-G software environment is used for programming. Unfortunately the IR Link sensor has a very limited communication range, far less than any other IR light emitting LEGO device. This was one more reason for me – other than wanting no line of sight operation – to switch to RF. I have thus placed one of my IRRF transceivers (big words for not much, this is just what I am calling them) right in front of the IR Link sensor, which sends out every 38kHz modulated IR light it detects into RF space and listens for any 433 MHz signals in half duplex mode on a first come first serve basis: If IR light is detected then RF is sent out – if RF is detected IR is sent out. Both channels are dynamically mutually “blocked”; when an IR message is sent out it will continue to do so until finished, the same holds true for RF. Here is an overall schematic of the RF connectivity and direction of signals. In case of PBricks (NXT, RCX, Scout, Spybot) bi-directional half-duplex communication is possible (but not required), thus the IRRF transceivers come in handy. In other words: The addressed PBrick may reply with “OK”, “Did not recognize the payload”, or “I am busy”. In case of NXT to PF or RC-train, just uni-directional communication without any feedback is possible. The NXT-G program running on the NXT PBrick equipped with the HiTechnic IR Link sensor is is available on my university account. This navigates you to a folder , which contains the entire program. It is divided into the main program “RCPF_Control_14” and several “MyBlocks”. This structure is entirely owing to the limitations of the LEGO NXT-G software GUI. One could readily program (“tie together” is better phrasing) this is one block – but the GUI freaks out when exceeding a couple of nested loops. Putting these into individual MyBlocks circumvents this problem. The compiler readily generates the correct output code – “regardless” (I found no limits) of number of MyBlocks nested or called. This is the workflow on the entire layout: Essentially, one supplies an address byte plus a payload byte consecutively as two LEGO messages within let’s say 2 seconds; that is easily manageable with the programmed remote. When programs send out the two messages, the time between ID and payload byte can be much shorter, in the 100 ms range. The two bytes are each encoded according to the “LEGO Mindstorms IR message” protocol. Prepare 2 messages: Address as LEGO IR message + payload as LEGO IR message: Send these messages consecutively out into RF space: Any “intelligent” device equipped with an RF receiver will recognize its own address, listen for the payload and act appropriately. Example: RCX1 has address 192. We issue the sequence “message 192” + “message 8”. RCX1 will now do what “8” means within its own program running. Another example: NXT1 recognizes all addresses between 194 and 205. Let us say, 194 to 202 are mapped to PF trains 1 to 8, and 203 to 205 to RC train devices 1 to 3. That would cover the regular PF and RC address space. NXT1 senses address 194 and payload “-5”. It then uses the IR Link to send out the PF single pin command “PF channel 1A motor power -5” into RF space. Which lets the corresponding PF train equipped with an RF receiver “go reverse at power level 5”. And “205 + 4” will then get RC train #3 on forward level 4. The device addressed acknowledges the reception of the messages by sending out “OK” or any kind of error message (e.g., “I am busy”) to the caller. When using one-way communication, e.g. the handheld remote control, that acknowledgement goes of course unheard – when running a program with IR tower that could be recognized by the program and acted on (simply resending the message or wait and then resend and so on). Using the PF single pin command lets the PF receiver “jump” to the respective power level; when it was at 0 = stop, sending “7” would bang the motors full forward. This is handled by the NXT program as well: It slowly increases the power level with programmable delays between the steps. This results in a more “realistic” train behavior. The LEGO RC train protocol just allows the commands “increase” (+1), “decrease” (-1), “stop” (0) on a scale of -7 to +7. The PF protocol allows the increase (+1)/decrease (-1) scheme as well, however, a control program may lose “track” when such a command issued was not received properly, since there is no feedback. When all three available RF frequencies 315, 418, and 433 MHz are used, 8 x 3 = 24 PF devices can be controlled with a total of 12 PF receivers. That is not including the change of the “address space”-bit in the PF protocol, which would double this number to 48. Any other track or trackside devices to be remotely controlled with PBricks works of course as well; here is an RCX turning on/off the light in the light house or the diffuse and changing light in a scary tunnel not shown (yet). Or a Scout letting a bridge go up or down and reporting the bridge status to the host control program. Switch drives hooked up to an RCX or Scout based brick-built “switch drive controller” may also recognize the address + payload sequence and act appropriately: “RCX2, put switch #5 in branch position”. See list of my controlled stuff above. In summary: You can control PF, RC, RCX trains and RCX, Scout, Spybot operated switches or other devices with an almost pure LEGO solution. Up next: Build switch drives and controllers solely from LEGO bricks + Scout, RCX or Spybot PBricks and then program them using LEGO software. (Sorry for the long post) Best regards, Thorsten

Hi sPy! oh man, that IS a very nice and nifty solution! I have some arduinos here, as well as RF PICs from microchip - and yes, it is amazing, what you can do with these. Here is my "motivation": Get as close to an "all LEGO solution" as possible. Just for fun that is. And also, because TLC never really showed people what their PBricks can accomplish (interaction wise). Since then I am after that ... I started this in 2001: Remote train control using RCX' - at that time all IR which was OK'ish but that was it. It worked though! At that time with QBASIC ... in an all LEGO solution Then came the RF extension using my little transceivers - it is a lot of work, but I did not break into LEGOs - yet Then I broke into LEGOs: Modified the 9V motors as power pickups (should have been done by TLC in any case, works like a charm on 9V and PF equipment Then I modified the PF receivers, because the "Big Uniting Sensor" from HiTechnic, the IR Link sensor for the NXT (that thing lets the NXT communicate with RCX, Spybots, Scouts, the whole line of PBricks!) had simply not enough range (couple of cm, sigh ...) Wait for my next post - I'll show you in more detail, what I try to do. Basically demonstrate that TLC has a number of solutions for a whole lot of automation - but a) never told us how to and of course b) it cost you a fortune. And lastly: After 16 years of work, I guess it is time to wrap this a little up. But again: I love the little arduinos very much!!! Best regards, Thorsten

Be what? Merciful??? I was a kid in the 70's and 80's depending on how you define "kid" - according to my wife I still am today - and I completely agree with you: It was easier to come up with a MOC. But you know what? The feeling of "ease" and "being satisfied" with what you created comes from your imagination. And that is the very difference for me: Imagination is what renders a studded LEGO MOC comprised of X by X bricks and plates and a couple of totally beyond belief round bricks, a never seen before tap ... in about eight colors - the most wonderful thing the world has ever seen! That is was LEGO is (was?) all about. And as Holger said: You really captured that look and feel. And: It is the most beautiful Shell terminal. I can literally feel the liquid pouring out of these taps into canisters. Wonderful decision, hope to see more of your future MOCs! Regards, Thorsten

They do cm in Bricksburg? All is good!

And even more information - presented in a brilliant way - at Philo's superb pages on every PF aspect you can think of. When you go one page up you'll get a wealth of additional valuable information on many other things. I have learned so many things from Philo's pages that I would need to repeatedly say "thank you" so many times, I wouldn't stop for hours. Good luck with your projects! Thorsten

Oh my, not again. Posting pictures rather than design files, regardless of format - in a public forum - is a very different thing. Whatever Xon is planning, whatever he has in mind, is not public business. Just because he or she shows pictures does not mean anything other than: "Look, what do you think?" As you know, some people sell their instructions or construction files. Others make them available for free. Many don't even bother, they just build an enjoy. A public post is simply is no obligation. It is a demonstration of what can be done. I completely agree with your statement about discussions! The thing though is, this is all entirely public. Or "exposed". With none of the speakers visible for the public. And that is the big difference: A discussion has usually a focus; and usually with an audience that is literal regarding the discussion topic. This is not the case here, I believe. And this is why Jim told you to continue this conversation in private. I believe you can settle much better on the issues you have raised with a personal message than rather than in public posts. One more thing: Publicly using the word "lying" is very, very strong. Maybe "Hiding something" is more appropriate, maybe not. But then: Xon can hide whatever he or she would like to hide. As far as I am concerned. Just my thoughts - and all for good! Regards, Thorsten