Toastie

Well, I believe there are multiple quality assurance issues, when going that route (which appears to be >very< expensive) ... ... and ... I believe volume wise, the 2nd hand market is more or less negligible - as compared to cranking out new sets, delivered all over the world. Best Thorsten

Wow! Congratulations @Hod Carrier! From the loco, the drive train, to the software solution: Simply brilliant! I love to see ingenious hardware solutions combined with smart electronics/software - and all completely in true LEGO space! Seeing an engine or a whole train moving that slowly and without stuttering ... wonderful. [Just as information: In the "other thread" dealing with the buggy SetSpeed command you found on the City hub in conjunction with smart motors, things are clearing up as well] Thank you very much for your time writing this up so nicely and sharing all the information! Best regards, Thorsten

Oh man, don't feel sorry! The whole PUp thing - without any real technical documentation at hand - is so confusing to me, that the level of my confusion was completely unaffected by your comment! In contrast, your comment cleared-up things rather quickly. To overcome chaos, one simply needs bold actions. And then watch the outcome. "Yes" and "No" are usually good bold actions, regardless of being true or false. And it worked again! So thank you and all here for clearing this mess up in a swift and to the point approach! All the best, have a nice day Thorsten

Yeah, I posted it here as well some time ago. It also shows the way they encode the rotation data.

And now what?

@Lok24 I edited your list. @kbalage Is this what it is? I still don't understand what a "software encoder" is. This means there is no rotation measurement hardware within the motor, or is there? If there was, I begin to understand ;)

@kbalage, ahh - it all begins to make sense: PUp motors without HW rotation encoding: No problem; they do (correctly) not respond to the SetSpeed command, but (correctly) to the SetPower command These are: The linear motor (45303), the train motor (88011) - is that it? I am asking, because all other motors, including those in the MoveHub, are described on the LEGO website as "precise position motors" PUp motors with HW rotation encoding (all others): Problem with SetPower command on City hub. Move hub (is that boost?): Internal motors = working with SetPower, external motors as in 1) + 2)? Technic hub: No problems at all. Is this summing it up correctly? Best Thorsten

@Hod Carrier, @Lok24, @kbalage, sorry for bringing this up again: I have hooked up a PUp train motor to the City hub and updated the info in the bulleted list above: The train motor does not crash the program upon using SetSpeed: It does not react, but the program loops forever; replacing it with the SetPower command on the fly works as expected; using both commands in the same code loop works as well - it appears as if the SetSpeed command is simply not executed; SetPower is. Best Thorsten

Just "talked" to @Hod Carrier in private: I believe that we need to include the PUp train motor here as well. Because this is what he is using in his setup - I believe I have one PUp train motor somewhere without cut PUp connector and if, will test. Also, @Lok24 may have used a PUp train motor in his tests as well, is this correct? That means that all hardware rotation sensor equipped PUp motors hooked up to the City hub do crash a program using the SetSpeed command repeatedly, the train motor hooked up to the City hub does that as well, the train motor does not crash the program; it does not do anything; the loop runs forever the linear PUp motor does not, the internal Boost motors do not. Is that summing it up correctly? Because devs need to know as many details as possible (as far as I can tell from troubleshooting a modern mass spec ;)) A question I have: What is a "software" tacho/rotation sensor? Does it assume 0 = stop and full speed = 100? (or whatever scaling factor is used?). Such a thing is not built into the motor, right? It is a piece of software in the hub, correct? If so: Why does the train motor crash the program? That one is for sure dumb as brick. But when Hub software is doing the work, then I don't get, why there is a difference in behavior between the PUp linear motor and the PUp train motor. Oh well - the world is becoming increasingly complex , beer always helps. Best Thorsten

How about some more life? Trees (hard to do, I know), bushes, flowers? Colors? Best Thorsten

Yes, exactly. Well, it could be that when the code crashes ("program irregularly terminates" with exit code "bad"), then there is some watchdog that realizes bad things happened (or a simple time-out) and simply shuts off the BLE connection. Best Thorsten

@kbalage, thanks a million! I am sure that @Hod Carrier is also "happy" that his code was not the cause of this behavior! It is exactly what he and I observed independently. Well, I think this bug is not that "special": With the City hub, >none< of the motors work with the SetSpeed command: Either it is a linear or a train motor w/o tacho, then the code doesn't even run the motors (which is fine, as it should be like this) - or it crashes. I also believe that the SetSpeed command is rather powerful ;) In many regards. Surely for trains, maybe for GBCs with critical timing, etc. etc. With a tacho equipped motor, I would not use the SetPower command at all, but rather set speed. But that is my taste only. Best regards and thank you very, very much again! Thorsten P.S.: I believe your channels are much more efficient.

