×

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 - Producer Consumer

Table of Contents

What is it?

The producer consumer is a standard LabVIEW architecture which allows for the separation of the code that is creating data or instruction from the code that is logging that data or putting those instructions to action.

Its primary use is for large scale applications where recording every bit of data is important, but in FRC we often times care more about the most current data or instructions, so while a true producer consumer is implemented using a queue, it is advisable to use an fgv or global variable.

Why use this architecture?

One reason to use this is to separate the code that is deciding what needs to be done (reading the joysticks) and implementing (setting the actuators).
Why not put it all in one place?
The more code there is in a single vi, the harder it is to maintain (correct an issue, update, or add to).
Don't parallel loops cause lag? They can, if not implemented correctly. It is worth noting that the standard architecture utilizes several parallel loops. (The main loop running Teleop, the loop in the vision code, the loops in periodic tasks, ... etc.). To avoid having one loop hog the cpu, put a wait in it (wait (ms).vi). Even a wait of 0 milliseconds will free the cpu to perform other tasks (like running other loops).

Example

For this example, we will implement a robot that has a linear actuator using a PID and encoder.

Begin.vi

Initializing the necessary items.

Setting things up

Teleop.vi

Here, the joystick is read, and depending on which button is pushed (if any), the value in the global variable is updated.

Reading joystick to set the state the elevator should be in

Periodic Tasks

Here the state is read from the global variable and used to create an encoder set point. Based on that set point and what the encoder currently reads, the motor is set.

Updating the motor in timed tasks

Summary

This tutorial shows how just a little bit of separating code can make all of the pieces seem simpler and much easier to understand. Also, if the actuator needed to go through sequences, it could do so without affecting how often the joysticks values are read or affecting the drive loop. For an additional architecture to consider for sequences, look at our state machine tutorial. These two pieces work well together, allowing the driver to update the instructions at any instant, and when the sequence is ready, it can check for the latest update in the variable.

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

Google Form to request details