Toastie

This is really extremely nice! Never heard of that mechanism - but then I have never heard of many other things here in the Technic forum. How did you do the motor control? Using the PUp remote and then setting manually the speed of the motors? Or do you have some sort of "power" and "rudder" dial, which lets you do things semi-automatically? Really nice. Congratulations on making it work such impressively! Best regards, Thorsten

Ahh, that is something entirely different! Believe me, all I do when using MLCad is documenting - be it just fractions of a build. Or just recently: When I modded a 10-wide BR 89 regarding the drive train, adding PUp), I first assembled the original build in MLCad (up to the stage where no more changes to the original were required = the super structure) - and then made all the changes. This is more a re-engineering (or top down) rather than a creative bottom up process. MLCad, as said, never gets nervous when something is a bit off or the like When building something from scratch: Always in real bricks - endless variations - and then documentation with - well, MLCad. What helps in this regard (using stone old software), as @dr_spock has pointed out elsewhere, is being older than dirt ... Best, Thorsten

Ever tried MLCad? There is no clicking into place or screaming "violation" - it just does what you tell it to do. If that is not intuitive, I don't know. As you are a hardcore builder, it even lets you place one brick literally into another - if that is not hardcore, I don't know. For me, everything in MLCad is intuitive - doing crazy things, violating the laws, and mostly important: Make illegal connections. And as a sidekick, it lets you make very nice - legal - models. It is up-to you ... What I like the most is, that MLCad always remains calm - telling you: Try it, apprentice. Best, Thorsten

And that is also fine with me - but then I would not even apply. This is my problem, and others may see it differently and do not care at all! However : When setting up - any - competition, i.e., there is a limitation of X (let X be space, could be anything) - volunteers or not - a somehow "fair" (I know: Nothing is fair) approach is setting up a list of criteria. Let's say 5. Or 10. Then make a box behind them and rank them on a scale of 1 to 5 (it is always good to avoid 0). Then summarize the numbers. Should there be entries with equal numbers, discuss briefly. Even the evaluated list will make some sense to the competitors. Way more than "sorry". The time one spends on this is really low. I am on many committees in my university - and now and then there have decisions to be made. Smoke and mirrors never do a good job in the long run. Furthermore, even with volunteers who simply don't have the time to write things up because they have a life to live: A photocopy of the evaluated scoresheet (well, a cell phone shot will do), which also shows the criteria for the decision-making process, which were put-up before the decision-making process, makes things much more transparent - with not that much of time consume. In the end, there was a decision. No feedback means (to me): Some folks in charge roll the dice. Or some folks in charge like some folks competing - but not all of them. I have simply seen it too often. I do remember my time as assistant professor in the US. I will never forget when NSF invited (for whatever reasons, maybe they liked lasers as well ) me, a rookie at UCI to Washington - for evaluating really large projects. No criteria. Nothing. Just names and projects. When I read my evaluation (made my own criteria list, took me ages, read every proposal assigned to me, made my calculation) to them, one big guy from NSF asked: "Who is this? Does he know what he is talking about? You can't let that group down!" And I tell you, the proposal from that group was ... crappy. As if they knew: We're in. Again: My problem. But Hanso's reaction triggered me. Big time. Particularly because the time competitors spend on creating/making their entry is >> than any decision process. Again, I know, it has to be like that. But a criteria list with scores from each referee, accounted for by the committee chief, then evaluated by her or him and put up to discussion, and then a copy of the result sheet for each competitor takes a fraction of time more than writing "sorry". I mean, the committee had to come to a conclusion anyway, so that time does not count as "extra". I believe they do it that way even here on EB, looking at the Technic competitions. I know I sound weird. And I don't say somebody did something wrong. Not at all! I am just saying what I would do, because I believe to know how Hanso must feel; I have been there, and then seen it too many times. That's all folks, don't take this too seriously! Sorry for getting derailed a bit. All the best, Thorsten

