Search the Community

Dear All, LEGO lasts forever – assuming “forever” is exceeding 6 decades – which surely will happen (or has happened already?). I still have bricks from 1965 (my first LEGO set was #323 – a push along steam train running on rubber tires …) – that still have very good clutch, colors only very little faded – and seamlessly fit into 2017 sets. Almost as long as I live, LEGO has been part of my life. True, there were dark ages from the late 1970’s to 1996 – but then it instantly came back – everything: The excitement about a new model, just another LEGO box, new bricks, colors … and it never disappeared since then, in contrast. 1998 was the ultimate rush back into the LEGO world: The Mindstorms RIS system – the RCX (at that time without the “1.0” extension) – it blew my mind. And since then a somewhat larger collection of all themes has assembled over the past 20 years. Building over multiple themes is my brick-philosophy. During my dark ages computer technology became my favorite hobby. The “IBM PC” was lightyears out of reach but other miracle machines came up: The C64, the Sinclair ZX81 – and that one was within reach of my limited budget! 1 kByte of memory and a 16 kByte dynamic RAM extension I built myself. “Tri state TTL bidirectional bus drivers”, the 74LS243 – and no internet, that remained to be invented. And it went on – the ZX Spectrum with 16 kByte of on-board memory got a 64 kByte memory “upgrade” – switchable in two banks. It was fun. Today, TTL chips are fading out and 64 kByte would result in the worst digital “photo” ever … I am not whining – so many wonderful new things have emerged! What really shocked me though was when TLG did not even think about making a 64 bit driver for the “perfect” Mindstorms USB IR/VLL tower. That beautiful communication hub for all RCX1.0, 1.5, 2.0, Scout, Spybotics, MicroScout, CodePilot bricks one is truly dead since 64 bit operating systems have taken over. At least this is what I have learned from the internet after years of searching. The next shock came around 2002, when .NET came up and Microsoft said “no more VB6 development at all”. VB.NET was so different from what I knew. In the following years I stuck to VB6 … my fault, sure. But I am moving slowly as time for LEGO is rather limited. XP vanished, 32 bit OS came out of fashion – and all that cool stuff – the Mindstorms software, the NXT software, NQC for RCX, RobotC for RCX … and all my VB6 programs – almost “gone”. Well, I kept of course my Dell Latitude E6500 laptop running WinXP SP3 with all that stuff installed and I still have it! Carefully backed-up everything and there it is, slowly aging. I hardly like to play with that thing – I don’t want that it gives up, which will eventually happen of course. Yes I know: “Install XP within a virtual machine” – but that did not work to the extent I would like to use a “LEGO programming and playing workspace”. The one thing that changed everything were internet rumors about the old Mindstorms RS232 tower working well with NQC/BricxCC on a 64 bit Win7 machine. So for the past couple of days between Christmas and New Year’s I was browsing the net, installing this and that, copying stuff from my old XP machine … and: BINGO. It all works! Everything works on my rather new DELL Precision 7510 with Win10 Professional as OS. All the old-back-from-the-late-1990’s stuff! OK, I know, not everybody will be as excited as I am. But I believe LEGO lasts forever – and now all the software I love so much, as well as all my old-fashioned programmable bricks (there are currently 9 RCX1.0, 6 Scouts, 10 MicroScouts, and 1 NXT PBricks doing work on my train layout) are directly accessible from this laptop, and they are programmed/operated using NQC/BricxCC, NXC, NXT-G, RobotC, the Mindstorms SDK 2.5, and most importantly VB6 SP6 programs – all natively running on a Win10 64 bit platform. A dream came true. And for all old or old-fashioned Mindstorms PBrick heads, for all who never managed to get their head around .NET stuff, for all who still believe that RCX’ and Scouts are miracle thing: Here is how I got it to work: Assemble some software from the internet: BricxCC (free, latest version from 2011) The Mindstorms Software Developers Kit (SDK) 2.5 (free on Philo’s homepage) RobotC for RCX 2.03 (which is free as well). Don’t download the 32 bit tower driver. It won’t work. The NXT 64 bit driver from TLG VB6 SP6 from Microsoft VB6 cumulative update for SP6 from Microsoft Get out the original CDs for: VB6 (SP5 or higher) The NXT-G 2.0 software suite – if that is not at hand, TLG’s Mindstorms website has it Assemble some required hardware The Mindstorms RS232 tower. They came in 1998 with the original RIS system – and they are widely available at BrickLink for about $5. Don’t forget to put a fresh 9V battery into the battery compartment on the back. Slide the range knob on the front to the left (short range). An USB2RS232 converter – I tried a (randomly picked) LogiLink converter, which works just fine. A PBrick of type RCX, RCX1.5, RCX2.0, Scout, or Spybotics. The next steps are for proper tower access: Plugin the USB2RS232 converter into the computer and let it find and install the driver (either shipped with the converter or on the internet). Open device manager (Windows key + X, select “Device Manager”), expand the “Ports (COM and LPT)” section, find the “USB Serial Port (COM X)” entry, double click it, choose “Port settings” then “Advanced” and make sure the COM port for this device is in the range between 1 and 8. Otherwise BricxCC and other old programs will not find the USB/RS232 converter = IR tower! It cost me some time to figure that out. When all COM ports in this range are taken by other devices, move one of them to the next free COM port far up and then manually (modern hard/software has no issue using COM ports in the range exceeding COM 8!) assign the converter to the now free COM port in the 1 – 8 range. Plugin the IR tower cable into the USB2RS232 converter. Next is getting access to RCX, RCX2, Scout, and Spybotics PBricks via BricxCC – this will also let you download the latest RCX firmware is case it is “gone”: Install BricxCC (full install) – this comes with NQC and many more things, e.g., the RCX firmware downloader. Put a PBrick from the list above into the IR tower range, a couple of inches away. Start-up BricxCC – it will try to connect to an RCX PBrick and most probably fail (“Cannot find brick. Switch it on or move it closer and press OK”). Press “Cancel”. Select “Tools” in the menu, go to “Find brick” and in the window that opens, select the correct COM port manually. Also select the correct PBrick. An RCX, RCX1.5, or RCX2 without firmware will correctly reply to the “RCX-type” in this window. The LED in the tower should come on and the program should connect to the PBrick, which is shown by many of the menu icons now being enabled. Download firmware to the PBrick (RCX, RCX1.5, RCX2) and that is done. Next is RobotC – this very straight forward: Install the software and run it. Select menu entry “Robot” and then “Platform type”. This should be “LEGO Mindstorms RCX”. Select menu entry “View”, then “Preferences”, then “RCX communications port” and select the COM port you have the USB to serial converter on. Download the required RobotC RCX firmware – and done. Next ist NXT-G – again very straight forward: Install the NXT-G software. Install the 64 bit NXT driver – done. Finally VB 6 – this is a little more elaborate: Install the Mindstorms SDK 2.5 – this will register one essential DLL correctly (vpbcom.dll). I don’t know how many times I tried that manually – I am too old I guess. Don’t install any USB tower software – it won’t work. You can test a PBrick connection using the “ScriptEd” program – upon starting it, the IR Tower LED should come on. This program also lets you download firmware or monitor the IR tower. Very handy for checking things. Install VB 6 from the CD. Now the trick here is that a full default install won’t work. Follow the instructions of this youtube video. There are many others, but this worked for me. I did the install directly from the “VB6 Professional CD” I still had (the video assumes you have an enterprise version but that makes no difference). The single most important point is to uncheck either the entire “Data Access” check box during the preparation steps for the installation or select “Data Access”, click “Change Options” and uncheck the “ADO, RDS, OLE DB Data providers” entry. The let the install program do what it has to do and be patient at the end, when it attempts to register all sorts of things. That may take several minutes, at least on my machine. I had a cup of coffee, did some other things and when I came back, it successfully finished the install. Install VB6 SP6 in case it is not already on the CD. Install the cumulative patch for VB6 SP6 in case it is not already on the CD. Right click on the new VB6 icon in the start menu, go to “Properties” and select “Run in XP SP3 compatibility mode”. Run VB6. Open or start a new project, then select “Project”, “References” and then tick the “LEGO VPBrick 2.1 Type Library” – and access to the above PBricks is established! The Mindstorms SDK has a PDF explaining the calls to the routines you need for that (e.g. ”FindPort” or “OpenPort”. This is it. At least on my computer. There may some other things to do on other machines, but it really appears to be doable. Just in case you want to program with VB6 “forever” or more importantly run all of TLG’s miracle PBricks from the latest Microsoft OS … as I do. And Yes I know, neither Microsoft nor any decent programmer will endorse this, in contrast. But then: It wasn’t my fault that TLG never published a 64bit driver for the Mindstorms USB tower. Nor did Microsoft ask me whether or not it would be OK to abandon VB6. All the 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

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

This was an experiment of automation of a tramway line with an old LEGO RCX brick: All sensors and cables are 100% LEGO. There are 8 light sensor, 4 (two couples, one couple for station and one for switch zone) on input 1 and 4 on input 2. 3 output, output A (station 1 - switch), output B (station 2 - switch) and output C (switch zone). Everything is handled by NQC program

Hello everyone, This is an old topic but I need your help. I acquired the set 9731 LM Vision Command without the original software but I have already found the version for Windows 98. Now i'm searching for the English version for WinXP and I can't found nowhere. At BrickLink, only other languages are on sale for WinXP :( Can someone share the installation CD in English of LEGO Mindstorms Vision Command for WinXP or where can I download the software in English?? Any help appreciated...

While skiing I had the idea to reproduce an entire detachable ropeway just with LEGO-Technic-Bricks. After 400 hours of developing, testing and programming the model was built from scratch without any construction plans. This ropeway is an improved version of my first ropeway 2 years ago ;) This model-ropeway works just as its real brother. The eight gondolas are detached in the stations and slowed down to let passengers board easily. But not just the cable-clamp-mechanism is realized like in real ropeways but also the rope tensioner. This mechanism keeps the haul-rope always tensioned by the information of the sensors. Other sensors supervise the distance between the gondolas and adjust it when needed by slowing down a specific motor. Also the haul-rope is monitored by sensors. If the rope falls out of a deflection pulley the whole system performs an emergency-stop. The entire model and even the whole control system with sensors and processors consists of usual LEGO-parts and is driven by 16 motors in total. Along with about 300 gears and 1‘000 chain-links, 10'000 parts were needed. Pictures of the building process can be found on Facebook Next year I plan to build an intermediate station with another 6’000 parts. The whole ropeway-model then will be powered by 30 motors, 4 Mindstorms-Computers, 15meters of technic-chain-links and about 500 gears.

hi all im looking for a ball counting program made with rcx code 2.0 its for a conveyor like this one http://www.brickshelf.com/cgi-bin/gallery.cgi?i=2036337

This project is the culmination of everything I have ever wanted to build. The Aquazone theme will always hold a special place in my heart, and Lego Technic and Mindstorms have solidified my lifetime addiction to Lego. I know this is a bit of a blast from the past using rcx's but they are cheap (as am I) and readily available on ebay. Not to mention they fit the color scheme ;). I got 10 between 2 ebay auctions and after a few hours of cleaning battery acid and a few solder joints i was left with 6 working units. I sold off some of my collection (bye bye maersk train), mostly minifigs to finance my ebay findings (hello dacta control center). Most of the Aquazone sets were bought years ago on ebay once I got my first job, I was able to snag one of most every original aquazone sets that i couldn't afford as a kid. Now that the history is out of the way on to the building! Features so far include: 2 sets of LED's given a random power level every 10ms, to give a nice flicker effect in the cave. 1 Lamp (more coming from bricklink!), randomly goes between power level 6 and 7 on a slow cycle. This is designed to catch the eye and add realism. Cant wait to get more to light the entire model. Power station in back powered by classic 9v non-geared motor, The propellors spin at different speeds thanks to different sized pulleys mounted on smooth axles, the smooth axles a carefully pushed through the friction pins of the propellors. Automatic air compressor using a rotation sensor to stop at max pressure, and a touch sensor and pneumatic cylinder to trigger start at min pressure. Also features manual override touch sensor to start again. Power functions RC robotic arm, doesnt quite fit in yet, but it will eventually, again this is a work in progress. The picture below is an overview of a somewhat recent picture, for the most recent work check out the brickshelf link. I will eventually post a video of the completed model without all the technical jargon. But if you are in to technical jargon the youtube videos below go in to detail as the model has progressed. Brickshelf Folder http://www.brickshel...ry.cgi?f=546905 Worklog Videos with Commentary part 1 part 2 part 3 part 4 part 5 part 6

Hi i saw in a document that it is possible to powering a RCX mindstorm (yellow one) by a jack plug in? I've a 1.0 and a 2.0 and didn't see any jack plug in? can you help me to find it? Thanks

I want to know if someone know how to check if a locomotive is on a curve track? One way is to use a axle to instead of bogie pin, then put a rotation sensor around that axle so that curve track can be checked. Does anyone have any more simple way to check locomotive on curve track?

I have a lot light sensors and wires connectors, maybe it is too old, I found the wire core is exposed as in picture, I want to replace this wire to a new wire, how can I do? What can I open bottom plate and what tool to be used? Does any expert give some suggestion to repair it?

Indeed! I am moving it to Mindstorms Programming

I am still using old RCX and serial IR tower for my projects. I have a question about old IR tower, can I use a 9v power supply to this tower instead if 9v battery?

This is simple project, there are only two RCXs, one is on mobile deCoupler, one is to control switch track and power on track.you can find IR communication between two RCXs. With PF system, maybe this mobile deCoupler is useless, but it was not a bad idea before PF:)

