Built in signal Processing for DaqMX

[falkpl]

I am a big fan of the built in logging added to the daqMX library, and would like to see NI build upon this model of adding common dq programming tasks without the need to do anything more than flip a few properties on a task.

The set of properties I would like to see is a section on task.read called processing that would apply signal processing to the incomming signal prior to reading.  Some examples would be filtering (low, High, band, selectable windows....) FFT, sthresholing, edge detection (returns booleans instead of analog signal).  If this was implemented in a slick way the driver could possibly offload the processing to a FPGA folowing the cRIO model.  Since this is a property added to a task, the task could decide if there are hardware resources avaliable or software processing only. 

The programmer can simply select the processing for the task type and now have a daq task with built-in signal processing simplifying the code development cycle (IMHO).

[Brian_Powell]

I have a couple of thoughts...

* This philosophy isn't unlike the modular instrument APIs, where measurements are done as part of the driver instead of explicitly on the diagram.  As you point out in DAQmx, we keep them separate, for the most part.  Both philosophies are valid, but...

* I worry that with the breadth of hardware capability in the DAQmx driver, adding a lot of measurements to the acquisition and generation driver is going to really complicate the API.  Can you mock up some examples that compare diagrams written with the existing and proposed APIs?

[Darren]

Any idea that has not received any kudos within a year after posting will be automatically declined.