Andman

Correct. The loop runs constantly since there is no condition set, which could start or stop the loop. Actually no. The loop is only receiving and does/should not interfere with the rest of the code. I think that could possibly reduce battery drain, since the loop would not run constantly. But I don't know how much energy it consumes. I have similar code and my phone battery is drain quite fast. But ion the other hand i have 4 technic hubs connected. Could be worth testing.But that's something for another thread.

On my end the code for widget button 1 is often buggy. It often adds up 10 only one time. Some times, after bulding that code structure it works and adds 10 after each click on the button. That's the first issues i experienced. Can you exclude that code suffers from that issues?

My earlier comment about local and global variables is obsolete. Had a wrong understanding.

First I see is that you are always using local variables. That means they only exists inside each code block. Other code blocks cannot "see" them. Have you tried to use global variables? Nevermind, i re-read the definition for local and global variables again. What i wrote before does not apply here. In the meantime I'll clone you code on my end and will test things. Could you please also share a screenshot of the controller layout in edit mode so we can see the widget numbers. Make sure the resolution is good enough. Some things on the screenshots above are hardly visible.

First i would like to promote these two threads: I would recommend the first thread for help requests. The second is more intended to collect working code. Regarding the issue you are facing: We can help you best, if you post a screenshot of at least the code in question (if you don't want to publish the whole code for whatever reason). From what i have read, it seems that you are missing a loop. But that's hard to say, until you post a screenshot. If you don't know how to post one then let us know.

How does it behave under load? I would be afraid, that the mechanism where you change the function can not handle load.

Oh right, and i was the last one who posted. Totally forgot about this thread. But then we already have a place to discuss. This thread then can be used to only publish working code and possibly optimized code. But back to topic. Here is another code which I'm going to use for my Steinwinter 2040. TL;DR Automatic turn lights Description: This code turns PF LEDs into automatic turn lights based on in which direction the wheel are steered. Code: Video Declaration of variables: a - controls steering angle, is set by the slider 0 b - sets the port used on the PF receiver (right and left turn light) Detailed walk-through: In the upper row are two Blocks. The right one controls the steering via the variable a and the slider on the left block. Note that the green block contains a multiplier. @allanp pointed it out in this post. Without the multiplier, the steering motor is constantly under load because it tries to steer further then possible. In my case 0.64 worked best. Tweak that value so it fits your needs. The turquoise block constantly updates steering position in the widget. The lower row contains the logic. In one (or maybe more) sentence: IF the steering position IS GREATER THAN 0 OR IF the steering position IS LOWER THAN 0, THEN continue the logic. IF a IS GREATER THAN 0 THEN set b to channel left (4), ELSE set b to channel right(5). The next purple block is setting the send mode (7) for the Boost Color and distance sensor. The sensor is connected to port D on the hub. After that next purple blocks will turn the light on and off with some delay. In my case half a second.

But we do not know how old the catalogue is. May that what we see was again just another sketch from some time ago.

How big are the chances that we are still not looking at the final model?

Oh my god! I almost forgot about that set. When i was young, i was looking at this set in catalogue for hours. I wanted it so bad. I'm really keen on seen this studless.

I'm missing a place where Powered Up code can be gathered and explained so other guys can reuse it or find inspiration. I had a discussion with @Jim how that could work out in this forum. I was thinking about having something like the hall of fame for code which underwent optimizations in a dedicated thread and which was proven to work. But this might lead to several thread which are prone to be inactive. So we decided to start with a single thread to publish PU code and discuss it. If it gets to chaotic We could have two separate thread. One for discussion and help request and the other one for working and optimized code. To keep things orderly, a general structure might be helpful. So here we start with my proposal. TL;DR: Automatic brake lights based on speed reduction Description: The following code switches brakes lights on in case the speed is reduced. That works for reducing speed while driving forward and backward. When the speed reaches 0, the light are turned off. In this code I'm using PF lights controlled by the Boost color and distance sensor. But that can be replaced with PU lights. Code: Video Declaration of variables: a - Used to control the speed, is set by the slider 0 b - Speed (a) at the first point in time c - Speed (a) at the second point in time d - Speed difference between b and c Detailed walkthrough: The code block consists of three rows. The first row consists of a loop (left) and the code block to control the speed of the motor (right). Most of the code blocks in the loop are not needed. You actually just need the first block which sets constantly a value for the variable a to control the speed. The rest are widgets for testing timings. The second row is the logic to detect speed differences. To do that constantly, a loop is used again. It simply reads a, the speed at different times. You can adjust the time between the measurments according to your needs. In my case 0,08s worked well. At the end of the loop the difference is set to the variable d. The value can be something between 100 and -100. The third loop at the bottom contains the logic to turn the brake lights on or off. You will also notice the purple blocks. They are used to control the PF lights. I'll come to that in a bit. First i want to explain the logic to turn the lights off an on. There are three scenarios: Driving forwards Driving backwards Parking When you are driving forward the max value of a is 100. Lets say the speed is suddenly reduced to 50. The difference is 50. When you are driving backwards the max value for a is -100. The speed is again reduced by 50. The difference is -50. When you are parking the difference is of course 0, because it doesn't change. So i have two condition i want to check for: Am I driving backwards or forwards? Is there a speed difference? I can exclude the third check, parking, by checking values for a that are greater or smaller than 0. So, in one sentence: IF there is a speed difference AND the speed is GREATER THAN 0 OR IF there is a speed difference AND the speed is SMALLER THAN 0 then turn on the light (upper purple block at the end). But how to control PF lights with Powered UP??? That is covered for example by @kbalage here. The first purple code block on the left sets the port and the correct mode for the boost sensor. The two purple code blocks on the right side control the brightness of the PF lights. D is the port where the sensor is connected to, 3 is the channel 4 on the PF IR receiver, 5 is the red or blue port on the IR receiver, 7 switches the light to max brightness, 8 turns it off.

Thanks for sharing and the detailed description! no need to apologize for the background or the photo quality.

Awseome model! I like it a lot!

Well done! I like it! Would you mind to also publish your Powered Up code?

The problem with buying old sets now is that you do not know, if they still have their original parts.

:-D I didn't read that it is powered by a buwizz. That's a game changer. There is only one solution! @A_C, please make a video and show how fast it can go!

You are referring to the non-loaded characteristics, which is described here: I was referring to the loaded characteristics. 5292 Torque Rotation speed Current Mechanical power Electrical power Efficiency 4.5 V 5.7 N.cm 150 rpm 1.36 A 0.87 W 6.12 W 14 % 6 V 5.7 N.cm 380 rpm 1.38 A 2.27 W 8.28 W 27 % 7.5 V 5.7 N.cm 580 rpm 1.37 A 3.45 W 10.3 W 34 % 9 V 5.7 N.cm 780 rpm 1.40 A 4.61 W 12.6 W 37 % 10.5 V 5.7 N.cm 1030 rpm 1.46A 6.16 W 15.3 W 40 % I'm again tempted to say that the values from table of loaded characteristics are closer to the real life conditions for this moc than the non-loaded characteristics of that motor. Your turn :-)

It's feature, not a bug! I'm tempted to disagree. Looks like the slower output is used, thus 780rpm @9V (According to Philos homepage). That's nearly 6km/h... in theory. But i might be wrong.

Well done!

From what i can see it could/should be a 1,4:1 gearing. Could reach 2,5 to 4km/h. Not sure about the torque.

I'm willing to help! Just send me the images

The google search trained me to never click on the second page. I'm on a level were it cause physical pain to even hover with the cursor over the number two.

While I'm waiting for some parts, i made a first concept for the body. The parts are actually white. I just had to lower the brightness, because it was all white and not possible to see the different parts. The doors on both sides give access to the hubs to turn them on. Anybody aware of extension cables for PU devices, which have a reasonable price? I'm aware of these, but they are quite expensive.

What defines or qualifies a MOC for SMF? The amount of system parts used? The look, means does it look like technic or lego system? But anyway, IMHO merging both forum is a good idea.

Is there an up-to-date overview available of which device is compatible with which hub?