Checking device type of a digital channel after setting the data transfer method causes an inexplicable error

[Rolfe]

When I try to check the channel type of a digital channel (using the ChanType DAQmx Channel property) after setting the data transfer method to DMA (using the DO.DataXferMech DAQmx Channel property) I get the error:

Error -200218 occurred at Property Node DAQmx Channel (arg 1) in DMA bug demonstration 2.vi

Possible Reason(s):
Data Transfer Mechanism must be Programmed I/O when not using hardware timing.

Set Data Transfer Mechanism to Programmed I/O, configure your sample clock timing, or set Sample Timing Type to Sample Clock.

Conflicting Properties

Property: SampTimingType
Corresponding Value: On Demand

Property: DI.DataXferMech
Corresponding Value: DMA


Task Name: _unnamedTask<1>


At no point have I set the Sample Timing Type to "On Demand." This problem does not occur when I perform the same set of operations on an analog channel, nor when I either set the data transfer method to DMA or check the channel type alone. I've attached a VI which demonstrates the problem (LabVIEW 7.1, DAQmx 7.4). Is this a bug in DAQmx? Am I actually doing something illegal? Thanks.

[JoeSavage]

This is expected behavior, and is explained as follows:

When you do a property "get," it causes the task to attempt to transition to the "verified" state (this behavior is explained in more detail in the "task state model" section of the DAQmx help file). Now, if you do this at a time when the task is in an invalid state, you'll get an error when DAQmx tries to verify the task, which will appear as though the property get is returning the error. In your case, for example, you probably haven't called the DAQmx Configure Timing VI at all before you've called the "get" property node, so the task defaults to "on demand" timing. As explained by the error description, "on demand" timing is invalid with DMA transfer mode. If you wait to call the property "get" until you've configured the timing, then the error should go away.

You can reproduce the same behavior by replacing the property get with an explicit "verify" operation (using the DAQmx Task Control VI).

--Joe

P.S. By the way, I didn't see an attached VI, so I can't confirm that you were doing as I explained.

Message Edited by JoeSavage on 04-10-2005 10:08 AM

[Rolfe]

That explanation fits with what I'm seeing. This is sort of irritating in that I was using the Reads from the property node to decide exactly how to configure the timing, but I can just pass the channel-type information on from earlier in the initialization process rather than extracting it from a property node. Thanks for your help.

[JoeSavage]

Also, you could just get the ChanType property before you set the data transfer mode to DMA. If you set an attribute on a task when it's in the verified state, the task will transition back to unverified, so you won't get any "invalid attribute combination" errors.

[JoeSavage]

[deleted duplicate message]

Message Edited by JoeSavage on 04-10-2005 11:29 PM