Between each myblock try using a motor reset block to zero out the motor. You should do this for every motor. some teams have great success using this strategy, but I've never seen my teams able to really use this strategy successfully. A mission doesn't complete correctly and then you're off in the program and it doesn't work. Best lot of luck to you and your team. Michael Brown ESVA FLL Mentor "What we discover is more important than what we win." On Nov 30, 2013 11:43 PM, "Bob and Ann Henshaw" <[log in to unmask]> wrote: > Dear FLL community: > > > > We are looking for advice regarding an unexpected programming problem with > our robot. Sorry for the long explanation, but I wanted to clearly state > what we are observing. > > > > We are trying to combine 4 separate missions into a single mission with 4 > sections triggered by a touch sensor. To do this, each separate mission has > been saved as a myblock (eg MB1, MB2, MB3, MB4), which run in sequence > between wait loops triggered by the touch sensor (eg. MB1, wait, MB2, wait, > MB3, wait, MB4). > > > > The first problem we encountered was that the A motor (which controls our > attachments) was locked and not moveable as we tried to exchanged our > attachments and reset the position of the motor between segments. We > addressed this by using a motor stop at the end of each myblock to unlock > the A motor. (eg. MB1, stop, wait, MB2, stop, wait, etc). This allowed the > motor to be freely moveable and allowed us to reposition each attachment at > the right angle. > > > > However, when running this program, we found that the A motor, starting in > our second segment (MB2), moves much further than programmed. For instance, > the A motor would move over 200 degrees instead of 120 degrees, causing the > robot to get stuck. > > > > Our initial thought was that we were running afoul of the rotation sensor > of the A motor as we manually moved the motor with each exchange of > attachments. To address this, we attempted to reset the rotation sensor > using the rotation sensor block, with the A motor checked, Action set to > Reset, and the compare degrees set to 0. We tried placing this reset block > both before and after our wait loops, with no change in the observed > behavior. (eg. MB1, stop, reset, wait, MB2 etc no different than MB1, > stop, wait, reset, MB2, stop, wait etc). > > > > We also tried unplugging the A motor between missions, trying to see if > this would manually reset the A motor, without any change in this behavior. > > > > Our 4 missions continue to work well as individual programs and we will > likely continue to operate with 4 separate programs. However, we have spent > a fair amount of time as a team trying to determine why the robot is > exhibiting this behavior. > > > > Thanks for any and all suggestions. > > > > Sincerely > > Bob Henshaw > > > > > > > _______________________________________________________________________________ > > Ann and Bob Henshaw > > 3808 Fort Worth Ave > > Alexandria, VA 22304 > > > ------------------------------ > 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-ANNOUNCEMENTS-L. > Visit https://listserv.jmu.edu/archives/vadcfll-announcements-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-ANNOUNCEMENTS-L. Visit https://listserv.jmu.edu/archives/vadcfll-ANNOUNCEMENTS-l.html to subscribe.