Lego Action

As a child I didn't have Lego in my toy box. I started using Lego just prior to 2000, using 2x4 bricks and roof tiles to build ramps and walls. Within the last 7 years I have expanded my Lego usage to include a variety of sets and elements. My favorite themes include: Classic (assorted parts), City, Technic, and Friends. While I like many of the Lego sets, I often either build modified versions of them or just use the parts to build something different.

Building a Lego model that sits on the table looking pretty is a good thing. But adding motion, lights, and sounds to it takes it to a higher level of fun and realism. I call this "Lego Action" and will refer to that using "LA" for this page.

Lego themes for LA

Lego has given us some great tools to help with LA. Modern tools are mostly controlled by an 'application' (called "app" in this document) which is run on a 'smart device' (tablet or phone) which meets certain operational requirements (such as Bluetooth and Location ability). Here is a brief list of Lego themes offering LA ability:

I am going to quickly cover the basics of each system so you get an idea of what it does best. There are many sites which already cover more detail about each system so I won't repeat the specifications here. This article is based upon MY PERSONAL EXPERIENCE and some information which Lego has. Different setups often produce different results so some things may work a bit different for you.

It is worth noting though that no matter which system is used to add action, you can still use any Lego elements to build the model. Most mounting in the modern systems is via 'Technic' connections, but there are many elements which convert those to stud (classic) style mounting. Model design will need to take into consideration the size of the hub/devices used as well as the wiring path between them. The hubs (any non Power Functions systems) have the battery compartment within, so there is no additional battery pack. However, since the batteries are in the hub, model design should allow easy access to the battery panel for changing batteries.

In the same respect, existing models built using the old 'Power Functions' system can be modified to use the newer 'Boost' or 'Powered Up' systems. The amount of modification depends on the size and mounting differences between the old and new devices. The 'Boost' Move Hub is the largest of the hubs, so it needs more room in a model. In contrast the 2-port 'Powered Up' hub is similar in size to the small 'Power Functions' battery packs, so it should fit well AND it doesn't require the IR receiver so extra room is gained there.

Mindstorm

To be honest I have never investigated the Lego Mindstorm system. So this section is short only because I know almost nothing about it.

Mindstorms was mostly an educational tool, not truly a 'toy' in that respect. Some people use Mindstorm devices to add LA to their own models, but it is still used more commonly for education in schools and FLL (First Lego League) competitions.

There are 4 generations of Lego Mindstorms:
Robotics Invention System (1998)
Mindstorms NXT (2006)
Mindstorms EV3 (2013)
The WeDo system branched from Mindstorms

The earliest of these systems devices were actually 'tethered' to a computer (wires connected the computer and the model). Then "intelligent bricks" were developed with processors in the devices themselves to allow for portability. This was the foundation for the systems being introduced in todays modern times.

Power Functions

The Lego "Power Functions" (PF) system was launched in 2007. Although it is no longer available from Lego, devices can still be purchased from people selling theirs. Unlike the Mindstorm system, PF has no computer relations. It is a basic system of motors and lights attached to a battery box and controlled by a handheld IR remote and an IR receiver. Because of the simple to use nature and a fairly compact design, it was easy to add to a model. Rechargeable battery boxes exist to reduce battery costs/disposal, but several varieties of normal battery packs also exist.

The remote/receiver has two device ports, red or blue. There are 4 channels available so that up to 4 different red/blue port pairs could be controlled with one remote. Devices could be mixed as desired, two motors, two lights, or one of each. The speed of a motor or intensity of a light could be controlled with the remote.

PF uses 'stackable' connectors, meaning more than one device could be attached to a red or blue port. However, all devices on a port would have the same behavior as the others (speed or intensity). This made it possible to chain many lights to just one port.

The PF system is great for remote control of trains, vehicles, or any simple LA expansion of a model. The biggest drawback is that only 2 ports (red/blue) exist on each channel. So if two motors are used (1 for speed and 1 for steering), adding lights is not possible. PF is ideal for trains since they have no need for steering.

With PF, there are no apps to install and no 'screen time' required. So although coding is not an option, the features needed to operate simple models is all done with a simple handheld remote control!

Boost

