Skip to end of metadata
Go to start of metadata
- Setting writeRelativeTo property to DAQmx_Val_FirstSample allows one to do double-buffering (i.e. write to other half of buffer, while one half is currently being generated) without any further effort (i.e. no need to set 'offset' property)
- Although rngLow and rngHigh properties are separate, they must be set in tandem before either set takes effect.
- One can configure and reconfigure timing (or triggering) parameters for a Task to one's heart's content, as long as Task is not started. EXCEPTION: For Timing, once it has been configured with one function (e.g. cfgSampClkTiming), it is not possible to return to default case where no configuration function has been called. To do so, one has to clear the Task.
- To unregister a callback, one simply needs to set the function pointer to NULL.
- The readChannelsToRead property can be used to select a subset of (virtual) Channels to read from the Task, which does reduce the amount of data returned by DAQmxReadXXX(). This is a convenient way of changing the number of channels being acquired without needing to create separate Tasks.
- Strangely/disappointingly, there is no writeChannelsToWrite property mirroring the readChannelsToRead property. There is no way, it seems, to select a subset of the AO channels to write to.
- The newer boards (M and X series) use the RefClkSrc property to specify an external timebase, while the older boards (S,E,AO,B series) use the MasterTimebaseSrc for this purpose. The newer boards actually generate the clock on-board with a PLL. In DAQmx, specifying either of these properties can be done via 'Task-based routing'. With older boards, it seems that 'immediate routing' is also possible, as the MasterTimebase appears as a terminal name in MAX.
- Documentation says that buffer size for AO Tasks is set on 'first' write operation. Tests show that buffer size is re-set on every single write operation (provided Task has been run and then afterwards stopped). The one situation that leads to error (-200547) is where you write to Task. To do step-wise writing into output buffer, DAQmxCfgOutputBuffer() should be used before first write operation.
- It is helpful to set buffer size to a minimum of 2 samples when using DAQmxCfgSampClkTiming() with DAQmx_Val_FiniteSamps option. If this is not done, then subsequent DAQmxWriteXXX() operations will give Error -200077. It is generally possible to write more data than is presently configured to generate; however, an error occurs when the value configured (the sampsPerChanToAcquire argument, or sampQuantSampPerChan property) is 0.
- To avoid software events being skipped/missed, it seems required to provide some wait time between DAQmxRegisterXXX() and starting the Task. This seems to apply to all 3 software event types: EveryNSamples, Done, and Signal.
- Buffer allocation by DAQmx driver is in the kernel memory space, and is hence limited in total memory (to about 60MB) regardless of the available RAM in the system. The 64-bit DAQmx versions employ the Windows user-mode device driver capability, and can allocate much larger buffers.
Single Sample Writing
CASE 1: No Triggering/No Timing Configured
- In this case, timing is considered 'On Demand'. There is no buffer configured. Calls can be made to DAQmxWriteXXX() with one or more samples specified, and they will play out 'as fast as possible'. There is no limit on the number of samples that can be written in this manner.
- There are two mechanisms that can be used:
- Mechanism 1 ('autoStart' = TRUE). The 'autoStart' parameter is set to TRUE on every subsequent call to DAQmxWriteXXX(). In this case the Task need not be started ahead of time. If 'autoStart' is not TRUE, then Error -200846 results. Following completion of each write operation, DAQmxIsTaskDone() will return True.
- Mechanism 2 (Start Task first). The Task can be manually started before writing data. Subsequent calls to DAQmxWriteXXX() will write specified data out as fast as possible, regardless of whether 'autoStart' is TRUE or FALSE.
- One cannot use the Done Event very usefully in this case. If DAQmxRegisterDoneEvent() is called and then Mechanism 1 is used, then Error -200985 results when DAQmxWriteXXX() calls are made with autoStart=TRUE. One could use the Done Event with Mechanism 2, but this is less useful, as the event is only Done when the user explicitly Stops the Task themself.
- Setting the 'writeWaitMode' property (to attempt to change from the default value of DAQmx_Val_Sleep, or even just to set that value explitly) causes the 'writeDigitalLinesBytesPerChan' property value to be corrupted (made empty), which confounds the use of our WriteDigitalData() method
CASE 2: No Triggering/Timing Configured