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.
© 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.
important no to confuse the Stack Decision Maker Wait Until
with the Wait For block. The Wait For block is not a
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.
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
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.
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
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.
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.
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.
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
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.