The Lego "Boost" system came out in 2017 and is still fairly well supported today. It features a 'Move Hub' with 2 internal motors and a tilt sensor, an external motor, and a color/distance sensor. Boost models were built around the Move Hub and showcased the abilities of the hub and some clever building techniques. Boost models are controllable ONLY by coding via the Boost App, not remote control. The Hub connects with the app via Bluetooth, so it may not be available for older computer devices. Boost is NOT compatible with Power Functions devices.

The system has several models that can be built with parts in the set. The instructions lead the builder through steps to construct the models AND teach coding along the way. Each time a model segment is built, the focus turns to how to program it in the app. This helps the builder to understand the relationship to the model segment and the code blocks available to give it action. While the included models may yield a lot of fun themselves, the app includes an 'open code' area. Custom code can be created using any of the defined code blocks available.

The Move Hub also has a status light. This indicates power and Bluetooth connection status. It is also possible to change the light using code blocks. The app has a sound clip library which can be accessed with code blocks and it is also possible to record custom sounds. All sounds are played on the device which runs the Boost App. The light and sound ability add more possibility for LA in a model.

Although Boost is an expensive set, it offers a lot of models and the ability to expand into custom models. I was impressed by the way coding is taught during construction and found it to be a very productive teaching method. The visual coding manner can be enjoyable for those who can grasp basic logic and functional processes.

The Boost hub and coding system allows custom models to be created and controlled with a great deal of flexibility. The 2 internal motors allow for motion without having to use external wired motors. The color/distance sensor opens up a lot of options for detection of objects and movement. The timing and logical code blocks give the ability to synchronize or delay activity. All of this and more gives a large amount of control to how a model can be put into motion.

The biggest drawback to Boost is that battery access requires opening a large panel at the bottom of the Move Hub. So if any of this area is covered by your model, it has to be taken apart to change batteries. I would have loved it more if Lego had included a method for adapter to simply plug in to recharge rechargeable batteries, that would have made the battery panel space more usable also.

Powered Up

In 2018, Lego launched their "Powered Up" (PU) system. This is basically a combination of Power Functions devices and Boost style Bluetooth/App coding control of them. As this is a new system, it is NOT compatible with Power Functions devices and some PU devices may not be compatible with Boost.

The Hub is the foundation of the PU system. This hub is the battery box and the Bluetooth receiver to get commands from the app. Unlike Boost, the hub has no internal motors although it does have an internal tilt sensor. Either hub can accept devices which include motors, lights, and sensors. The motors and lights are similar to their Power Functions cousins in operation but PF devices are not compatible with PU due to the different connectors.

In my limited testing so far, the Powered Up app seems to be able to allow open code access to control the 2-port hub, 4-port hub, and Boost hub. But only the first hub on the list gets controlled, you can change the device order within the app to switch which hub is currently 'active'.

The PU app is similar to the Boost app in some respect. If you learned coding using Boost, you will be able to transition to PU easily. The PU app has sections for the Lego PU themed models and also an ability to create code for custom models. PU code blocks reflect commands for the PU supported devices and the sound library has different sounds than the Boost app has.

Where Power Functions relied on a remote control to send commands, PU relies on using the app installed on a 'smart device' (tablet, laptop, phone) which meets certain requirements. Bluetooth is used as the communications protocol between the app and the PU hub. When a program is run (invoked) on the app, it sends the commands to the appropriate devices connected to the hub. While this system was really designed to be controlled mainly by the app, it does support creation of code to allow use of the remote control.

The Hubs have several mounting points for Technic connectors. Models can be built around the hub as desired. Remember to keep the area around the battery access panel free so the model doesn't have to be taken apart when changing batteries. The hub status light can be changed using code blocks and programs can make decisions based upon the orientation of the hub according to its 'tilt' position on X/Y/Z planes.

The app also offers code blocks which report the tilt position (X and Y only) of the device running the app. This makes it possible to control actions based upon the device orientation. Thus the device CAN be used as a type of remote control. For example, tilting it forward/backward could add/reduce vehicle speed and tilting it left/right could steer a vehicle in that direction.

Although Power Functions devices are not compatible with the PU system, there is a code block in the Powered Up app which allows the color/distance sensor to send IR signals to a Power Function remote receiver. This is a great concept for 'backwards compatibility' with Power Functions models. This greatly expands the ability to control more models with the same app for those of us who have many Power Functions devices and models.

2-port hub:

