LabVIEW
Realtime A/D conversion
Possibly the point you have missed is that LabVIEW operates on the basis of data flow.
When the desired number of samples are available from a Data Aquisition task (DAQ aquisition), the data becomes available to the processing routine by 'flowing' from the DAQ task into your process task. It's this flow that controls the execution when you connect the data wire from the DAQ task to your processing task.
Thus is if you use the DAQ Assistant and create a task to read your channels, if there is insufficient time to read in or process the data then an error (e.g. -200279 buffer over written) will be generated and be made available at the error node. Whilst if there is available time the system will wait untill the timeout or the data becomes available.
For your task I suspect that you will need to use reasonably large data blocks for example at 10kHz perhaps transferring data as say 1000 sample blocks might be good for your computers processing configuration. Thus you would have 20 channels at 1000 samples giving a transferred data set of 20,000 samples (if they are two byte samples that's about 40k bytes of data). Now you need to finish your data processing calculations (threshold calculation) in less than 0.1 of a second to be ready for the next set of data as with the rates and sample sets detailed there will be 10 sample sets per second. So now you can determine if your processing task can be performed in the available time period.
Unless you need some kind of guaranteed realtime response behavoir then the realtime operating system may not be necessary. Don't forget that real time only implies that a task will start at a certain time based on a given set of criteria. It does not guarantee that the data processing of a block will complete if the processing overhead is too large for the total system iteration rate.
"May the flow be with you"
When the desired number of samples are available from a Data Aquisition task (DAQ aquisition), the data becomes available to the processing routine by 'flowing' from the DAQ task into your process task. It's this flow that controls the execution when you connect the data wire from the DAQ task to your processing task.
Thus is if you use the DAQ Assistant and create a task to read your channels, if there is insufficient time to read in or process the data then an error (e.g. -200279 buffer over written) will be generated and be made available at the error node. Whilst if there is available time the system will wait untill the timeout or the data becomes available.
For your task I suspect that you will need to use reasonably large data blocks for example at 10kHz perhaps transferring data as say 1000 sample blocks might be good for your computers processing configuration. Thus you would have 20 channels at 1000 samples giving a transferred data set of 20,000 samples (if they are two byte samples that's about 40k bytes of data). Now you need to finish your data processing calculations (threshold calculation) in less than 0.1 of a second to be ready for the next set of data as with the rates and sample sets detailed there will be 10 sample sets per second. So now you can determine if your processing task can be performed in the available time period.
Unless you need some kind of guaranteed realtime response behavoir then the realtime operating system may not be necessary. Don't forget that real time only implies that a task will start at a certain time based on a given set of criteria. It does not guarantee that the data processing of a block will complete if the processing overhead is too large for the total system iteration rate.
"May the flow be with you"
