Toastie

Good evening Davide, you should H0 "companies" as well as TLG loudly know what you are doing here. This may be a game changer, when it comes to bricks and H0. Particularly because the number of bricks required to match both worlds, is on the much lower side as compared to the other train scale modeling worlds. This (your!) route is simply fantastic - and by the way - the principle idea of LEGO is fully resurrected: Imagine, let people think/dream/realize what a MOC represents - and make it as easy as possible. Which is what you do. The H0 scale has never really appealed to me - I mean the modeling worlds of Märklin as well as all the others. This has changed - with the advent of your ideas and realizations! I mean - "H0" includes the >full< suite of all track geometries (powered!!!) you can dream of. Wonderful. All the best, Thorsten

Ha! Hahaha! Nope - you are not telling the truth - this cannot be your first try after your dark ages... no way. OK: Maybe your first published "try" on that ... Very nice and interesting story behind your "first try" - it makes such a difference reading about what happened and "why" ... thank you very much for sharing that part. I really like the pictures from "before your dark ages" - and honestly? Already then you can clearly identify a skilled builder: The extended length of your modded train/carriages alone ... very nice! Man, I love the details to the interior - particularly the "service" section ... Do you have plans to make it "real"? It will be some investment, I guess - but totally worthwhile. I can imagine a layout/show where TLG's original passes by - and then your train approaches. Same color scheme but sooo different, I would hold my breath on that occasion. All the best and thank you for sharing your story and the nice renders! Thorsten

This is not from me but from @Mortymore. There is a thread here on EB - here is the link to the many interesting things he started/did: https://www.eurobricks.com/forum/index.php?/profile/4317-mortymore/content/&amp;type=forums_topic_post&amp;page=2 Here is @Mortymore's Brickshelf gallery regarding the PF receiver: https://brickshelf.com/cgi-bin/gallery.cgi?f=442112 There is his hand drawn schematic - I have searched a lot, before I equipped my PF receivers with an RF receiver; did not find anything better. Maybe it helps (it helped me a lot!!! I hope it is OK to post your image here @Mortymore, if not, please let me know! All the best and good luck with your project @XG BC, looks like much fun!!! Thorsten

Maybe some people here just have a different take on colors? I mean - some people here apparently are ready to sue for "wrong" colors - some people here cannot care less, and just have fun with the bricks and plates. It is up to you to judge them as terrible. I believe you can go to your profile and then do what you want.

Dr. Venkman: "What do you see here:" Me: "Uhmm - bubbles of - sort - of - different color?." Dr. Venkman: "Wrong" Bzzzzzzzzz. (My chewing gum flies out of my mouth). ... Dr. Venkman: "Nervous???" Me: "I don't like this" Dr. Venkman: "You only have 75 more to go" Best Thorsten

I did not - but it may help other folks here to be a bit more specific? What type of sensor? The way the sensor is telling the hub, what it is? Or have you figured that out already? Just any tinkering with a sensor? As you certainly are aware, @Philo has looked into the PF sensor/motor <-> hub traffic: https://www.philohome.com/wedo2reverse/protocol.htm Best, Thorsten

It depends on where the wire is damaged. When close to the receiver, and you can live with a shortened wire, just cut it, open the receiver, remove the remaining piece of wire, and press fit the cut wire in place again. Best Thorsten

Well, count me in! I did exactly the same; first Leo then Google ... Regarding life: Oh well - don't think about life because of that - just take as educational and thus quality of life enhancement. Best Thorsten

Just a heads-up: Cornelius has replied on GitHub and will have a look over the holidays, if his time allows that. Best, Thorsten

Well, this is what @legotownlinz said Flat (not warped) Same color and finish as Lego switches. ... so I believe it depends. It shouldn't be like that, of course! Also, time goes by (according to Madonna ). Oh, sure. As I said: Let's assume you have a decent 3D printer ... and use it on a day-to-day basis for something else. Buying a printer for the purpose of printing switch points does of course not make any sense. Best Thorsten

