Jin Ye,

That's a good challenge. There are probably lots of ways to handle 
it, but here's one method that might work well and be generally 
applicable.

First, each working routine can become a MyBlock. That way they are 
easy to handle, look like what was originally built, and editable.

Then, they can be combined into a single program that calls each 
MyBlock in turn. Inside the MyBlocks, the beginning and/or end will 
need to be changed, as the robot won't be starting/ending in BASE in 
each case.

That's enough to get the whole thing working as a single program. 
However, it does leave the problem of having a 2.5 minute 
(hopefully!) routine, so it's difficult to work on the last parts. It 
will be handy to be able to run each MyBlock individually, to work on 
just that part of the routine. What's needed, then, is to be able to 
place the robot where it will be between each pair of MyBlocks--i.e., 
at the transition points.

To do this, I would insert a pause (and maybe a beep) in the main 
program, between each pair of MyBlocks. When the robot stops and 
beeps, the team can note and mark the exact location of the robot on 
the competition table. Later, if they want to run just the second or 
third MyBlock, they can place the robot at those intermediate 
positions.

Later, the pauses and beeps can be removed.

Cheers,
Mike


>Scenario -
>
>The 09 Challenge tasks in NE area of the field have been sectioned 
>to 3 sub-groups and three subgroups of your team have been assigned 
>to each of them and they have made good progress on programming and 
>testing each NXT program that they made. Each one is executed 
>starting from BASE and returing the BASE at the end. However, as 
>they expected, total accumulative time for all three is like 2 min.
>
>They wonder if they can combine and refine the all three programs, 
>they then can take care of the multiple mission tasks in NE area BY 
>ONE RUN, the great amount time will be saved.
>
>So your team is writing and testing an NXT program to deal with all 
>tasks in NE area of the field  and the program is called 'ne.rbt'
>
>The BIG problems that I can see are -
>1 - now so many NXT blocks are in the program. Since they are 
>executed in a serial sequnece (one action follows another), more 
>accumulative errors are likely surfaced - a little off at the early 
>steps may cause late steps waaaay off.
>2 - Even if you program intelligently (using sensors) so the 
>accumulative errors are small, you still have to run ALL early steps 
>to get to the late steps in order to test them.
>
>So your team want to find a way for each of the team subgroup to 
>work on a subset of the entire program ('ne.rbt'), and when each of 
>subsets is fine-tuned, the team can quickly combine them to get 
>entire 'ne.rbt' without much re-program and re-testing!
>
>Experienced coaches and mentors - any suggestion to VADCLL community?
>
>I'll post my suggestion tomorrow.
>
>Jin
>
>
>
>To UNSUBSCRIBE or CHANGE your settings, please visit 
><https://listserv.jmu.edu/archives/vadcfll-l.html> 
>https://listserv.jmu.edu/archives/vadcfll-l.html and select "Join or 
>leave the list".
>VADCFLL administrative announcements are sent via VADCFLL-ADMIN-L. 
>Visit 
><https://listserv.jmu.edu/archives/vadcfll-admin-l.html>https://listserv.jmu.edu/archives/vadcfll-admin-l.html 
>to subscribe.

-- To UNSUBSCRIBE or CHANGE your settings, please visit https://listserv.jmu.edu/archives/vadcfll-l.html and select "Join or leave the list".

-- VADCFLL administrative announcements are sent via VADCFLL-ADMIN-L. Visit https://listserv.jmu.edu/archives/vadcfll-admin-l.html to subscribe.