Begin.vi

[Levansic]

Humble Begin.vi.

Everything starts in Begin.vi. We open all of our references and configure a few things in those bundles. When the mood strikes (paranoia or deja vu) we might even document key parameter values or the best guess of what we think other programmers were trying to do in this VI.

Other than setting up structures for motors and sensors, what does your team do in Begin.vi? What do you do that is novel here?

[Alan Anderson]

One year, we had a bunch of For loops in Begin reading arrays of configuration data from a Globals vi. Each loop handled one "type" of resource: Motors, Digital In, Encoder, Analog In, Solenoid, etc. If we wanted to add another motor, we'd just add the appropriate information to the Motors array. Finish had a corresponding collection of For loops.

It was a lot of work setting it up in the first place, but it made changes simple. We eventually decided that the simplicity was not worth the up-front effort.

Our Begin vi this year does very little. Except for the framework's Error in/out etc., all it does is call our Drivebase and Superstructure VIs, passing them an enumerated "Begin" value. The real work of opening the resources is done in the Begin case of each.

[Levansic]

We added some homing code for a few motors. It doesn't run until the robot is enabled, and only really runs if the controlled actuator is not already homed.

Our thinking is that similar to charging a pneumatic tank, we could re-home our manipulators in the queue, if needed. After exiting begin, we are not anticipating the need to re-home, but have code that triggers if we trip lower limits.

If we don't get to re-home in the queue, it only takes a second of autonomous, and nothing else happens until the homing is complete.

[Levansic]

Originally Posted by Alan Anderson

Our Begin vi this year does very little. Except for the framework's Error in/out etc., all it does is call our Drivebase and Superstructure VIs, passing them an enumerated "Begin" value. The real work of opening the resources is done in the Begin case of each.

I'm slightly confused here. Am I interpreting correctly that you essentially have a VI for your drive and a VI for your manipulators, and you just call each with a selector for the various behaviors? I am guessing that both generate and use their own refnums.

That seems like a great idea for code organization and bringing new programmers up to speed. Instead of hop-scotching through all of the different VI's like teleop.vi and Periodic_tasks.vi, you have all related code contained in each part's VI.

If I am interpreting correctly, how do you deal with autonomous, as I assume that there has to be some sort of sequencing and communication between both drive and superstructure to complete tasks?

[Alan Anderson]

Originally Posted by Levansic

I'm slightly confused here. Am I interpreting correctly that you essentially have a VI for your drive and a VI for your manipulators, and you just call each with a selector for the various behaviors? I am guessing that both generate and use their own refnums.

That seems like a great idea for code organization and bringing new programmers up to speed. Instead of hop-scotching through all of the different VI's like teleop.vi and Periodic_tasks.vi, you have all related code contained in each part's VI.

That's exactly right. The other unobvious bit is that we keep all the RefNums in a shift register cluster so we never have to do a RefNum Get. We do RefNum Set in Begin just so we can use Test mode.

If I am interpreting correctly, how do you deal with autonomous, as I assume that there has to be some sort of sequencing and communication between both drive and superstructure to complete tasks?

Autonomous is independent at the moment, using a flat sequence. If we wanted to keep it in the rest of the code, we'd probably implement state machines with a shared state variable.