Toastie

@Andman and @Hod Carrier, hooked up the Technic (4I/O) hub. Temporary access of PUp app to "location" on the phone was enabled: No motor operation (although it does connect and runs the program ... ) . >> Global activation of access to "location" on the phone: Boom - works. Should have known better, as this was mentioned elsewhere, and repeatedly. Result: SetPower runs >flawlessly<, as you said @Andman, on the Technic (4I/O) hub. Loop count now reaches 2500 - and I guess that is it: Works! Back to the City (2I/O) hub: Exactly the same behavior as described in my previous posts: Crash (= no response and disconnect) after (almost) arbitrary #loops. Conclusion: Bug in City hub's firmware. I cannot think of anything else ... Best Thorsten

Just to be sure and I know how that sounds, but you are using the SetPower block, not the SetSpeed one, right? Best Thorsten

No, these problems are buried somewhere else ... it is definitely not the IOs vs Android system!

OK, there is another Technic hub here. Swapped batteries: This one does the LED color play and seems to load a new firmware. Done, connect to PUp app, all is good, no motor response. So all this is caused by my phone??? Running Android version 11, security update on April 1st, 2021 - well that may explain it: April 1st ... But honestly: Holy crap I did not know how bad things have become ... Best, Thorsten

No chance, the app tells me "wrong connections", regardless of what model I am selecting. Updates usually come upon connecting hub and app - with that colorful LED play. Nothing here. Conclusion: Firmware is up-to date, or Moto g8 sucks, right? @Hod Carrier: What device are you using?

Wait, will call up that one ...

How do you tell, and how do I update? Man, this is so cool - it says a lot ...

That would be nice!!! @Hod Carrier: This is fun!!!

Well, my thought. The thing is, I can't get 88012 to run the motor with my program. It connects, and then runs the program without any glitch (counting to "insane" numbers), but does not turn on the PUp L motor. Do you have the motor attached? Best Thorsten EDIT: Sh*t questions asked, no reply: I am using a Motorola Moto g8 power with Android 11 and PUp App - wait - 3.6.0. And I have the Spider App 1.0 running on the screen, as I dropped the damned thing two days ago - onto a concrete floor

No, if it really turns out to be true (others need to verify that as well - as of now, there are two of us ;)) it is the other way around: Thank you very, very much!!! The most valuable input for any developer is sound and reliable error reporting. And the more input we supply, the better the response may be. >IF< anyone "responsible" reads this thread ... and cares ... [I had remotely comparable experiences with other - custom - firmware: Dave Baum changed the NQC firmware code, because I was asking for the possibility of introducing short jumps. This has nothing to do with the issue here, but with "how to develop" firmware. He did, and I was super happy. It meant that a SCOUT could do much more, as it has only about 400 byte code memory capacity - and a long jump crunches 6 byte codes, a short 3. Yes, I am old school - memory was most of the time I was coding - an issue. It is not anymore. Here, we are facing a completely different issue: The firmware becomes unstable upon using the SetPower command. And it looks like: Always. That is a big issue ...] I can only confirm that: Regardless of what you do: Repeatedly calling the SetPower command >always< leads to a crash. And that is bad. OK, here we go, I am citing from my favorite movie: "I'm fuzzy in all good-bad things. What do you mean, 'bad'? Try to imagine, all life as you know is stoppin' instantaneously and every molecule in your body exploding at the speed of light. Total protonic reversal. That's bad. Ok. A' important safety tip. Thanks Egon." OK. It is not that bad. But bad. Thank you very much for bringing this issue up! All the best Thorsten