OK, I am no user of PyBricks (yet). But it appears as if you guys are really close to the hubs firmwares - developing a programming language that close to hardware seems to require detailed knowledge on that. My question is: How do you guys judge the status of TLGs LWP3.0 document on GitHub? Is this still a good reference to the lower level communication? Or did this protocol change a lot? As I am programming in VB6 with the n/software BLE stack as well as with ArduinoIDE/Legoino/NimBLE on ESP32s, I am sometimes a bit concerned about the validity of that document. Are there any ways to get updates or is this document (besides all the typos) which is so outdated? Would you guys know? All the best, Thorsten

Hello, I am the Necro Bumper I found the answer to my question above about the weird behavior of the myTrainHub.setTachoMotorSpeed(port, speed, maxPower) function. I have no clue, but are you using Legoino at all @Lok24 anymore? I believe you have migrated to PyBricks, right? I am still excited about Legoino and the things you can do with this software. It appears as if there are two little bugs in Legoino library "LPF2Hub.cpp" file, which need to be edited before it works: (1) For the setTachoMotorSpeed function in Legoino, @Cornelius used accidentally the sub-command 0x01 (StartMotorPower) but not the required 0x07 (StartMotorSpeed) sub-command of the LWP3.0 Output Command 0x81. Also, the sub-command 0x07 does not recognize any BrakingStyle::FLOAT/BRAKE, as it can't go to 0% speed; the minimum is 1%. I believe the speed regulating algorithm in the Hub's firmware does not like to go to zero, as it can't regulate anything at 0. This is also noted in TLGs (outdated!) LWP3.0 document on GitHub: " If FLOAT or BRAKE should be used e.g. when a slider is set to 0 (zero) the user has to use either StartPower(0 or 127)." Note: StartPower (0x01) I believe it is generally a good idea to clearly separate "power" and "speed"; it makes things much clearer. As far as I know, the former works for all PUp motors, the latter naturally only for "TachoMotor", e.g. the PUp L motor etc. (2) The Legoino "stopTachoMotor(port)" function calls the "setTachoMotorSpeed" function with the argument speed = 0. As dicussed, this can't work. Instead, in Legoino setBasicMotorSpeed(port, 0) must be called to stop the motor. The 0 corresponds to "0 power with brake"; when setBasicMotorSpeed(port,127) is used, this corresponds to "0 power with float". With these two changes in LPF2Hub.cpp, all the motor output functions (power, speed, speed for time, speed for degrees ...) work perfectly fine! Here is my messing with LPF2Hub.cpp in that section; it begins around the line 1220: /** * "setBasicMotorSpeed" works; should be renamed to setBasicMotorPower though * Many (minor) changes in the following, one bug, some unknown settings as marked * * From the LPW3.0 protocol: * 3.27 Motor Output Command 0x81 - MotorSubCommands [0x01 - 0x3F] * StartPower: 0x81, Sub command 0x01 Encoding: WriteDirectModeData * int8_power: Power int8_power: 0=FLOAT; 127=BREAK; -1%-100%=255-128; +1%-+100%=1-126; * * Byte| 1 | 2 | 3 | 4 | 5 | 6 | 7 | 8 | 9 | 10 | * SetPower | 07 | 00 | 81 | ID | 00 | 01 | PWR| * SetPowerAB| 08 | 00 | 81 | ID | 00 | 02 |PWR1|PWR2| * SetSpeed | 09 | 00 | 81 | ID | 00 | 07 | SPD|MPWR|PROF| * SetSpeedAB| 0A | 00 | 81 | ID | 00 | 08 |SPD1|SPD2|MPWR|PROF| * * Byte 1: Length of message * 2: Always 0 * 3: Command * 4: Port ID, supplied by hub for virtual ports upon connection * 5: 2 Startup/completion 4bit-nibble: ssss cccc; 0x00=0000 0000: buffer if necessary, no feedback * used here: 0x11=0001 0001: Execute immediately, status feedback * 6: Subcommand * 7: See table, depends on subcommand, SPD=speed; MPWR=max power for controlling speed, PROF=use profile. * 8: -"- * 9: -"- * 10: -"- * * PROF: 0000 0000=none; 0000 0001=use acc profile; 0000 0010=use dec profile; 0000 0011=0x03=use both. * All use profile combinations have been tested and work; in this library, profiles are always used. * The default profile upon hub start-up is acc/dec time=0, which is use no-profile behavior. /** * @brief Set the motor >power< on a defined port. * @param [in] port Port of the Hub on which the >power< of the motor will set (A, B) * @param [in] speed Power of the Motor -100..0..100 negative values will reverse the rotation */ void Lpf2Hub::setBasicMotorSpeed(byte port, int speed = 0) { //byte setMotorCommand[8] = {0x81, port, 0x11, 0x51, 0x00, LegoinoCommon::MapSpeed(speed)}; //train, batmobil //CHANGE: startup/completion=0x00 (buffer when necessary, no feedback); motor command 0x01 "setPower"; setMotorCommand array length byte setMotorCommand[8] = {0x81, port, 0x00, 0x01, LegoinoCommon::MapSpeed(speed)}; //train, batmobil, and others WriteValue(setMotorCommand, 5); } /** * @brief Stop the motor on a defined port. * @param [in] port Port of the Hub on which the motor will be stopped (A, B) */ void Lpf2Hub::stopBasicMotor(byte port) { setBasicMotorSpeed(port, 0); //0=BREAK or 127=FLOAT: Tested, both work. Could be an option in Legoino. } /** * @brief Set the motor >speed< on a defined port * @param [in] port Port of the Hub on which the speed of the motor will set (A, B, AB) * @param [in] speed Speed of the Motor -100..0..100 negative values will reverse the rotation */ void Lpf2Hub::setTachoMotorSpeed(byte port, int speed, byte maxPower, BrakingStyle brakingStyle) { //Use acc and dec profile (0x03 last two bits set) //In the original file, the wrong motor subcommand is used (0x01 = set power): //byte setMotorCommand[8] = {0x81, port, 0x11, 0x01, LegoinoCommon::MapSpeed(speed), maxPower, (byte)brakingStyle, 0x03}; //The set power subcommand does not have a braking style, as it can't go to 0 as argument. Motors need to be stopped with //set power subcommand 0x01 with BREAK (power=0) or FLOAT power=127) byte setMotorCommand[7] = {0x81, port, 0x00, 0x07, LegoinoCommon::MapSpeed(speed), maxPower, 0x03}; WriteValue(setMotorCommand, 7); } /** * @brief Stop the motor on a defined port. * @param [in] port Port of the Hub on which the motor will be stopped (A, B, AB, C, D) */ //There is no "set power = 0" for the sub-commands 0x07 and 0x08. Use set power=0(BREAK)/127(FLOAT) instead void Lpf2Hub::stopTachoMotor(byte port) { //setTachoMotorSpeed(port, 0); //Tested, works stopBasicMotor(port); } I will try to get in touch with Cornelius either on his GitHub Legoino repository or elsewhere. For now all the best, Thorsten

Well, that depends on your perspective. To be honest, I value injection molded pieces as far superior over printed pieces. Clutch-wise, duration-wise, and the looks ;) And me tinkering with the material. :D That's a bold statement: Let's assume you have a decent 3D printer, and you know how to operate that thing, and you have the files. Then it does not get any cheaper than printing yourself. It comes down to the raw material - which is dead cheap. Let's also assume it is fun to do so ... that does not get any better. So in essence there seem to be folks, who want a reasonably priced working double cross over, there are folks who like the crisp look of injection molded stuff and will have a go on the design, and there are folks who just - well - print the stuff that works. All are happy! Win-win-win. Best, Thorsten

