[Greg McKaskle]

I'm not magician responsible for the compressor code, but I'll take a pass at pulling back the curtains.

As mentioned, the compressor code is a bit more complex than most of the WPI code. This is because there were multiple authors writing modules, and each has their own personal style. On the one hand it means that there is a bit less consistency, but on the other, it means there are more samples to learn from.

The compressor implementation in LV demonstrates how to kick off totally asynchronous tasks which communicate with both HW and other compressor API calls.

The key to this approach is really in the Open VI. Provided there are no errors on input, the code allocates the DIO and Relay channels, creates two communication channel called RT FIFOs, Opens a reference to a reentrant VI, writes the I/O and FIFO refnums into the controls of the VI, and then invokes the Run method. Essentially pushing the Run button on the VI.

Honestly this is probably overkill for a single compressor, but the code spawns an asynchronous task so that it could handle any number of compressors, each with their own communications channels, I/O refnums, and timing loop. Again, probably overkill, but not a bad pattern for more complex entities where you have an undetermined number of instances.

To see what this spawned task does, double click on the static VI refnum, located towards the left of the diagram and looking like a document with a dog-ear tab and an alias/reference arrow. The double click will open the VI being spawned -- RunCompressor.vi.

The VI loops, but blocks waiting for the enabled FIFO to be written to or for a half-second timeout. If not enabled, it ensures that the relay is off. If enabled, it checks the pressure switch on the DI, updates the relay appropriately, and publishes the latest relay state so the API call to give compressor state has the current value. The loop terminates when the I/O is closed elsewhere and goes invalid.

The rest of the API updates the enabled FIFO, reads the relay state FIFO, etc.

The important take-aways of this code are ...

LV has a way to spawn any number of tasks, peek and poke values into the instance to act as parameters, block until completed or run asynchronously.

LV has a more efficient and more controlled data sharing mechanism than the global variable. It isn't clear that this is actually necessary for FRC robotics, but if you want to move from soft realtime towards hard realtime, this is the sort of data sharing mechanism that enables precise control of the various loops, VI instances, and parallel code.

To compare this approach to the other posts. The compressor could certainly be done in the FPGA. The FPGA would allow for polling at very high rates and would allow for a miniscule latency between the pressure switch transition and relay updates. Since there is really no need for this timing precision or loop rates, it would be relatively expensive in FPGA fabric for something that is easily done in other ways.

Similarly, interrupts could be used to have small latency response, and might make sense for a small micro, but for an I/O rich environment, you quickly run out of interrupt lines to directly tie to a switch. Again, a relatively precious resource for a task which doesn't necessarily need it.

I hope this was clear, but if not, please ask followup questions.
Greg McKaskle