OK, here's a little update; I'll stop it here, because I believe that @Hod Carrier has really found a nasty bug in the City hub's (2IO) firmware, regarding the SetPower command. Will try the 4IO hub later (whatever its name is - Technic hub or Control+ hub ...) PUp program used (note that always the same power setting is used): PUp interface used to count loops until crash: Left button: Start program, right meter: #loops Data recorded: Data interpretation: Yes, there >seems< to be an issue with BLE traffic, when going from 0 to 2 seconds delay time, performance improves running time wise, but that is actually "fake" as the #loops to crash are more or less erratically distributed, and I believe when averaging more, the #loops to crash may actually level out. However, when using 5s delay, a very low number of loops is enough to crash the system; this would mean that the firmware may get confused by simply doing the PID job ... Conclusion: Either dumb PUp program I used - or really nasty bug in firmware. The latter sounds more reasonable - but who knows. This also explains to me, why I am having a rather hard time in getting stable operation with multiple trains using this command. And I thought it was VB 6 ... Here is to VB6! All the best - and code well Thorsten BTW: When taking a screen-shot on the cell phone (lower sound + on/off button for some Android phones, as my Moto g8 power) - the PUp app crashes immediately, shows the program page, and disconnects the hub. Initially I was afraid that it would also trigger the hidden self-destruction feature of the LiPo battery in the phone, but that does NOT happen

See above ;) Maybe the 2021 PUp world is not that far away from the 2000 VB6 world with an up-to date BLE OCX control ... And for trains: See also above event_handler(new_slider_value): Wait 0.1 s: new_slider_value = old_slider_value? No: loop. Yes: old_slider_value = new_slider_value: Call (SetPower(new_slider_value)) More importantly: Others need to confirm these observations; these are my very first PoweredUp "programs"!!! EDIT: It appears as if the time-to-crash (TTC :)) correlates with the wait time - which in turn >may< correlate with the number of calls to SetPower on the hub??? No idea! Here's the super code:

I did not know, that I can multitask that well 1s delay: Crash (the set power block is permanently high-lighted) 2s delay: Works: The power block is flashing nicely and constantly every 2 s. Best Thorsten

Yes that. (I am right in the middle of a video conference which requires some attention (cool research results, I must say!!!) What should help as well is changing the Speed only, when (new != old) - this will be often the case for trains - folks usually enjoy seeing them run at constant speed, because that implies: Insane torque ;) Best Thorsten Yes, in contrast to SetPower, which has much less overhead, I believe. And on another thought: The ramp_up/down-time data + final speed value (in addition to the PID control routine, which is bolted into the firmware on the hub) is usually is a fire-and-forget piece of code, client-wise (i.e. on the phone): submit ramp times (which can even further expanded to power restrictions, according to the LWP3.0 protocol) once; submit final speed once and then leave the remote server alone and let it do what you were asking for. It then takes care of things - until you want to change speed again. When using a slider/dial to set the speed setting on my VB6 program, I am using a delay-time to finally read the terminal speed value I am selecting. Otherwise, the slider control fires change_value events as often as the slider value (1 - 100) changes (duh ...) upon sliding - which then calls the BLE stack to issue the SetPower command as often, which in turn crashes the program (OK, it is VB6 ...) immediately.

Is it conceivable that the loop, in which the set speed command is embedded, is adversely affecting the program? You need to create such a loop for sure to react to changes in the speed setting, but the code behind these blocks is rapidly cycling through this loop, even when there are no changes in the speed value, right? My question to the gurus here is: Is the SetSpeed command executed each time the loop is encountered - or is it executed only when the speed value actually changes? The latter could also be done in code, should the SetSpeed command behave badly when simly called too often. After all, the PID parameters have to be reset etc. I have a very simple program here that consists only of Start, define ramp_up_time, define ramp_down_time and then: loop{SetSpeed to constant value}. From the flickering of the block during execution, it appears as if the command is invoked (with constant speed value) each time the loop is executed. The program then does exactly what @Hod Carrier is reporting: It runs for a while, then stops and disconnects from the hub. When I do this: Start, define ramp_up_time, define ramp_down_time, SetSpeed to constant value (called only once), and then loop{forever} - the program does not crash. Big difference with the set power command, as this can be called as often as you want - it just sets the PWM ratio. With PID control though, things may go bad when called too often. As judged from what I learned when I coded PID into the RCX, that is. Things here may be very different! Best Thorsten P.S.: I just noticed that when the SetSpeed command is directly in the loop (i.e. executed every loop), it flickers initially, then stops doing that (motor still runs) then after a couple of seconds stops and disconnects from the hub.

