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...
Anonymous said…
I 'solved' this problem using a separate threat and a logic variable.
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 :)
Anonymous said…
The value of the sound sensor is read only as the loop finishes an iteration. So, if the value of the sensor exceeds the limit while other code in the loop is running, it doesn't "count".
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.
Thanks for verifying... I figured that the LOOP only tested at the end of its iteration and wasn't monitoring the Sound sensor during the MyBlock executions.
John's idea of putting a parallel sequence beam *within* the loop in question brings up a good point. A loop will only "loop" (begin the next iteration) if *all* the sequences within a loop have completed. So if you put in a second sequence within the loop with a Wait for Sound block on it, the upper sequence will execute once... and then the loop hangs, waiting for the sequence with the Wait block to complete.
Keep the "Waiting" sequence outside the loop, and control the loop via a boolean variable (*not* a wire here) like this:
This is the main problem I find with the NXT-G software. That is why I use Robolab in my classes as you can have an Event set up to immediately respond.
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.
But this is what I LOVE about NXT-G - as soon as I encounter a roadblock, someone has a solution.
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...
Jim
Anonymous said…
Thanks for all your input! I tried the Boolean variable and couldn't make it work, but Jim's suggestion did. With some practice, I now have a pretty good idea when the sound cue needs to be given to stop the loop.
Anonymous said…
Hi. I'm having the same problem as jim kelly, but with the touch sensor. Can someone please give me the easiest way to make it stop as soon as the touch sensor is pressed? I didn't really understand what you guys said to him about separate threats and logic variables and stuff. Thanks : )
I'll try and explain, but you'll have to let me know if this doesn't make sense.
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.
Anonymous said…
I am really confused... Ok, I am sorta new to the whole nxt thing, so I just built the crane that comes with the set, and I want it to drop the ball when I turn off the lights, but as what you guys have said, it will only drop it if I turn off the lights and it just finished the loop. So can someone explain to me how to get around that? (very simple please-I am new)
Comments
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.
Jim
'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:
http://www.brickshelf.com/cgi-bin/gallery.cgi?i=1906478
And *not* like, for instance, this:
http://www.brickshelf.com/cgi-bin/gallery.cgi?i=1906474
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 ;-).
--
Brian Davis
:)
Jim
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...
Jim
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.