The smaller size of the hub allows for smaller models to be created. The hubs lighter weight provides for less impact on the movement of the model. Remote operation allows models to run without using a 'smart device' to run the app, so they can be truly portable but without any sound effects provided by use of the app.

This hub uses the classic 'stud' style mounting. It has no 'Technic' connection ability, except by using elements which can convert to it. This makes some sense though as smaller models tend to be built using classic elements while larger models use more 'Technic' elements.

The biggest drawback of the 2-port hub is that it only has 2 ports, which limits what devices can be attached to it. But considering the use is to simply control vehicle speed and steering, this isn't much of a drawback. So basically if you want a simple vehicle setup that can be controlled by a remote, use the 2-port hub. If you need more, use the 4-port hub.

4-port hub:

Having 4 ports increases the flexibility of uses in models. Vehicles could have 1 motor for speed, 1 motor for steering, 1 set of lights, and 1 sensor for monitoring objects. Thus a full featured vehicle is possible under app control, but not under remote control. Models could make use of two sets of sensor/motor combinations to provide for different movement based upon surrounding conditions.

This hub uses only 'Technic' style mounting. Its heavier weight will need to be supported well in the model framework. Having this hub near the center of the model will allow for more evenly distributed wiring lengths to devices AND detour imbalance due to uneven weight distribution. While having this hub near the bottom/center of the model may help keep battery panel access handy, it may also cause problems in keeping the power button, status light, and ports accessible. Depending on the model, some creative design might need to take place in order to meet these challenges.

Control + app:

In 2019 Lego introduced the "Control +" (C+) app which is part of the Powered Up system. The C+ app is geared more toward vehicle control. It appears that the C+ app only works for those Lego models designated with the C+ theme. In other words, no open coding for custom models.

Notes:

The device compatibility between Boost/PU/C+ varies by device. Each system has a specific app to control the associated devices. I haven't done much inter-system testing to make any useful conclusions yet. My best advice is to check with Lego prior to purchasing a system to determine how compatible it is with any currently owned system you may have. However, I have noticed that as of this writing the Powered Up app at least recognizes multiple devices (Boost hub, 2-port hub, 4-port hub, and remote) are present when powered on. So if the goal is to program custom models, the Powered Up app seems to be the best tool for the job.

Although the coding process seems to be similar between the different systems, I know of no way to transfer a project between different system apps. However, exact or similar code can likely be created manually as desired. Code blocks vary by app and with supported devices so some variation in code may be needed to perform similar functionality. It also seems that sound clips are much different between apps and I know of no way to import/export these between apps. So whatever app is being used determines what sounds are available.

There has been much online discussion about PU/C+ lack of 'stacking' devices like the Power Functions system allowed. However, this is more a limitation of Bluetooth operation rather than poor design by Lego. Power functions connections simply supplied variable power to devices, not specific commands. In contrast, Bluetooth devices are referenced by a 'device address', which is tied to the PORT which they are connected to. This allows precision in sending specific commands to specific devices on specific ports. Thus, multiple devices on one port (aka 'stacking') is not possible for Bluetooth communications.

For many years there has been a market for 'Third party' (non-Lego) devices/apps to provide LA solutions for custom model creation. These include lighting, sound, and 'smart brick' coding systems. There are pros and cons to pretty much any system available. So my best advice is to look around and use whatever meets YOUR specific needs best. Lego has been continually improving both app features and device firmware (although often slower than some people like), so don't give up on Lego just because something you want isn't in place quite yet.

Beyond vehicles:

Vehicles and trains are very popular models to build with Lego. Being able to build an RC car or run a train layout is indeed fun. But there is much more that can be done with the LA options of the systems discussed above!

Motors spin, which is what turns the wheels of vehicles or trains. But this same circular motion can be used to operate amusement rides such as a carousel or ferris wheel. Timing code blocks could even be used to automate the length of the ride and a delay for unload/load between rides. Or build a small circular photo cube or display case which rotates. This could be activiated by motion by using a color/distance sensor to detect movement nearby.

Lego makes 'tread/track' elements (as used for wheels on tanks or heavy construction equipment). Some of these allow for connection of elements on the front facing. I used this to create a Waterfall model for display. The motor ran the tread loop vertically and the treads had various bluish colored tiles on it to simulate water. The effect was close to watching a real waterfall. This same concept could be run horizontally to mimic a conveyor belt.