@SylvainLS: Ahhh - thank you very much for your explanations! Yes, I can switch between CPU and GPU. It was on GPU so I'll test relative speed later. Thanks again! Best Thorsten

I have no clue what you guys are talking about - but just clicked on "nvidia settings", which tells me that I have a "Quadro P1000" thing on this Dell laptop (7530). I simply don't know what the green side is, but it sounds to me as it would be favorable to be there when using Stud.io just for rendering (which I do; building in MLCad, loading into Stud.io for rendering). This laptop turns rather loud fans after a few moments - but I can still work on papers and so on without delay. Is this the "green side"? Thanks for your help! Best Thorsten

For motors, and partly for sensors (because they are usually located at - well - "restricted" areas, where boldness sucks) I can see that. However, when it comes to lighting, a 6 wire PUp LED or the like is very often - well - counterproductive. I can see the LEGO approach of making it a) less experienced proof and b) for hundreds if not thousands of rebuilt structures, cars, trains, etc. However, when wanting to light up a modular or any other semi-permanent model or MOC, all that finicky may be well suited. Hiding such wires is much easier than any of the LEGO wires I am aware of, maybe except for 9V wires (partly, as they were available in meters length). It all depends, I guess. I for myself use custom wires, as "tiny" and fragile as possible, just allowing to flow current with acceptable voltage drop to remote LEDs. To light up structures and track side. Which are kind of static here ;) Which translates to ever decreasing space ... not the LEGO idea, but mine Best Thorsten

@Hod Carrier - first of all: No need to apologize! You had a question, which raises more questions - that's the fun of it! What @Andman said makes really sense - it came to my mind when I was walking the dog this morning :). I could be that you branch off into a dead end, which then terminates the program ... could be. We'll see. Very interesting issue! Best Thorsten Very good idea - however, shouldn't these two threads not be here, in the Mindstorms and Robotics forum? Just asking. Best Thorsten

Shoot! Then some TLG officials will go down the drain swiftly ... Saturn V, the Eagle, the flag. Totally illegal. Grobschnitt, a German band (of high school students) back in the days, ;) had this one on one of their records: "Ist das erlaubt? Ist das erlaubt? Ich glaub ich hab die Lampe an ..." I'll never get this illegal thing ... TLG themselves used exactly the same technique all over the place - back them though. When ABS was strong enough to cope with it ;) Best Thorsten

Wrong. Totally the other way around: Your Fourwides are awesome, they really are! Very nice work. All the best Thorsten Really nice - I have no clue - zero - how you guys do it. Man, it looks like the original - with that limited size and part list. Thank you very much for sharing! All the best Thorsten

@Hod Carrier I believe the app gurus here would like to glance over your program as it seems to be a more serious thing as the app essentially crashes, right? It initially responds correctly and then it doesn't respond anymore, and then it looses connection. May there be a hidden endless loop or the like? When you don't press anything, but just wait for a while and then press the button, this works, right? Also, when you press the button once and then you don't press anything anymore, does it still disconnect? Best Thorsten

True, is has that because of the PUp L motor. But the thing is that with PID control you would compensate for the low torque in the train motor - if it had a rotation sensor. Or if there were a PUp rotation sensor. With 4+ XL motors on a decent train, there is no real need for PID control. They "just do it" by using their muscles = torque at low speed (and "high" speed, where high is limited ...). Best Thorsten

That is very true. And it will be even more challenging for TLG, when they go further into electronics. Best Thorsten

You don't need a time machine for that: Just look into a mirror - and smack yourself better use the time machine to tell yourself not to use that "rubber". Other than that: Yes you are right! Best Thorsten