My team has ran into what appears to be a LabVIEW or NXT bug. They have had successful autonomous for several months running a queued state machine. A couple days ago they made some changes to a subVI that controls the robot movement. This VI moves straight using a while loop monitoring encoder counts or turning using a while loop monitoring compass sensor. The addition was while monitoring the encoder sensor slowing the robot down the closer it gets to its target so the move could be more accurate.
After this change the NXT is aborting the running program after 14 seconds. Their code is menu driven and they are able to select different auto tactics. No matter which tactic is selected the robot stops after 14 seconds.
We have a “feedall” watchdog in its own loop running every 500 ms. We have tried moving that into the move subVI, multiple NXTs, taking the changes out of the code, etc. All while loops have several up to 5ms waits for execution timing. We are using only the LabVIEW wait, not the NXT that has the watchdog buried in it.
Their teleop (using some of the same subVIs) runs perfectly for more than two minutes.
Any ideas are welcome.
Is it possible to share the code so we can take a look at it?
If you use diagram disable to comment out the changes made, do you still see the 14s behavior or does it run like it did before?
Are you seeing any errors or is it just stopping?
Well, mystery solved. After trying everything under the sun we could think of one of the team members realized with our new encoder strategy changes we were logging more data points. Sure enough, it seems like we were hitting a memory issue either in LabVIEW or on the NXT. When they do a sensor operation (move to encoders, rotate to compass, read IR) they log the sensor values. Taking out the logging fixed the issue. They can put back the logging feature for specific moves but not the entirety of the program.