×

Our Future . . .

When I initially created this site in 2014, it was to serve two primary purposes.

  1. To document the tips, tricks, and other higher level development practices that make programming for FRC in LabVIEW easier.
  2. Provide a common place for LabVIEW teams to find resources.

At first, this meant documenting the architectural and similar tools that I had learned on my way to becoming a Certified LabVIEW Developer, that had been put to use by the team I was currently mentoring (#3937, Breakaway). (This had the added bonus of helping the senior programmer that had been soaking all this up document it for his successor.)

Since then, this site has had a few additions and updates (mostly by me).

While I have often invited other teams (I am no longer in the AR area and have pretty much lost contact with Breakaway) on CD and at the regionals I've been at to write tutorials for specific topics that they had solved, I was rarely met with a response (specifically once - shout out to the Huskie Robotics 3061 for actually following through, but they were the only ones).

 

In recent years, I have found myself going through some family changes and needing to dial back my commitment to other activities.

This leaves this site both:

  1. Looking for a new champion/curator, that is willing to:
    • maintain the back end,
    • make sure material that becomes obsolete is either updated, or moved to the archives section of the menu,
    • and either write content or get other teams to write content to help this site remain relevant.
  2. Looking for a new source of funding/hosting. (I have been personall providing the $36/yr that it costs to maintain it using Google Domains for the domain name - and email - and Hosting24 for the hosting; I have thought about using some sort of a Donate button, but have not been able to find a platform that allows for *only* raising the target amount).

 

If you have any interest in seeing the continuation of this site, please let me know.

FRC LabVIEW Tutorials - Teleop

Table of Contents

Background

When the authors of this website first started programming for FRC, we would get the 'Robot Drive Not Running Fast Enough' error frequently. After speaking with several teams at regionals, we came up with a solution. The following optimization has been used by the teams that we are alumni of and mentors of, and none of the teams have had that error since.

-- note --

In the summer of 2016, we were able to actually do a performance test on this that showed that the following method significantly outperformed the DevRef get/set method. We gave our results to the people at NI that work on this, and they said the reason was the DevRef get allocated memory every time and they fixed that for the 2017 season (and presumabley onwards).
For that reason, the following moves from being an optimization to reduce lag to being an optimization for the developer (by not causing him/her to type out a case sensitive name multiple and related less than great development methods).

Initialize

Begin by opening the devices in Begin.vi, notice that we even skip setting the refnum, and just bundle everything.

Setup

Now, place an indicator on the front panel, here is another place where the TypeDef can be extremely useful, so we'll take a moment to set one up, notice that we also take this opportunity to rename each element in the cluster to something meaningful (drive joystick, rather than JoystickDevRef)

Indicator

We can use these names in the Begin.vi block diagram as well - by switching the bundle for a bundle by name - this also bears other advantages like what is demonstrated in the TypeDef tutorial

setting up the TypeDef

For now, we copy the indicator from Begin, to Teleop and paste it on the front panel (and switch it to a control).

Teleop

We can connect both the control and the indicator to the terminal block, and connect the two in main.vi

Inside Teleop we can unbundle the DevRefs and use them.

Undbundled TypeDef's

This wire allows us to skip the getDevRef for every device every time through the loop. Giving us the performance boost we were after.

Notice that the wire in main will not break thanks to the typedef.

This minor change to the architecture can permit Teleop to complete just a little faster, which can remove the error message, and using a typedef, can save a lot of time during development too.

If this tutorial inadvertently leaves some details out, please tell us about it and we will update it.

Google Form to request details