That is very good to hear! However, "knowledge" becomes knowledge by sharing, explaining, and interpreting "knowledge" - so in a competition, or better call it a peer review process, as Hanso's and his folks' entry is reviewed by his peers, constructive feedback of why what happens is - as far as I am concerned - as much (sometimes even more) valuable as the entire work, as such feedback may/should actually result in better performance regarding further tries. That's the only part I was and will heavily criticize, regardless of topic: A competition for limited something, a review process and no feedback = a waste of time. When we submit a research paper to a journal, and the reviews are really harsh and even suggest to the editor to reject it, I tell my folks to just digest them for a week before freaking out. There must be something wrong - as our peers (in my research area) are usually not committed to shoot down a paper, but to increase the paper quality. The worst review is of the type: "Good work, publish as is" = don't want to deal with it further or: "Not good, reject" = either did not understand it or something made me angry. Good reviews have a short summary and then a bullet point list of things the reviewer was not happy with. And I believe in every peer reviewed process there should be at least a bullet point list, or even just a score behind a criteria list. Doesn't take much time. But: "No, sorry" - well - that is useless. In my opinion. You know, this is the useless way TLG is doing it with IDEAS. Best, Thorsten

Shit. (I typed Sh*t, this will most certainly replaced by the Big Brother tool of EB with "megablocks". So replace sh*t with merde, as that tool does not speak French ...) And this tells a lot. First, don't feel bad or discouraged; you know, the selection team may be way less knowledgeable than you guys are . Second, what were the official "criteria" for the selection process, if there were any? If there are: Did you go along these lines? (I would never do that, because it means tailoring your approach towards appealing to the criteria rather than being unique. However, wanting to be there, whatever it costs, is another thing. If that is most important, then, well, play along the criteria line - and cheat. Just tell them you rock. Not my cup of tea, but I believe or have learnt that this is how it works ...) Let's assume there were no criteria for the selection: In that case ... I wouldn't even apply. An event is an event, and it has to - in the view of the organizers - appeal to the expected crowd. You assembled a "system" that is way beyond belief for many, I'd say incomprehensible. A - from a programming, or logical perspective - breathtakingly nice system. Complex, functioning, for me: Wonderful. My world. Team work. Nothing, an individual could do in a restricted amount of time. But maybe the committee was looking for "action". Fast movement. The "how did that happen" moment, as there is replay only so often. To get the crow excited. Slow, but determined, clearly functioning, logically evolving, showing and demonstrating processes - may not catch on with a committee of a "show", call it "LEGO World 2022 Utrecht". I may be totally wrong. No question. If I were you though, I'd stick to what you are doing: Fantastic work, suitable for classes at university level curricula: "Advanced Programming of Microcontrollers"; "Complex Problem-Solving"; "Team Building in the Engineering World" and so on and so forth. Stick with it. It is fantastic work you are doing, and your accomplishments prove that. All the best, and ... Just keep Doing It. Thorsten P.S.: Yes, find out who the "judges are/were" and if you have a chance, hose them down with a foam canon modulated with some code of your programs in binary form: 0 = off for 1 s, 1 = on for 1 s. I'd suggest for the foam ... pink as color and gin/tonic as taste. Maybe that would make them accept you to the show. Na, it wouldn't: Judges of that kind just don't get it

Ahh, now I get it: You mean folks having the PU motors but their own (programmable) controllers, right? If so, yes, that could do the trick. The main obstacle for me would be to tap into the PU data flow - they have done it and shown it partly on EB; also Philo did that, I believe. To me, this protocol looks like trying to land on the moon without crashing the thing. But I may be wrong. Best, Thorsten

Oh come on, Dave, you just dwarfed all the programming fun! All the theoretical thinking and worries - but I guess you are right There is only one thing left for the theory folks: Optimization. When you let the DC motors doing it by themselves, the most powerful(s) will almost do it all - and it is not that much of a difference (but it still is, as you said!) to have a weaker member in there - it will basically move along. With some programming, you could kick their butt a bit more. A bit. That's all. Again: It does not make the big difference. All the best, Thorsten

