You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Idea is to generate analog outputs on the fly, using the continuous mode of the daq.
The analog daq sessions needs to be in IsContinuous mode, and a DataRequired callback needs to be set, e.g. every 50 or 100ms. When this callback runs, it asks each analog signal generator for the next 100ms of samples, and queues them all. The signal generators can come up with these however they like. When the daqController.command function is issued, this information is passed on to the signal generators so that they may use it to inform the samples that they are generating.
The benefit of this approach is that analog signals can operate in parallel, asynchronously and so that they can be updated in a smooth way (e.g. a sine wave output can update its frequency without going out of phase, for instance). The cost of this approach is that any requested new analog outputs that are commanded would only show up ~100ms later or so. This is probably slower than currently, though actually maybe not slower by much (has anyone tried to measure the delay somehow?).
The text was updated successfully, but these errors were encountered:
Idea is to generate analog outputs on the fly, using the continuous mode of the daq.
The analog daq sessions needs to be in IsContinuous mode, and a DataRequired callback needs to be set, e.g. every 50 or 100ms. When this callback runs, it asks each analog signal generator for the next 100ms of samples, and queues them all. The signal generators can come up with these however they like. When the daqController.command function is issued, this information is passed on to the signal generators so that they may use it to inform the samples that they are generating.
The benefit of this approach is that analog signals can operate in parallel, asynchronously and so that they can be updated in a smooth way (e.g. a sine wave output can update its frequency without going out of phase, for instance). The cost of this approach is that any requested new analog outputs that are commanded would only show up ~100ms later or so. This is probably slower than currently, though actually maybe not slower by much (has anyone tried to measure the delay somehow?).
The text was updated successfully, but these errors were encountered: