File Error and Compiler Error

[timdavid]

Originally Posted by ISHW

It would be great if some of you could post the size of the largest single programs that still runs successfully on the NXT.

Our sequencer program this year is currently at 30 KB. I think it was larger than that last year, but I'm not sure. It looks like a big chunk of the memory on our NXT is being occupied by sound files used to "improve" the audio feedback for the person running the sequencer program...

[ISHW]

Originally Posted by Dean Hystad

My program that allows writing NXT programs on the brick, slaving to another brick, sending programs to another brick, or synchronizing running programs across multiple bricks takes up 47.5k. It runs like a champ.

Thanks for posting. This is a strong indicator that our problem is not (not only??) the file size.

This also means we need to keep searching where the problem comes from, at least if my team wants to use the "Menu" program.

[dnb]

Originally Posted by ISHW

It would be great if some of you could post the size of the largest single programs that still runs successfully on the NXT. My team is still struggling to get the "Menu" program working when they put their competition programs in. We'd really like to understand if program size is a limiting factor, or if we have to do more search going through all these MyBlocks.

Our largest program that still works is about 34 KB (compiled as reported by the NXT memory tab). In this case 5 levels of MyBlocks are used.

Our main program (sequencer) takes up 47k and has 4 levels of MyBlocks.

[dcsastry]

Hi,

Our team had a master program with 6 embedded mission programs, compiled it was around 59K and it ran fine. But if they tried to add or change blocks where the size went above 60K we could no longer compile it in NXT-G.

Our solutions was similar to others here - we had 2 separate master programs, one with 4 missions and the other with 2 missions. Total space was higher, but it fit all mission on the NXT FLASH memory.

We do have problems with back-2-back missions having motor rotaion problems, but we learned recently about the rotational error-correction managed by Move blocks and how can use the Motor Reset block to clear those. But we haven't verified yet that it solved our problems yet.

[Dean Hystad]

Originally Posted by dcsastry

We do have problems with back-2-back missions having motor rotaion problems, but we learned recently about the rotational error-correction managed by Move blocks and how can use the Motor Reset block to clear those. But we haven't verified yet that it solved our problems yet.

The Reset block documentation makes it sound like it does some sort of accumulated error correction. This isn't really true. What the Reset block does is reset the commanded motor position to zero. The commanded motor position is the value used by the PID servo correction to control motor position. The value starts at zero and is adjusted using the Move and Motor blocks.

          cmd     pos
Start       0       0
Move 90    90      90
Move 180  270     270
Move -300 -30     -30
Reset       0       0
Move 90    90      90

Usually you position the robot and adjust the arm with no program running. When ready you start the program and all the motors are reset to zero. The first Move of 90 degrees moves the motor to 90 degrees and the motor rotates 90 degrees. But what happens if you manually turn the wheels or adjust the arm AFTER you start the program but BEFORE the first move block?

          cmd     pos
Start       0       0
Manual 45   0      45
Move 90    90      90

The Move duration is 90 degrees, but the motor only moved 45. The motor moves 45 degrees because that is how much the motor needs to rotate to get to the commanded position. Think about what this does to a mission if you rotate the wheels while positioning the robot.

Lets say the first command in the mission drives the robot straight ahead 10". You run the program alone and the first move drives the robot out 10". You put the program in your fancy sequencer and test. Setting up for the mission you position the robot 1" from the wall and slide it backward till it touches. You press a button to start the mission and the robot drives out 11" instead of 10". What the heck? You test again. This time during setup you push the robot forward 2", pick it up and set it against the wall. You press a button to start the mission and the first move only goes 8". You test and test and the results are different all the time. For a really big surprise roll the robot forward 10" or more before starting and the program appears to entirely skip the first move. I think this is what's happening when teams report a program is skipping some of the move blocks.

Reset is a very important, very underutilized block.

[LOLComets]

Originally Posted by Dean Hystad

The Reset block documentation makes it sound like it does some sort of accumulated error correction. This isn't really true. What the Reset block does is reset the commanded motor position to zero...
Reset is a very important, very underutilized block.

Excellent post and it belongs to a special category for those that should be kept and made available every season.