Any information about DAQmxGetCIEncoderZIndexEnable

[Kamen]

I am sorry for posting a software programming question in a hardware forum but either there isn't an appropriate forum for my question or it takes more than a 35-year software engineering experience, with two Master of Science degrees qualification to find it.

My question is about the DAQmx "C" programming language reference for accessing a counter/timer property, and more specifically, any information about the function DAQmxGetCIEncoderZIndexEnable. The only information in the help files and online is the function declaration:

int32 __CFUNC DAQmxGetCIEncoderZIndexEnable(TaskHandle taskHandle, const char channel[], bool32 *data);

and it states its purpose as "getting the value of the property". Nothing more. While for anyone who has used the DAQmx C library it would be obvious what "taskHandle" means and that "data" is the value of the property, it is by no means clear what the "channel" string designates. There is no hardware channel name that would be assigned to the Z index, and I don't think it would make sense to call for the name of an input terminal (PFI).

I don't use LabVIEW anymore and I can't drill through the respective VI, and I don't feel like spending hours trying to reverse-engineer the functionality, so I hope someone who has dealt with encoder indices might have an insight as to what that parameter might be. Thank you in advance.

Kamen

[Kevin_Price · Accepted solution]

No need to apologize about a software question.  Most of the discussion in these "hardware forums" is about the programming involved to *use* the hardware. 

Now, while I *only* use LabVIEW, making this a speculative answer, I nevertheless have some moderate confidence in it.

I believe it will probably turn out to be an *optional* parameter to pass.  In the LabVIEW API, one would query for whether Z indexing is enabled using a "DAQmx Channel property node".  The same node is used for all manner of properties across all kinds of DAQmx tasks -- AI, AO, DI, DO, CI, CO.

Consequently, there's an optional argument to feed into the node where one can identify the channel(s) in question for the query at hand.  It can be useful in an AI task because a task can contain many channels, and many of the settings/properties can vary from channel to channel.  The ability to designate which channel(s) you're referring to in the query can be important.

It's not particularly useful when checking on Z indexing for a CI encoder task with only 1 counter channel in the task.  Many devices don't support CI tasks with more than one channel.  However I think there are some that do, particularly in cDAQ.  So it probably isn't dumb or a bug that the text API makes provision for being specific.

I would guess that you can either pass in a single channel used for that encoder task (similar to "Dev1/ctr0") or pass in an empty string to mean "do the default thing -- give me an array of results, one for each channel in the task".   For a 1-channel task, I'd expect the same result either way.  For a multi-channel task, I'd be prepared to allocate 'data' to be able to contain as many values as there are channels in the task.

-Kevin P

[Kamen]

You're probably right, Kevin. I used an empty string and it seems to be working fine. I just hate it when there is no documentation and we're left guessing.

I'll give this a few more days - both to do more testing and to give an NI engineer a chance to see the problem (lack of documentation) before marking it as an answer. Thanks!

Kamen

---

@Kevin_Price wrote:

No need to apologize about a software question.  Most of the discussion in these "hardware forums" is about the programming involved to *use* the hardware. 

Now, while I *only* use LabVIEW, making this a speculative answer, I nevertheless have some moderate confidence in it.

I believe it will probably turn out to be an *optional* parameter to pass.  In the LabVIEW API, one would query for whether Z indexing is enabled using a "DAQmx Channel property node".  The same node is used for all manner of properties across all kinds of DAQmx tasks -- AI, AO, DI, DO, CI, CO.

Consequently, there's an optional argument to feed into the node where one can identify the channel(s) in question for the query at hand.  It can be useful in an AI task because a task can contain many channels, and many of the settings/properties can vary from channel to channel.  The ability to designate which channel(s) you're referring to in the query can be important.

It's not particularly useful when checking on Z indexing for a CI encoder task with only 1 counter channel in the task.  Many devices don't support CI tasks with more than one channel.  However I think there are some that do, particularly in cDAQ.  So it probably isn't dumb or a bug that the text API makes provision for being specific.

I would guess that you can either pass in a single channel used for that encoder task (similar to "Dev1/ctr0") or pass in an empty string to mean "do the default thing -- give me an array of results, one for each channel in the task".   For a 1-channel task, I'd expect the same result either way.  For a multi-channel task, I'd be prepared to allocate 'data' to be able to contain as many values as there are channels in the task.

-Kevin P

---