LabVIEW & autonomous "remembers" old values?

[Alan Anderson]

The "Autonomous Independent" is run in a different way from all the other team-edited VIs. It is started by a special LabVIEW function when Autonomous mode begins, and it is stopped by a special LabVIEW function when Autonomous mode ends. If you just disable and re-enable without leaving Autonomous, the first run is not stopped, and if conditions are right a second copy can end up running at the same time. But that really shouldn't happen, and I don't think it's what is going on in your case. What is probably happening is that your encoders are not starting at zero when you run Autonomous a second time, and that's confusing your sequencing.

If you're going to cancel Autonomous without proceeding to Teleop, I think your best option for making things work properly is just to reset the roboRIO before running Autonomous again. You can do that remotely from the Driver Station.

[sethj]

Originally Posted by Alan Anderson

But that really shouldn't happen, and I don't think it's what is going on in your case. What is probably happening is that your encoders are not starting at zero when you run Autonomous a second time, and that's confusing your sequencing.

We are actually resetting all the encoders first thing. What you said first sounds like it (at least in what it does).

[Greg McKaskle]

Autonomous is indeed launched specially. When the robot transitions to Auto, it will "run" your autonomous independent VI. I put it in quotes because it is literally calling the Run method and is very much like pressing the run button.

The reason it does this is really for what happens at the end of auto. When the period ends, it calls the Abort method, which is pretty much like hitting the Stop/Abort button next to the run. It does this because that allows you to write your code without worrying so much about how it stops and transitions to tele.

So, what Alan says is theoretically possible. LV can clone and run as many reentrant VIs as you have memory for, but Auto isn't reentrant, and I have not seen this, and I think that if anything like this happens, it is because the abort has been blocked waiting for a DLL or some other system call that has hung. At that point I think you'd see lots more symptoms than described.

If you run the code in the debugger, without build/deploy, you can open the auto window and actually see from the buttons what is going on. I believe that when you hit disable, you will see auto VI stop. Please inform me/support if it doesn't.

So what is happening?
-----------------------
Here is another way that the auto->disable->auto transition can have the side-effects you describe. When a robot is disabled, the servos, motor controllers, pneumatics, and other output values are simply ignored. They aren't zeroed or magically reset. If your auto makes assumptions about their initial state, that mean that the outputs are simply reenabled to their most recent state.

Example:
Two motors A and B are using during auto. First A is run for 5 seconds and stopped, then B is run for 8 seconds and stopped. You run auto and see this pattern work. Yay.

Then you run auto again and abort when B is running. You now enable the robot for auto again. All outputs are enabled, A and B will both run for five seconds, then A will stop. B will run for 8 more and stop.

This wasn't what you intended, but unless auto specifies what to do with B, it gets to do whatever it wants, or rather whatever state it was left in, until you tell it otherwise, which doesn't happen for 5 seconds.

-----------

So that is my theory as to what is happening. It won't actually happen in a match because the boot up puts things in a known state. But practicing and testing can cause some very confusing results. The easiest way to avoid this is to stop Robot Main and restart. This will close and reopen all outputs, and I believe should give reliable state and is quicker than restarting the runtime or rebooting the controller.

And of course, if you write your Auto to put all your outputs into an initial state, that is a good approach too.

Greg McKaskle

[aeastet]

It sounds like you are using Local or global variables. If this is true then one of them is probably not getting initialized properly. The is the trouble with using these. If you post your code I could look through it and give you some suggestions.