I’m looking at using the new Test Mode. Is there ANY overhead associated with it during an official match?
Also is there ANY overhead associated with bringing up a new window on the Driver Station through the Dashboard during the test?
Or using network tables to communicate between the Dashboard and robot since the robot would be turned on, on the field and would not go into the test mode, however since the code would still be sitting there in test mode, are those network table entries active, and therefore overhead?
I’m using LabVIEW.
Let me know if you need to see the code.
Test mode is an alternative to autonomous and teleop. The field will not put your robot into test mode, and on the field, your DS does not control the mode.
Test mode is intended for development, troubleshooting, and validation before you run a match, not during a match.
If you want to run a test and have the test results/progress show in another window, this should be fine. The overhead will depend on what the window does and how the code for it is written.
The test mode is implemented using network tables, but of there are no updates to a variable, there is no/little overhead.
I hope I’m answering your questions, but if not, please give more background on what you are trying to accomplish or how you are thinking of using test mode.
Greg McKaskle
I have attached a Robot Project and a Dashboard Project with the test code in them. You should be able to run these in the simulated mode and probe around. Note that you may want to hook up a joystick on joystick # 2.
The test: Launcher Test for testing a Launcher on a practice field, in the pit etc…
When the Launcher Test is selected from the drop-down menu in the Test tab on the Dashboard it brings up an extra window with sliders to control motor speeds, a goal for our Launcher Angle (up/down), a potentiometer readout for the same Launcher Angle, and a range control that sets the range the Launcher Angle must be in, to stop moving.
Since the Test VI is a static VI does this mean it is overhead?
I’m not for sure what static VI means.
2013 Robot Project.zip (3.51 MB)
2013 Dashboard Project.zip (336 KB)
2013 Robot Project.zip (3.51 MB)
2013 Dashboard Project.zip (336 KB)
I looked at and ran some of your code, and it seems fine to me. I didn’t see the CPU usage being more than a few percent on the computer when running the popup panel for the test. I didn’t run it on the cRIO or the simulator.
The general idea is to give you a way to test out a mechanism in order to validate it after work or after a match. So this seems like a good example.
As for the question – a static VI is one that is known about at compile time, as opposed to a dynamically called VI. At least that is what I assume you are asking about. Do you have a specific location in the environment that is calling it static and confusing you?
Greg McKaskle
About the static VI: I’m just wondering if since the Test VI on the Main VI is static, does the program keep running it even while TeleOp is running, and/or since the Test VI is outside the main case structure?
Let me restate the main question: Does putting in test code make ANY extra overhead, NOT during the test but during an official match?
The next time I can I will probably test the time it takes for the main While Loop to run in code with and without the test code and compare the results.
You should be careful about using the word ANY. For example, the 2013 template that includes test mode adds two extra cases in the switch statement in the main while loop compared to the 2012 template. This adds several extra assembly instructions. At 400 mhz, this might add a few hundred nanoseconds. This means that test mode does cause extra overhead. However, I don’t think that is really what you were looking for.
Note that this example is based purely on the template, and it doesn’t matter if you’ve added any test mode code.
Ahh. I was wondering if/how the static VI reference was causing the confusion.
The Test VI is launched when the DS starts test mode and aborted when it leaves test mode. There is no overhead when the robot isn’t in test mode.
Static refers to the fact that the name of the VI is known at compile time and the VI is built into the EXE even though it is referred to dynamically. VI References work like function pointers. They are generally used for more sophisticated architectures, but are also handy when you want to run/abort a piece of code and it isn’t required to cooperate.
Greg McKaskle
Thank You, I think this answers the question.