[Greg McKaskle]

I'm eager to hear the answer to your questions too, Ether. I don't know what the time quantum is for thread scheduling, but I'm pretty sure that equal priority threads are sliced out. I certainly think I've seen it using the NI RT Trace tool. Additionally, in the default code, all of the VIs are at the common or standard priority, and LV has a thread pool of about four threads to execute the parallel tasks. It sure seems like they slice.

As for the sensors -- the FPGA is involved in all of them except for CAN, serial, and ethernet. Its 40MHz clock drives latching the values in, performs averaging or accumulation, and those values can then be read from FPGA registers using the NI-RIO driver's peek function. Scaling with calibration constants and to engineering units is performed on the RT side, as is the validation that the module and channel inputs were correct. In reality, the RIO platform allows you to move the functionality from RT to FPGA or back, as you choose to use the resources. What I'm describing is how it was compiled for FRC. I'm sure there are processing intensive tasks that make sense to move off, and it is always an interesting research project, but I'm not sure that it will improve the timing, measurement quality, or the throughput of the system in most cases. Because the digital module is the low-cost, high channel version, the encoder sensing is somewhat limited -- about 150k pulses per seconds. If you have other examples to the contrary, please post details.

Greg McKaskle