@dr_spock - wow - the new Hairy Potta set actually is on par with your creation: Best and have fun with all the shades of gray Thorsten

Thanks to both of you @Tcm0 and @Lok24 for your swift replies. Will try! Best Thorsten P.S.: Oh yes, and it is always very beneficial to check with @Philo's page first ...

Thank you! Yes, back in the days I wanted to do that as well - the only problem is, that I don't know which of the PF receivers can make use of that feature and which can't. I do have one V2 receiver in my HE and could give it a try. Is there any way to know (other than the V2 imprint), which receiver type is in my hands? Thanks and all the best, Thorsten

Nice one! I believe he also has an earlier(?) video, where he "removes" the bottom plate and then inspects the cause of the failure, which is simply caused by a design flaw, as there is no spring - or, as in some versions of e.g., the FX points, rubber bands - retracting the blade into position. Just one note on the latter video: The way he removes the bottom plate is simply >brutal< . Using a (new or sharp) drill bit (2 - 3 mm diameter) for manually removing all the heads of the riveted bolt type connections of bottom and top (I believe they are secured by applying some heat to the bolt head sticking out a bit upon assembly), allows you to remove the base without using any force. Also, you can nicely reattach the bottom to the top part by applying >very tiny< spots of superglue here and there, not where the bolts are but at the borders. This way the bottom part can be removed and reattached several times, which should not be necessary - but who knows. A drill press with carefully adjusted end stop works as well, but I like to "feel" when the flattened head is removed. I did that years ago with all my 9V points (to let the lever move almost freely) and the LEGO cross over (to install the mechanism shown above). All points work flawlessly for years now after that treatment In conclusion: €30 + design flaw is a very good deal for me. Best, Thorsten