Pretty much so. I believe it would be easier though to use the internal hub "hold speed software", as you also take care of any load changes. Furthermore, the adjusting speed function between the two motors/gears/circumference is more or less linear (as speed is proportional to rpm and this is what the hub's algorithm tries to accomplish, reach constant rpm), so that speed_1 = speed_2 * x ( with 0 < x <= 1, provided the entire drive train and wheel circumference of 2 results in larger speed at identical manual speed_1 and speed_2 settings). Once x is determined, you only have to turn one dial (speed_1). All the programming of reading the rpm and adjusting power is already built into the hub's firmware, why not building on that. Best, Thorsten

I'd like to cite Douglas Adams: "Now it is such a bizarrely improbable coincidence that anything so mind-bogglingly useful could have evolved purely by chance ..." A 4-pack of straight track for €1,33 ??? The probability of this to happen is - well, bizarrely improbable and in case of TLG (as judged from company founding up-to now) zero. I just put one of these items into the PaB cart: €1,33 + €9 S&H. No, I did not click on checkout Best, Thorsten

Did you see this thread? I believe a DC motor does not stop like that because it has gone bad. I may be wrong, though. Nevertheless: Instead of replacing the motor, I'd check the things mentioned in that thread first and then, if nothing helps, focus on the PTC first: You can simply remove it and then see what happens. Best, Thorsten

Oh yes, I can clearly see this huge re-design effort ... Now, you are talking about PF gear, correct? If so, as @ThePhatController suggested, his tweaking approach may work. I believe visiting @Philo's motor comparison page is always beneficial, when it comes to motor questions (and many, many other things as well). The PF L motor makes 390 rpm on a 9V supply, the PF XL 220. Depending on your gearing, this will of course change everything. The motors do also have different load/no load characteristics, so that will also affect the actual rpm at specific power settings, even when tweaked under "locomotive only" conditions. Another crazy way out would be using PUp gear using 2x PUp L motors - and then use the SetSpeed rather than SetPower function. Then you do the same test as @ThePhatController has suggested and tweak the speed (not power) in a way, that they both run - well - at the same speed. It will certainly not be the same speed setting on the controlling device, as this depends again on your gearing ratios tender:locomotive, wheel size, and friction forces. However, once you figured out which speed setting on the tender matches that on the locomotive, you're done: The PUp hub (make it a 2-port City hub), will now keep the speed of tender and locomotive constant. This should also balance out the electrical stress on both motors a bit, as they "help each other out". BTW, I find the PUp L motors quite powerful (8.8 N cm). The PF L provides 6.5 N cm, the PF XL 14.5 N cm => 21 N cm total. 2x PUp L (8.8 N cm) results in 17.6 N cm - all without gearing and such. The PUp XL is not doing anything better, as it also provides 8.8 N cm, but is geared differently. I also find their footprint and geometry favorable for integration into System and/or Technic builds. Crazy? Sure, but I believe it may actually work. All the best, Thorsten

WHAT? Oh my goodness. And I thought, I will never find rest I shall apply for asylum immediately - after a few tests I bet they will grant me citizenship. Back in the days, Doc Colorful thought I was either faking or his fancy apparatus was broken. Both were not true. This also explains, why I never had any color issues, when ordering from Bricklink (or TLG or BB or who cares from who ...) All the best, and let the LEGO white put on some nice weathering. Or the red all shades of gray Best, Thorsten

Oh my. I thought it was the engine and the carriages that are simply beyond belief. Well: Wrong! So wrong! It is the engine and the carriages "living" in these wonderful colors and then (as if she were absolutely self-confident - pulling these endless wagons) steadily pulling the looong train through that beautiful environment - and at the same time the entire train appears light and happy and as if smiling at the surroundings - the river, the rock, the trees, the bridges - caring zero about the outside LEGO worlders running around. You know, this train is so different from the German steam trains - mostly black/red engines, some white stripes - (dark) green carriages (OK, I know, some engines were blue, some green, some carriages were silver, others brown and I bet some were even differently colored - in another shade of gray). But orange, yellow, red? Daylight ... this is beautiful. The beautiful setting and the train as the star. Or the other way around: The fantastic scenery as the star and a beautiful, a colorful train coming through. Just breathtakingly beautiful. This is much, much more than I could envision. Thank you very much for sharing these pictures. All the best and have fun, Thorsten

None of the above. I played with LEGO (and with LEGOs ) all my life, except between 1977 - 1996. Never ever I felt anything like embarrassed when buying sets. In contrast: When somebody asks, sure, this is for me. No one in the family is interested to the extent of playing/building but all, both family, friends, my coworkers/colleagues have accepted that as a solid, unbreakable fact: I am playing with LEGO. And thus I when birthday or Christmas arrives - guess what happens ... No, I am not. I contrast. All the best, Thorsten

Thank you very much for doing this!!! I really appreciate that! Well - way out of my league as well - if I would approach Ms Toastie with any of these price tags ... loud laughter, yes I believe this would best describe her reaction Thanks again! Best wishes, Thorsten

This is breathtakingly nice (all of your modules!!!) and so well-thought-out! Wow. The price tag on these modules/layouts is also pretty tough, right? Is there a way to estimate the costs per module? Very impressive. With very best regards, Thorsten

Oh man, this is so cool and so nicely done. I also love the colors - this one is sure a chief or leader of a gang of a bunch of them (in lame gray). Congratulations!!! And thanks for sharing - with your pictures and advice you have given here, I may actually try to make one myself ... and then for me, a dream comes true. All the best, Thorsten

Absolutely wonderful. I love the colors - although I am a bit underexposed in that regard (well and maybe in many others as well ) - but knowing what they are ... the appearance is so different from the steamers I know of; this is a colorful, yet very powerful and at the same time very elegantly looking (and of course very nicely done) train. All the best and have fun, Thorsten

So I finally figured it out – I mean, why “simply” blocking the wheel set of an arbitrary wagon in a consist leads to decoupling at that very position. Remember that I had headaches because of not understanding that? They’re gone. I am not talking about the “weakening” of the magnetic coupling between two magnets by pushing them slightly apart (as discussed and shown by @zephyr1934 and @Lok24) or even blocking one car and pushing the other away, as shown by @Lok24 and @Ts__. Pros and cons have been discussed here and elsewhere. These are very smart solutions and render the section below meaningless. However … I am just talking about a simple one-side blocking – realized by others in many ways. Even the 12V train system does that (cf. e.g. @Reker1000000's videos in the corresponding thread here on EB as well as on other YouTube channels); also the 4DBrix decoupler does it that way: It simply blocks one wheel set to move any further when the exact position of magnetic coupling between two cars has been (automatically) detected: However, a quick experiment with a consist of 5 different cars, some heavier, some very light, clearly shows that simply blocking does not decouple the blocked car(s), but the weakest magnetic coupling of the consist. As I expected. And always. When you have some more cars, and you find pairs of magnets, which create (almost) identical magnetic force between them, then decoupling occurs statistically along the consist. The latter experiment took me a while, but eventually I found some cars behaving like that. And again: As expected, see my little drawing somewhere above; the pulling force of the engine (or my hand) is equally distributed over all couplings – and naturally the weakest will decouple. Or if they are all identical, statistics rules. Now, why on earth do all the “simply blocking the car/set of cars you want to decouple" designs work, then? We speculated it was: “Shown only the attempts, when it worked”. Hmm. I doubted it. And why did my experiment demonstrate, that it does not work? Further investigation strongly suggests: It is the acceleration (and mass) of the entire consist that generates the required surplus force acting on the coupling to be decoupled. This is the difference between my experiment and “all the others”, favorably shown in the 4DBrix video, as here you can clearly see what happens: In the 4DBrix video one can see, that when the coupling is precisely located (man, this is a nice way of doing it!!! Using a Hall sensor – very cool), there is still some considerable "slack" (distance) between the wheel block and this position. Then the engine is fired up (and in many videos out there people point out to use new rubber bands on the wheels, to quickly move the engine away, etc.) accelerating the entire consist, and only then one car runs into the block. At that moment, the car(s) to be decoupled instantaneously stop, while the remaining consist has gained some speed, caused by the acceleration, and the latter leads to an additional force into the direction of the moving consist, i.e., at the coupling of the blocked car, but not at all the other couplings – as they are still moving. In contrast, in my experiment, I blocked the last car at one end, then pulled carefully at the other end and moved the consist into “position”, i.e., the last car touched the block. Then I carefully pulled with increasing force the car at the other end. Decoupling was either at arbitrary positions or at the weakest coupling. Always. And hardly at the blocked car. When repeating my experiment, adding some “slack” between block and wheel set, the expected behavior of a decoupler results: It decouples where it is supposed to decouple. The smaller the acceleration is, the less reliably it works. Success rate is 100% when the acceleration of the entire consist is large enough to generate sufficient additional decoupling force via F(add) = m a, where F(add) denotes the additional force acting on the critical coupling, m is the mass of the remaining consist, and a is the current acceleration when running into the block. A sufficient distance between block and “decoupling position = beginning of acceleration phase” is required to allow the engine actually building up some acceleration (note that velocity is not critical and that a of the consist remains zero when there is no distance between blocking and starting position). In other words: All is in harmony. Best, Thorsten

I love it! Actually, I love all your creations you have show here. LEGO at its very best. This is one is fantastic! All the best, Thorsten

Did you see this video? OK, it is in German but is fun to watch: Now, this is also one of my ever "wanted" sets - I just recovered from my dark ages back then ... and I just learnt about the Technic series. And I certainly don't want to spend any stupid prices, given that almost all pieces are still available today. Colors mean not much to me; I bet they have painted them in every conceivable color, as the Empire had many planets to dwarf. Dune for example would favorably be worked on in camouflage other than that old dark gray This is so cool ... Good luck!!! All the best, Thorsten

I believe the "wait for message" loop in Philo's NXT-G receive program is essential. As far as I remember, a buffer "read" (e.g. into a variable = store the message buffer content) clears the message buffer. Then evaluate/manipulate the variable (again as in Philo's program, e.g. scale the value) and then do the action using/based on the variable but not the message buffer content. Best, Thorsten

No idea what the robot inventor app does - as I don't have it. However, I believe, for sure, that no overload protection kicks in here. It pretty much sounds like you are setting power (i.e. PWM duty cycle) and not speed (with whatever control loop implemented on the robot inventor system). On the City and Technic hubs, 5% is really working fine with a PUp L motor. I don't have a PUp XL motor - but the control loop is for sure the same as for the L motor. When I try to stop the PUp L motor set to 5% speed, man, it freaks out. Needs some time (< 1s, so it is probably more P or PI rather than sharp PID) but it eventually freaks out, trying to maintain that 5% speed. Yes, that is the issue. Using an ESP32/Legoino client, 5% is no problem. As said, there is some notable time lag, but that's it. That needs to be considered, for sure, but PWM is far less prone to such "failure", as reported by @SNIPE. Best, Thorsten

I believe this really needs some experience, though. As I am also wandering the Dark Side of bricks, they have numbers on them - almost not discernible from LEGO bricks and pieces. The only thing that helps me is the missing LEGO print. With old pieces, i.e., before the Dark Side came into play (I am old), when they redo them, I could not tell the difference. Best, Thorsten