Motors do not have to just spin constantly either. Using the 'tacho motors' which are part of the Boost and Powered Up system, precise control over the speed, distance, and position is possible. As pictured above, I created an automated railroad crossing guard for a train display. A sensor detected the motion of the train which activated the program. The motor turned the crossing guard arm 90 degrees to lower it, then waited for a period of time, and then turned the motor 90 degrees in reverse to raise the guard. This is still a very simple example of what can be done.

Some elements can transform the circular motor motion to a more linear motion. A horizontal track can be constructed to have a model go back and forth in front of background scenery, such as shown above. Here the circular motor motion is changed into linear motion by using the toothed bars. These are mounted on a sliding platform, so whatever is on the platform (the dog) moves back and forth. The dog starts by its owner. Slowly the dog is pulled toward the other person, notice the hub light is red during this. Just before the dog reaches the person, it more quickly runs back to its owner (with green hub light). So the motor reverse speed is greater than the forward speed but the distance it travels (rotates) is the same (just opposite directions).

The main parts used for the sliding platform with their 'Design #' are: #3743 toothed bar, #4510 slide bar, and #2653 grooved brick.

This same action could be done vertically. This is how some elevators or esculator work so these would be possible to build and control. With a bit of creative coding and timing, an elevator could be made to randomly travel to different floors, stopping for a bit to simulate unload/load, and then continue. It could also be triggered by motion using a sensor. Many other cool ideas could be created using similar movements.

This shows one way to control a motor using the Powered Up app. Here the speed of the motor is controlled by the distance an object is from the sensor. The closer the object is, the faster the motor turns.

Notice the code being run here. This is a simple continuous loop which sets the speed of the motor (connected to port A) based upon the reported distance of the sensor (connected to port C). The motor speed is between 0 (off) and 100 (full speed) and the sensor reports distance between 0 (close) and 10 (far). So we subtract the sensor value from 10 and multiply that result by 10, giving us 0=far (motor off) to 100=close (motor full speed). If you want the motor to DECREASE speed as the object gets closer (such as for slowing a vehicle before a collision), just use the sensor value directly (without subtracting it from 10) before the multiplication by 10.

Notice I also have the code blocks for sensor reporting at the lower left of the tablet. You can watch the values for distance, color, and level as reported by the sensor. Note that color perception is only reliable when the object is very close to the sensor while distance and motion detection has a much longer range. Knowing the characteristics of the devices helps create models and code that work the way you want them to work. Experimentation is a key part of learning!

Motors can also be used to pull cables through a pulley system, such as how cranes work. Using twine or string (or any similar material) wound around a drum connected to a motor would allow a pulley system to do a variety of tasks. This could lower/raise a drawbridge for a castle or raise/lower a roadway over a river to let tall ships go through. Even a zipline could be simulated with this type of setup.

In the video above, a simple drawbridge is controlled by the Powered Up system. A string is connected to the bridge and runs though a pulley on the way to the motor drum. The drawbridge starts in the raised position so that nobody can enter the castle. When motion is detected at the bridge landing area, the program runs. First the motor is turned counter-clockwise enough distance to (almost) reach the ground. Notice how the light on the hub turns green (usage allowed) at this point. After 2 seconds, the hub light turns red (not allowed to use bridge) and the motor turns clockwise to raise the drawbridge back to its original position. Note that the bridge needs to have enough weight for gravity to pull it down when string becomes loose. It would be possible (probably even more practical) to have the motor directly control the drawbridge movement, but this shows how a system could mimic cables being used in real life situations. The speed, precise positioning, and timing can all be easily adjusted with the app program.

My tablet running the Powered Up app is intentionally included in this video. It shows how the different parts of the code get highlighted on the screen as they are run. Each code block has options to control how it functions, such as its speed, timing, associated device(s), color, position, or other settings. According to Lego, the device running the app can be 'up to 30 feet away' (depending on any nearby interference) from the hub. During my recent display and in testing, I have had the tablet over 20 feet from the hub AND had myself and other objects between the tablet and hub without any issues or program interruption.

There are so many things that can be done with motors, gearing, and a bit of imagination and creativity! With the ability to add LA to a model, a whole new dimension is available to tap into. Give it a try!

Coding:

"Coding" is simply the process of creating a list of instructions to be performed by a computerized device, in this case it applies to Lego devices such as hubs, motors, sensors, and lights.

The fact that the Boost and Powered Up apps both allow for custom coding is awesome. The fact that Lego itself has very little public documentation for the specifications of the coding is not so awesome. Lego has a very short page on their website for a few of the Boost code blocks with no useful information for custom usage. This is at: Lego Boost guide

There are a few guides done by third parties which are more complete and list more of the code blocks with some detail and example usage. But even those lack specific technical detail which Lego really should make public. Most notable missing items is the range for the color/distance sensor for accurate detection of color, light, motion, and distance recognition.

However being a GUI (Graphical User Interface) system, the icons do reveal basic usage hints and the input methods in the app also act as a guide to the range an option can have. Once you figure out what the icons and their attribute options graphics mean, you can better understand other icons too. So while initially a real Lego guide would be very useful to beginners, experience in the long run will eventually allow easier coding to occur.

Coding is done similar to putting a jigsaw puzzle together. The workspace is called a "CANVAS". You 'drag and drop' each piece (code block) around the canvas and join it to other code to make a horizontal program line (called a "SEGMENT"). The app guides this operation by adjusting the position of other code as needed and then 'locking' the piece in place when it is released. Code blocks lock together as their left or right edge indicates they can. Program segments must begin with some sort of 'start' block or they cannot be executed (run), this makes it possible to leave 'orphaned' code blocks on the canvas for easy access later on without them being run in the meantime.

Any options or input are connected to the cutouts on the bottom side of a code block. 'Reporter' blocks have a top hill (curved or sharp) which make them connectable to the 'options' of other code blocks bottom. The status of a reporter block is thus used as the number or condition for that option.

All programs and subs MUST begin their segment with a 'start' block (rounded left side) in order to be executed. That program will stop (end) when it has no more blocks, encounters a 'stop' block, or all programs on the canvas are stopped. Note that other program segments can issue a 'stop other segments' order also.

Rather than create another third party guide, I thought it would be better to just show the basic icons and attribute patterns. Knowing the graphics allows you to understand a code block no matter which app is being used and if Lego creates new ones in the future. So the table below is a quick look at the groups and attributes:

PROGRAM EXECUTION: NOTICE: Activation of an individual code segment is done by clicking (touching) that segments 'START' block. However, ALL program segments on the canvas can be started by pressing the green arrow icon at the upper right of the app screen. This changes to a red square, which will stop ALL programs on the canvas when pressed. Yellow code blocks manage program execution including starting, looping, and stopping code. Code blocks with a rounded LEFT end mark the start of code segments. Code blocks with a rounded RIGHT end mark the end of code segments. Loop blocks run the enclosed code repeatedly before continuation of the remaining code in the program.
	This group of blocks START their attached program execution. The 'green arrow only' block starts the code segment when it is clicked (touched), while the other two green arrow blocks delay execution until their conditional option is met. The green flag block starts a sub program when its 'trigger' number is encountered in other program segments.
	The green flag block 'triggers' (runs) a sub program with that number. The hourglass blocks delay further commands until time (hourglass) or true condition (hourglass with ?). Red square blocks stop other sub program(s) execution and (if the right end is rounded) this code also. Notice that a '?' in the icon indicates that its operation depends on a true or false 'condition' to occur rather than a number.
	Loops allow for running code segments repeatedly, which is often useful in programs. Notice that a '?' in the icon indicates that its operation depends on a true or false 'condition' to occur rather than a number. The two 'branch' loop blocks allow two (upper and lower) code segments to be built within. The '?' branch runs the upper code when the condition is true and the lower code while false. The 'fork' branch runs both the upper and lower in unison, which allows for synchronized device control.