Hmm. Not throwing a switch actively is already a workaround, isn't it? I will go with the crap and just throw the points; they are either all straight or all diverging (anything else does not make sense). This then will work fine, I believe - well it works with the LEGO cross over, which is an utter failure in itself, blade position wise ; just get the stupid point blade driving rods, springs and whatnot out, and let the nylon wires do the work: Never had any failure on this one. Best, Thorsten

Hmm. I'd say yes: Dry lubricant, no silicone or the like. The powered stuff. On the other hand: When this issue is overcome by actively throwing the switch, I don't see any problems when you use either manual control and/or motorized switch drives. Best Thorsten

This is a very helpful hint! [Shouldn't we open a BB thread (I have zero problems with having that in the Community forum; however, there are so many "3rd" party things happening here - which are super helpful!!! - why not a BB thread?] Quick question: Are the parts for the crossover injection molded? And another one: When you turn it over: Are there tiny "girder type" occupied holes, which may my used to "easily" open the assembly? Or screws? Or is this boldly glued? Thank you very much for the info! Best, Thorsten EDIT: Shoot, another one: Can you easily force back the point blade back into place? EDIT: If so, it appears as if the friction between the point blade and the enclosure is too high? (Dry) Lubrication?

Wow, that is really a very fine piece of work!!! This should get more folks interested in PUp and its capabilities! Note: Your "Documentation" link points to this thread; on the other hand, the documentation PDF is also available in the GiHub project folder. All the best, Thorsten

@ejayb when you type "@Lok24" @Lok24 will get a notification that someone (= you ;)) were addressing him. Otherwise, he has to read all the messages to get hold of your inquiry. Which he will certainly do at some time, but this may speed up things a bit. I like the STOP function to stop any of my trains with full brake (= shortened outputs). I use power/speed = 0 to slow down my trains in the way you suggested. Sometimes things do go bad on a layout - you see it coming - and then the train slows down "realistically" but maybe not preventing damage ;) Just my thoughts. All the best, Thorsten

This. I am a bit more convinced (as you maybe) that you got it right. We tend to gauge things from our very own perspective. Which may be trained 30+ years following and getting used to what TLG does. However: TLG came to a grinding halt on making any decent trains - as judged from the perspective of an average train fan. Sure, the Crocodile popped up - popping up now and then is not relevant to this discussion. I am following this path: I am no good builder. I really like many of the BB designs. They charge you next to nothing - as compared to a) TLGs current price politics, and b) as compared to zero current sets from TLG. Oh sure, we can go to BL, or the like, and pay higher prices for the very, very few originals. Nope. So what I will do, said it before: Out with the apparently non-functional BB parts, replace them by or even mod around with the SuperParts. I sure hope that the SuperParts are not becoming the single advantage of the SuperCompany. That >never ever< worked in history (as in > 1 - 100 years). As SuperParts can be made better upon natural evolution - and will "do" so. Designs though are evolving on a different temporal scale, these are decoupled from the usually "slow" stuff evolution processes (including phalanxes of legal folks). They are made by inspiration. Homo sapiens is pretty good at thinking about what could work. The internet is promoting this endlessly - but not the legal crap. So: I will check it out, simple as that. Best wishes, Thorsten

Wow. This is beyond belief. What a fantastic job. I simply love Dune (the book(s)) - I admire Frank Herbert as an "author". Or better as the creator of entire worlds and universes. What you have accomplished here goes into the same direction. I love LEGO as well - and this rendition of an ornithopter is so well done. Congratulations!!! All the best, Thorsten

Amen. 100% agreed. Best Thorsten