I used four RCXs to control two trains, one car, three switch tracks and one cross leveling, there are five light sensors to check three switch tracks, two light sensors to check cross leveling. RCX1 is master to control RCX2 and RCX3, then RCX3 is to control RCX4, all programs is run in brickOS. Now I try to convert this project to PF system so that all wires will be moved. This is layout and some pictures, You can view trains and car moving

[ full gallery] I have finally had a chance to photograph my semaphores. First off the signal bridge is modified version of a design I first saw by Jeramy Spurgeon. I have since seen this idea duplicated on several other layouts, but so far all of the examples I have seen have inactive signals. Sure, I had working LED signals, but then a few years back I started thinking about semaphores. There is just something nice about the changing position. So soon enough, I combined my semaphore idea with the signal bridge design. The MOC is tucked away in a dark corner of my layout and my camera batteries were dying, so I couldn't get any good video, but I was able to piece together this animated gif to give you an idea of how they look when operating. The mechanicals are fairly simple, a PF m-motor with a rubber band for a clutch. The one non-obvious feature is the two 1x1 plates just below the red and white semaphore arm. These are twisted ever so slightly to provide stopping points, the plate in back for the white and the plate in front for the red. I use an RCX to run the whole signal tower with a simple "break beam" train detector consisting of a PF LED pair in the middle shining on two light sensors, one for each track. I used a technic half pin to keep the emitted light beam tightly focused and a 1x1 plate sized hole in front of the sensor to keep as much ambient light out as possible. Because the whole setup is in a dark corner, the light for the sensor looks a lot brighter in the photos than it would normally look, e.g., I had the semaphores at one show and some of my club members were puzzling over how it sensed the trains. Given normal light levels it was a lot harder to see the light used for the sensor. The RCX is tucked away in a snug shed along the tracks, with cables coming out for the sensors, light, and motors. The program isn't complicated, but it does have a few clever tricks worked in, e.g., at startup it samples the background light level and stores that for a reference (instead of using a hardcoded value). It then does a loop to check if beam a has broken (saving the result in a variable), then if beam b has broken (again saving the result), then checks to see if it needs to change the state of either semaphore (either due to a newly broken beam or timing out since the last detection). Then loops back. Since most of the action is confined to the conditional statements, the program can complete the loop quickly and sample both tracks with a fairly frequency. I should also mention that I do not actually cut power to the track, so these are just for show. It should be fairly simple to modify this set up to control a single block on one track. [ full gallery]