Quote:
Originally Posted by Kevin Sevcik
Tom,
I'm a little concerned that I don't see any DaqMX tasks in this code. I realize it's slightly advanced stuff, but it's important slightly advanced stuff. You can set up hardware timed data sampling tasks that run at much higher frequencies than your background processing tasks, as well as setting up custom scales and all sorts of other things. Hopefully it's just that beta teams haven't gotten around to looking at that sort of thing yet, as opposed to it not being an option.
|
The FPGA is implemented to execute hardware timed analog acquisitions in the background. You can specify different sample rates for each module (which is more flexible than DAQmx) so that you can better tailor the measurement to the sensors connected to that module. In addition, there are hardware accumulators (DAQmx doesn't have them), oversampling / averaging engine (DAQmx doesn't have it), 8 analog triggers (DAQ boards usually have 0 to 2) and the triggers support rollover detection (DAQ triggers don't)... the list goes on and on.
Custom scales are implemented by you wrapping the GetVoltage VI with the calculations you want for your scale. The voltage values that are returned to you are scaled with factory calibration constants stored for each channel on each module during manufacturing.
Quote:
Originally Posted by Greg McKaskle
Responding to the question about DAQmx usage, the cRIO and other reconfigurable I/O devices don't have a traditional driver API to their I/O. The I/O is defined by VIs that run on the FPGA, and accessed by VIs that run on the RT target. In other words, the WPI library really is the API. It is built upon/incorporates the FPGA, and is DAQmx is not in the picture.
|
The goal was to create an API that, while not as general purpose as DAQmx, provides more of the features that teams will need to excel. I hope you find that to be true. Oddly enough, for my day job I'm a driver developer for DAQmx.