Oh, absolutely!!! Family first is the common sense here among all "members" ;) - it is the most important thing and then - for long - there is nothing much else! I did not mean to push you, please don't feel that way! There is zero need to rush things. I just wanted to make sure, that this remains on the radar, as it may very well be that >I< am screwing things up - would not be the first time, in contrast - when suspecting something is broken or faulty. Thanks a lot for your reply! Best wishes and have a very nice day. Thorsten

@kbalage, did your config make it persistently all the way through? Because when it did, it means the behavior @Hod Carrier and I were noticing, it is either our phones, or the L-motor, or the City hub. I believe it is worthwhile to follow up on this, right? Best regards, Thorsten

This is really excellent work!!! And with regard to the bump: I read once here from a >moderator<: "I have created this thread, so I can necro-bump it". It makes total sense, regardless how old the thread: Improvement means progress and that should never be an issue, bumping wise. Best Thorsten

@keymaker and @HectorMB, thank you very much for your thoughtful replies! It is a very difficult matter. Best Thorsten

Phew, really cool. I had no clue what is possible ... And TLG pulled the plug on the Osprey because of ... well ... whatever. We are not allowed to show "clone bricks" on EB other than in the Community Forum, but we are allowed to show how to play Counter Strike within a LEGO environment in the Digital Designer Forum? Counter Strike? Wow. I have nothing against that, those who what to go there, please feel free go there. But I really have problems with how EB is treating "clone" bricks. I do see fully incompatible measures here. When clone bricks are soo bad for TLG's reputation or appreciation of this forum, so is Counter Strike, isn't it? Oh well. Cool though, what is possible, and what you have accomplished for sure. It must have been a load of work and knowledge! All the best Thorsten

I believe no. It is what it is: Things in the public domain will be the "prey" of others. And things in the public domain are even no "prey" at all; they are - in the public domain. >Legally< available to everyone. I know: There will be comments on this. Sure. But folks, please take into consideration: "They" are far, far away, in a galaxy ... What amount of money do you want to spend to fight it through? How much time do you have to spare to do all that? We can restart the whole thing again: Ethics, rules, IP, behavior, appreciation, legal stuff. Please don't. In the world we are living in today, with so many "companies" around - forget for a moment China - just >so many companies knowing to do top level injection molding< - and all wanting to make money - in what we call the "free market": DON'T put things you don't want to see treated in this way into the public domain. It was like that in the past, back then, pre-internet. It is now: >With< superfast, diverse distribution channels. The moment you post in a - let's say - a LEGO forum, the moment the interested world knows. And only some of these interested folks are believing in ... "private intellectual property" or ethics; they want to make money. And mostly don't care about legal stuff. Over and out. How about that: Either keep it to yourself, maybe build IP, try to do it on your own - there are ways to do it. Your take: I don't want to waste my MOC using unacceptable quality bricks is fine. Don't go the unacceptable route, that is my advice. "They" do increasingly well - if not par. Sorry to say, but The Myth is currently vaporizing. And how about that: Either go with them (make money) - or enjoy the appreciation (just that, be proud) that they selected your very model. It is up to you. With very best regards Thorsten

No. We forget. As simple as that.

Does that only apply to folks who have managed to get invited to Billund by TLG, hired by TLG or would you possibly also accept a document that says: "I tried to the best of my knowledge" or something, signed by me? Have a nice weekend! Thorsten

This. I was waiting for you, Ole, to chime in here; you as native Danish, as you (and others of course here) know much better than I. But now that you just wrote, I'd like to back up that a bit: I was born in Northern Germany and lived for 20 years in Jübek, which is about 30 km away (by bicycle) from the Danish border, then moved >way too far south< to Kiel for further 18 years, which is about 60 km away from the Danish border ;) well and then elsewhere, which >really< hurt(s). I for my part could never tell the difference when crossing the border - other than that people are even more relaxed as they are in Northern Germany and extremely friendly. For more than 45 years - no kidding - we spend at least one week of vacation on the island Fanoe - which is about 60 km away from Billund. Have been to Billund multiple times (guess why). I know that many of you do not share the same feelings, but I have to admit that I regard Denmark as one of the most beautiful countries in the world. Green + flat = life + space + biking = perfect. Particularly with regard to the people living there. And when you have seen or even been to a Danish school - regardless of level, either the elementary school on Fanoe in Nordby or the high school in Schleswig, Germany, (which is a Danish school, as I said, generally not that much of a difference up there), you know where your taxes are going. Building and infrastructure wise and quality of teaching wise (e.g., ratio between #stundents/pupils and #teachers). Or when you look into the Danish medical insurance system and healthcare coverage and quality: One of the best in the world. Go to a public library or any other public building with public service: You'll be served - top notch. How do I know? Been there, part of the family visited the Danish school system (in Germany), some of my former high-school friends do work there. All I am hearing is: It is not only worth the taxes - there is so much more, usually expressed as superb quality of life. BTW no one of them wants to get back to Germany. I can clearly see that - no surprise at all. Best Thorsten