SENSOR, HUB, APP DEVICE: Orange code blocks manage sensors and hub/app orientation. Here "DEVICE" means the device which is running the app. For the Boost sensors, distance is 0 (close) to 9 (far) or 10 (nothing is detected). Hub and device orientation is reported as numbers which are not in 'degrees of angle' units, are VERY sensitive, and may vary by hub or device. NOTICE: Experimentation is the best method to understand the behavior of YOUR specific setup! Hub and device orientation statistics might report different things for different devices. These numbers also change with even the smallest vibration. When using these in actual code it is usually best to build a 'range' conditional (if -reported value- is between -lowest value- and -highest value-) statement. Do a LOT of testing before making important decisions!
	Sensor detection can either start a program or have a program wait for the option selected to occur. The icon will have a color wheel (color detection), hand (distance detection), or grayscale bar (ambient light detection). The first option is always the hubs port (A, B, C, D) where the sensor is plugged into. The second option is the color (color detection) or distance (distance detection). Distance is 0 (close) to 9 (far) or 10 (nothing detected).
	Sensor reporter blocks are used to provide the program code block options with the value of the sensors detected color, distance, or light. They can also be used on the app canvas alone for a visual display of their current value. The only option is the hubs port (A, B, C, D) where the sensor is plugged into.
	Hub and device reporter blocks reveal the orientation of the hub or device running the app to the program code block options. They can also be used on the app canvas alone for a visual display of their current value. Options for hub orientation are the device and X, Y, or Z axis to report about. For the device running the app there are no options. Be advised that these values are VERY sensitive to even minor movement so it may be wiser to restrict options to a range of values instead of using the raw value reported. For example: "If device orientation is greater than 20 but less than 30, run the code". There is also a reporter block for the remote control, which reveals what button was pressed. For this you enter the channel (A or B), which matches the left and right side of the remote. This can be used in a comparison input option to control other code blocks.
MOTORS: Green code blocks manage motors. Motors can be internal (Boost Hub) or external (wired to a port). There are several types of motors available with different properties. Some motors (called 'Tacho' motors for 'tachometer') can both seek to and report their speed and position. 'Linear' and 'Servo' motors are also available. Motor control seems to be fairly standard, although some options apply to different motor types. The first option is always the port of the motor (or motor pair). The speed (aka power) is a value from 0 (stopped) to 100 (full speed) with negative values usually for counter-clockwise movement and positive values for clockwise movement. Distance and position (when able) is a value between 0 (position of motor when connected) and 9999 (in rotation degrees (*)). Notice that 360* is one rotation, so a value of 9999* would be 27.775 rotations. Tacho motors can seek to a position using a positive or negative value as needed. Tacho motors can report their speed and position (via 'reporter' code blocks), which allows precision control AND reference of their current state.
	Notice the plain white motor face on the icons, this indicates no specific motor type, so these work for all motors (in theory). The first option is the port. Notice the 'meter' icon as the second option which is the speed (power) value. 'Float' (red square in icon) means that power is removed from the motor, although it can still move a bit via inertia. 'Stop' (red square with ! in icon) implies a brake is applied to actually stop the motor.
	These provide a way to control a pair of motors. The first option is the port of the two motors, such as AB (A and B) or AC (A and C). The second and third 'meter' options sets the speed (power) for the first and second motor respectively. This can be useful to synchronize or differentiat motors. The 'speed and steering' icon is useful to control two wheel vehicles (such as those using tracks like a tank or large construction vehicle). The second option (upward arrow) is for the speed (power) of both motors. The third option (steering wheel) controls what influence is applied to adjust the speed of one motor to cause a turning motion. The fourth option sets the directional difference between the motors. This action runs forever (note the rounded right edge), but constantly checks the second and third options for changes allowing for movement control. This is useful as single code block method to control a vehicle.
	Notice the curved red line on the motor face of these icons, which indicates they apply to the 'tacho' style motors. These are the basic 'Tacho' motor controls for operation. Note the 'up arrow' (in the icon by the second input) is for speed (power) and differs from the 'meter' style used in the row above. Speed is still 0-100 with negative values meaning counter-clockwise movement. The third option can be either a 'range' (circle with shading between two angle lines) or a 'position' (circle with just an angle line). The 'range' is used for distance to rotate while the 'position' is used to specify an exact position. Both use a value of 0-9999 degrees. Tacho motors can be reset to their 'start up' position simply seeking to position 0, which is VERY useful to put a motor used for steering back to its center position.
	Tacho 'reporter' blocks return the speed or position of a 'tacho' style motor. These can be used as options for comparison blocks or just alone on the canvas to give a visual indication of their value.
	More control over a tacho motor is allowed with these icons. First option is the motor port. 'Stop' (red square and ! in icon) stops and holds the motor, which implies a brake is used. The second option with a 'meter' sets the maximum power (speed) allowed (0-100) and stays in effect until changed again. The second option with an 'hourglass' is the time in seconds (with fractions allowed) for the action. The icon with the upward curved arrow is for 'acceleration' time while the icon with the downward curved arrow is for 'deceleration' time. These set the time desired before the motor gets to its full speed, often helpful to allow for smoother starts and stops.
	Tacho motor pair code blocks operate just like the single motor versions except they work with a pair of motors. Note the 'up arrow' (second and third options) is for speed (power). The fourth option can be either an hourglass (sets time in seconds) or a 'range' (sets distance in degrees). There are a few other icons (varies by app) which offer other control options, but mostly the option symbols for them work as those described in this section so are not repeated here.
