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.