Well this is not at all related to how TLG is hiring, but I do see at least similar patterns here: I am on a number of hiring committees at my university each year in response to advertised openings ranging from professor (assistant to full) as well as permanent staff (technical and administrative) positions. Again, this is certainly not reaching the level of what TLG is doing but at least getting close for recruiting at the full professor level - in Germany the department has to live with that person for about 25 - 35+ years, as you can't fire them - SOE is built into the package. So the person better fits or there could be fights for that amount of time One aspect is always: Does a person meet the (all) criteria in the catalog, the committee has assembled before inviting folks? But equally important is to have "diverse" people in the process. Just being good is one thing, meeting all criteria is another, but then comes the "chemistry". And that works only in person. For me the most important thing. In regard to the hiring process of TLG: I can readily see that industrial designers are better suited for this task than AFOL#1. They study, practice, and learn how to work with compromises, limitations, and integration of technical things and design. We have such a curriculum here at the university and I must say: Impressive. They had 5 3D printers years before we had and so and so on. However, I can clearly also see that when AFOL#2 is showing similar or even better skills in the in-person interviews and talks, she or he will get the job! If I were TLG ;) I would do in exactly the way @Sariel has described. Maybe even more diverse, not only limited to industrial designers. Best Thorsten

And that certainly does include you. Should this turn out to be a bug, you found it, you reported it (after I bet numerous - as in very, very many - test runs). And as said before: These are the most valuable reports to a) the community, so others don't rip out their hair because they think it is them - this is usually my approach and usually true: Almost every time such things happen, >I< screwed up ... and b) to developers. And they need even more input - could be my phone, maybe yours, maybe two faulty hubs (sh*t does happen ...) - who knows! I do hope others will run the tiny test program as well, and then we'll see. More importantly: Yes, your updated program is a nice approach to resolve the issue for the time being! I also believe it will work quite well, when the load is not becoming too excessive, as the L-motor does develop quite some torque (when you don't gear it up). I believe what you coded is a "proportional" (P) control loop. I may be wrong though, others here know much better. Under high load, i.e., when the torque of the motor cannot easily compensate for the sum of changes of forces pointing in the reverse direction of movement, it may come to oscillations. But that is fun to see as well, as it tells you that your program is trying very hard to do what you want it to do! I have no clue, but maybe you can add the "integral" (I) and maybe even "differential" (D) corrections using the PUp code; then you have full PID control. However, as said: Most probably not required at all, and P will do! [As a note: As it stands, you are polling both rotation sensors - on a train equipped with two motors, the readings should be (within margins of error) identical, right? I believe you could save program run-time overhead by reading just one sensor and then adjusting the power to both motors in the same loop?] It will be very, very interesting to see your results! I sure hope you find time to share these results here! All the best and have a nice day, Thorsten

I am running the code on a Motorola moto g8 power Android 11 phone, latest PUp app installed (3.6.0), City hub, and as far as I can tell the latest City hub firmware installed (it does not do the LED color play when connecting to it). Only one PUp L motor is hooked up to the hub on port A. The code runs fine for almost arbitrary #loops (note: Sometimes < 5 loops, sometimes >180 loops), I simply copy here very simple measurement results from above, sorry for that: This was done with this code: Code runs fine on Technic hub. (Same phone, same app, Technic hub with the latest firmware installed (it did the color play yesterday upon testing), same PUp L motor attached to port A. Best Thorsten

I don't have the faintest idea. Maybe @kbalage or @Lok24 would know? It would also be favorable if others confirm that erroneous behavior of the City hub, when using the SetPower command repeatedly. Code to crash the City (2I/O) hub without wasting much time: Best Thorsten