Posted by Marc-Andre Bazergui (bazmarc) March 08, 2019 ROBOT REMIX #6 Share Get link Facebook Twitter Pinterest Email Other Apps Post a Comment
In the past, when I've relied on the Sound sensor to break a LOOP, I've had to yell over and over because it seems that the LOOP block only checks the sound sensor at specific intervals... for example, I believe that when the MyBlocks inside the loop are executing, the Sound sensor is not being polled... your ONLY opportunity to trigger the Sound sensor is when the last MyBlock completes and JUST BEFORE the loop starts again. This has been my experience, but it might just be a fluke...
The separate threat first sets the variable to false. Then it goes into a loop which checks for the sound level to rise above 60. When it does it set's the logical variable to true.
The loop in the first threat waits for the logic variable to become true, so if you clap when the loop in the first threat is busy, the second threat sets the variable to true, and when the loop in the first threat checks the variable it will stop because it was set to true.
I hope this makes sense :)
I'd recommend using Brian Davis' loop expander to create multiple sequence beams inside the loop. Then, configure the loop for logic and put a 'Wait for Sound' on the sequence beam that doesn't have the MyBlocks.
Sorry if this isn't clear, but I can't seem to attach a picture.
'anonymous's comment is a better way to go.
Keep the "Waiting" sequence outside the loop, and control the loop via a boolean variable (*not* a wire here) like this:
And *not* like, for instance, this:
and the fact that I had these examples all ready up in my Brickshelf account should tell you this is not the first time the question has come up ;-).
I just saw on the Tufts site that there is an update for Robolab 2.9. I have just installed it, looks like it has some nice new NXT functions including motor syncing etc.
There are some discussions in other arenas related to NXT-G programming issues that I participate in, and I can tell you that there are a LOT of solutions to programming problems that are floating around...
When using a LOOP block that is configured to BREAK when a sensor is triggered (the Touch sensor, for example) - the LOOP will ONLY check the status of the sensor after all the blocks inside it have executed. So, if you have 3 MOVE blocks inside a LOOP block and the 2nd MOVE block is being executed when you press the Touch sensor, the LOOP will NOT break. The LOOP block MUST finish the 3rd MOVE block and then it will examine the status of the Touch sensor. What this means is that you must time the Touch sensor button press very carefully when dealing with LOOP blocks.
What Brian suggested (and what works) is putting a Touch Sensor Block (yellow block) inside the LOOP Block. Let's say you configure the Touch sensor block to trigger when the button is pressed (as opposed to bumped - or press&release). Now, take my same example but put the Touch sensor block in front of the 3 WAIT blocks. Now, if the Touch sensor is pressed, the block will register a TRUE value (the condition is met? TRUE). This TRUE logic value can then be passed to the LOOP block. The difference is that you'll configure the LOOP block to break using a LOGIC condition. If TRUE, then break... if FALSE (meaning the touch sensor was never pressed) then the LOOP block will execute again.