As Alan said, if this is running on FRC hardware, you should really use the FPGA-packaged solution provided, with the interface given in WPILib.
If you need to access raw counts, the Encoder VIs should expose this (the Java and C++ libs do), though I don't have an FRC copy of Labview in front of me to confirm. If not, you can always divide distance by the distance per count you gave the Encoder Open block, though this is not ideal.
The FPGA is a large reconfigurable logic circuit (
Field
Programmable
Gate
Array). This means we can design (just about) any network of logic gates in a language like Verilog, VHDL, or even LabView (or just about any hardware description language), and then compile this "code" into an image for the FPGA. Imaging the FPGA reconfigures it to match this circuit design. This means that the operation of your "code," i.e. your circuit, is just as fast as hardware (or almost as fast), but you can still reprogram it without manufacturing an entirely new chip. However, in FRC, we are required to use the FPGA image provided by NI and FIRST, which already does a lot of useful stuff, like count encoder counts. Everything we do has to be in software on the CPU.
Encoder counts go by pretty fast. Even at FPGA processing speeds, we can't have shafts spinning anywhere upwards of 15,000 rpm for the typical US Digital encoders. Depending on a number of things, that limit is probably substantially lower, between 5,000 and 10,000. If instead of "looping" at 6 microseconds in the FPGA you want to loop at 6 milliseconds in software, your limit drops by a factor of a thousand, so now you can't spin the encoder shaft faster than about 5 or 10 rpm. And that's just not very exciting.