LIGHT AND SOUND: Purple code blocks manage light and sound. The sound file block icons have a speaker at the lower left corner. These are different for each app so they are not included in this table.
	The intensity of an attached LED string can be controlled by the first block. Here the first option is the port and the '%' option is the percentage of intensity, 0 (off) to 100 (brightest). The status light color of the hub can be changed with the second or third block, with the port being the first option of both. The 'paintbrush' option allows a color to be choosen from a color picker menu. The three '%' options allow an RGB color value to be specified, using percentage (0-100) rather than an actual value (0-255). The sensor light color block also has a 'paintbrush' option with a color picker menu.
VARIABLES AND MATH: White code blocks manage variables and math/numeric operations. Variables are used to store values for future reference. There are 'local' (box of folders icon) and 'global' (with a globe) variables. A local variable is only available to the code segment it is defined in, while a global variable is available throughout the canvas. A variable can only store ONE value at a time, but there are many variable names to choose from so this shouldn't be a problem. There are also a variety of math function and comparison operations available, which are mostly used to control the options of other code blocks. These typically accept two values for the comparison or operation. These can be numeric, the value of a 'reporter' block, a color picker value, or other appropriate value.
	This is a special block which allows access to devices on hubs other than the 'primary' hub. An app which allows for more than one hub to be connected at a time (such as the Powered Up app) has an ordered list of hubs, the first being the 'primary' (or active) hub. Any ports used in code blocks reference the primary hub ports. But this code block allows access to other hubs, with its first option being the hub number (1 to #_of_hubs) and the second option being the port on that hub. The list of connected hubs is available by clicking (touching) the "Bluetooth" icon at the top left corner of the canvas. Be strongly advised that since you can change the hub order (using drag and drop), a hub number can change and thus make this code block reference unwanted devices. Also, if a hub is disconnected or the app is closed (which disconnects ALL hubs) a new list is generated as hubs are connected again. So while this code block is very useful, it has its drawbacks too!
	Variable reporter blocks have just one option, which is for the variable name. Variable setter blocks have a second option for what value should be stored in it. Setting a value overwrites any value it previously had.
	These commonly used logical comparison blocks which return a 'true or false' value, used for code block options that have a similar 'triangle shaped' connector. These are called 'conditional' blocks because the value is based on if the condition is true or false.
	These 'conditional' blocks take on two 'conditional' options with the result being a 'conditional' value (true or false). "AND" returns true if BOTH options are true, otherwise it returns false. "OR" returns true if EITHER option is true, otherwise it returns false.
	These are simple math blocks which perform their operation on two numeric options and report the numeric result.
	The 'inversion' block simply inverts the option values positive/negative state and returns the result. Negative options (such as -5) are inverted to positive (5), while positive options (such as 7) are inverted to negative (-7). The 'maximum' and 'minimum' blocks compare the two options and return the result. So '3 max 7' would return 7 and '3 min 7' would return 3.
	The 'random' block returns a random value in the range of the two numeric options (inclusive). The 'modulo' block returns the modulus (remainder of a division operation) of the two options. The 'ADV' block has a variety of advanced math functions to choose from (first option) to work on the second options value. Math functions available may vary by app or be added to in the future. Not all math functions are listed above.

Exploration of all the code blocks available in the app you use is a fun way to learn. Using the icons, symbols, color groups, and basic descriptions should allow you to figure out any unlisted blocks which are encountered. Think about what you want to do, think about what code blocks need to be used, experiment and test, retest and retry as needed, and then enjoy the successful result!

I am in process of preparing more text, images, and videos to this page. So please check back again to see what is being added.



Page last updated: November 22 2021 15:05:53.
Page visited: 683