Programming Highlights

 

 

In this activity students are working with the Wait Until and Sensor Watcher sensor blocks. In the next activity they may be using the Yes or No Stack Decision Makers. We’ve decided to discuss all programming highlights here in order to give you a more global view of the various ways to get information from a sensor. We do not recommend introducing all these concepts in the first sensor lesson.

 

Wait Until

 This Stack Decision Maker block makes a program pause and wait until a certain condition becomes true (e.g., wait until the touch sensor is pressed). Stack commands attached to a Wait Until block will not run until the sensor condition is met. Once the specified condition is true, the program continues top-down, carrying out the stack that follows. The entire sequence only runs once.

In this block the program looks for touch information coming through input port 1.

(Click wizard tab)


© The LEGO Group

The question that the program is evaluating is “Is the touch sensor pressed?” As indicated by an arrow pointing at the pushbutton. To see the condition, users must click on the wizard tab.

(Click wizard tab)


© The LEGO Group

In this block the question the program is evaluating is “Is the touch sensor released?” As indicated by an arrow pointing away from the pushbutton.

It is important no to confuse the Stack Decision Maker Wait Until with the Wait For block. The Wait For block is not a decision maker.

Return to Top

Touch Sensor Watcher:

The Touch Sensor Watcher monitors the state of the sensor, watching for a specific condition—pressed, released or clicked. It sets off a stack of commands attached to it when the condition becomes true. Translated to plain English, each touch Sensor Watcher is set to watch for a sensor event, say if the sensor is pressed, as if continuously asking the question “Is the touch sensor pressed?” As soon as the answer to the question is “yes,” the watcher sets off the stack attached to it.

Note that the Sensor Watcher monitors the state of the sensor frequently, as if repeating the question over and over again.

Examples:

Note that click is yet another event a touch sensor watcher could test for. A program recognizes a click as a press followed by a release within 0.25 seconds.

Beyond the Basics

Return to Top

Motors don’t stop, unless told to do so (well, almost)

Once a motor is turned on, it will stay on until an Off command is issued. The Off command may or may not be in the same stack and may be hidden in an On For block.

A program can run up to 9 stacks in addition to the Main program. An important question is how commands in one stack affect those in another. For example, what happens to a stack in the Main program when a sensor watcher stack is triggered? The simplest way to answer this question is to say, “it depends.”

It depends on whether or not the different tasks (stacks) are seeking control over the same resource (e.g., motors). For example, if the Main program turns on motors and a sensor watcher triggers a stack that has beep blocks as in the program TwoJobs, the two stacks can be carried out without interruption. Here there is no competition between the stacks. Each stack controls different resources: one controls the  motors, the other controls sound. 

However, as illustrated in the program Stop, both the Main stack and the Watcher stack are seeking control over the same motors. In this case, the motors will be turned off when the sensor is pressed.

In the program TwoJobs, motors A and C turn on in the Main stack. It beeps whenever the touch sensor is pressed. Beeping does not interrupt the motors running. The motors run continuously and beeping occurs in parallel, because beeping and motors running do not compete for the same resource.

Important Note: The programs TwoJobs and Stop are simple examples. They also tell only a very small part of the story. The next section provides additional details on how tasks interact.

Smart Tasking

As you have seen in the program Stop, a sensor event can interrupt the Main program. An important question is what happens to the unexecuted blocks in the Main program after a sensor event takes place? A feature called Smart Tasking manages the order of task operations. When an event triggers a stack, the blocks in the stack carry out. This may or may not interrupt the stack in the Main program, depending on whether or not the stacks issue commands to the same resource (e.g., the same motor, A). If commands do not address the same resource, both stacks continue to carry out (e.g., On A in one stack; On C in the other stack). If the commands address the same resource (e.g., On A in one stack, Reverse Direction A), the unexecuted blocks in the Main program are put on hold. The stack triggered by the event watcher carries out and only then the program returns to the Main stack.

Consider the program MainStreet. The program starts by turning on motor A for 3 seconds; While A is turning, (but before motor C is turned on), the touch sensor is pressed. The Sensor Watcher stack triggers and the Main stack is put on hold.

Where will the Main stack pick up? Notice the dashed horizontal lines in the picture above. They designate logical chunks of commands for the Smart Tasking. The program will pick up from the top of the chunk that was interrupted. In this example it will start over with the On A For block.

It can be difficult to determine where in the stack the Main program will pick up after a sensor event interruption. This difficulty is directly related to how students think of how much time the program spends executing a block.

The large majority of students have no difficulty understanding the operational differences between the power commands On For and On. However, many are likely to misconstrue an important distinction between the two—how long it takes the program to execute the block before it moves on to the next block. While in the On For block, the program focuses on the block for the specified length of time (e.g., 2 seconds), in the On block the program drops to the next block almost instantaneously.

Here is an example: In the first stack, the motors run for 2 seconds before the beep sounds. In the second stack the beep sounds as soon as the motors turn on. But because the motors stay on, students may think that the program is still executing this block.

 

 

Here the program executes the On AC block in a fraction of a second and immediately moves to the next block, Beep. 

Here the program doesn’t leave the On AC block for 2 seconds. Only  then will it drop to the next block, Beep.

 

 


© The LEGO Group

How does this relate to Smart Tasking? Look at the NoPickup and Pickup programs.

In the program NoPickup, On AC executes instantaneously, and the program leaves the On AC block. When the touch sensor is pressed, the motors turn off and Smart Tasking returns the program to the Main stack. The motors do not turn on again because at the program had already left the On AC block.

Do not let the fact that the motors are still running confuse you.

On the other hand, in the program Pickup, if the touch sensor is pressed within 8 seconds, while the program is still executing the On AC For 8 block, the motors will turn off. As soon as the sensor is released, Smart Tasking will return the program to the Main stack, where it will pick up at the top of the string of blocks enclosed in the horizontal dashed lines (i.e., starting over the On AC For 8 block).

 

 

Tech Guide

  

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

Tech Guide

 

 

 

 

 

 

 

 

 

 

 

 

Tech Guide

 

Tech Guide

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

Note: If you wanted the motors to stop when the sensor is pressed, you would either have to deactivate Smart Tasking or add an End Program block in the sensor stack.

See additional details on Smart Tasking and End Program.

 

 

Return to Top