You implicitly transition the task to a new state when you perform an operation that requires that the task be in a specific state and it is not. If this occurs, the task is implicitly transitioned to the required state. Some operations that require state transitions include the following:
Querying the value of an attribute/property implicitly verifies the task. This verification is required to return accurate coerced values of attributes/properties. Because the coerced value of a attribute/property often depends on the values of other attributes/properties, the task as a whole must be verified to calculate the value. Because the task might be implicitly verified when you query the value of an attribute/property, NI-DAQmx may return an error specifying that the value of attribute/property is invalid.
Calling the Read function/VI implicitly commits the task if the task is not already committed. If the value of the DAQmx Read
attribute/property is True and the task has not been started, the task also is implicitly started. For more information regarding the auto-start behavior of read operations, refer to Using the Start Task Function/VI.
Calling the Write function/VI commits the task. If the value of the
parameter is True, the task also is started. For more information regarding the auto-start behavior of write operations, refer to Using the Start Task Function/VI.
For example, if the task is in the Reserved state, the value of the DAQmx Read
attribute/property is True, and you call the Read function/VI, the task is implicitly committed and started. The task transitions from the Reserved state to the Committed state and to the Running state before the read operation is performed.
In some applications, it is not necessary to explicitly transition the task to any state. Instead, invoke the desired operation and the task implicitly handles everything else.