Counter/Timer

cancel
Showing results for 
Search instead for 
Did you mean: 

DAQmxCreateCIDutyCycleChan error when using C functions

Hello, I am new to the forum so I am not sure where to post my question, I hope someone can help me.

 

I am trying to measure a PWM duty cycle using the C functions for DAQmx, but I am having trouble creating a Channel for this purpose. I can successfully read the duty cycle using the MAX task interface.

Does anyone have a code example? I'm guessing there is an issue with the parameters I'm using with DAQmxCreateCIDutyCycleChan, I've been testing with the "counter" and "max/minFreq" parameters, trying several combinations like Dev1/ctr0/PFI1Dev1/ctr0, Dev1/PFI1 or Dev1/portctr0/line2 for Counter and using Hz or Time for min/maxFreq. Usually I'm getting error codes like 22, 17 or 18.

Thanks in advance.

0 Kudos
Message 1 of 9
(2,677 Views)

Update:
The error codes are actually -200430 (DAQmxErrorInvalidPhysChanType) or -200431 (DAQmxErrorPhysChanMeasType), so the "counter" parameter is the one that seems to be the problem.
I am using a USB-6251 M series DAQ. The duty cycle is correctly measured using PFI1/P1.1 (pin 10) in the MAX task interface.
Is a Pin configuration required before using said pin to measure a PWM duty cycle using the C functions? I've tried using "Dev1/PFI0" to "Dev1/PFI14" with the same error code for all cases:  -200430

"Dev1/ctr0" and "Dev1/ctr1" return error code -200431

0 Kudos
Message 2 of 9
(2,625 Views)

Dunno if this is the whole solution, but hopefully it helps get you closer.

 

Syntax for a counter channel would look like: "Dev1/ctr0"

Syntax for a terminal or signal source would look like: "/Dev1/PFI0".  Notice the subtle but important leading '/' character.  Important but not at all obvious, and it's a recurring issue that folks keep running into.  Not sure why NI did things this way...

 

 

-Kevin P

CAUTION! New LabVIEW adopters -- it's too late for me, but you *can* save yourself. The new subscription policy for LabVIEW puts NI's hand in your wallet for the rest of your working life. Are you sure you're *that* dedicated to LabVIEW? (Summary of my reasons in this post, part of a voluminous thread of mostly complaints starting here).
0 Kudos
Message 3 of 9
(2,617 Views)

Hello Kevin, thank you for your reply!

Unfortunately error code -200430 keeps popping up with or without the "/" before Dev1/PFI1, and -200431 for Dev1/ctr0.

Would you happen to know which one of the two should be used for a Duty cycle measurement? Counter or PFI? When using the MAX interface it doesn't seem to matter whether I'm using ctr0 or ctr1, it starts reading the PWM until I specify PFI1.

Here's how I'm using the C function:

DAQmxCreateCIDutyCycleChan ( taskHandle, "/Dev1/PFI1", "PWMread", 100.0, 5000.0, DAQmx_Val_Falling, NULL );

 

Thanks in advance

0 Kudos
Message 4 of 9
(2,610 Views)

I don't use the DAQmx text-based API, but that function sure *looks* like it configures a counter *channel* so I'd look to use "Dev1/ctr0" as the 2nd argument there.

 

Other API functions are available to define the *terminal* where the PWM signal can be found.  That would be the function where I'd look to specify "/Dev1/PFI0".  (This are often optional function calls.  If never called, a specific default terminal will be assumed.  That default can vary from device to device.)

 

The -200430 error is an error specifying the channel type.  It makes sense you get that when specifying the *terminal* PFI0 where it wants the *channel* ctr0.  The -200431 error suggests that ctr0 (and probably any other counter) on the device you're using doesn't support the "DAQmxCreateCIDutyCycleChan" function.

 

Over in LabVIEW land where I operate, I've never come across a "Duty Cycle" counter task, not explicitly by name.  Over there, I've seen "Pulse" measurement tasks and "Semiperiod" tasks, either of which deliver both high and low time data making it possible to *calculate* duty cycle.

 

It's possible you're using a "Duty Cycle" API function that isn't widely supported and that you need to use a function using terminology more like "Pulse" or "Semiperiod".  Mind you, this is just a semi-educated guess.

 

 

-Kevin P

CAUTION! New LabVIEW adopters -- it's too late for me, but you *can* save yourself. The new subscription policy for LabVIEW puts NI's hand in your wallet for the rest of your working life. Are you sure you're *that* dedicated to LabVIEW? (Summary of my reasons in this post, part of a voluminous thread of mostly complaints starting here).
0 Kudos
Message 5 of 9
(2,598 Views)

Yes, after some reading I was coming to the conclusion that a counter should be used as a parameter. 

 

Would you happen to know which APIs could be used to define the *terminal* where the PWM signal can be found? I've seen the term "NI-DAQmx channel attributes/properties" thrown around, but I'm guessing it's part of some GUI rather than an API. I suppose I need to specify a counter and then a specific terminal to read.

 

Regarding error code -200431, I would assume the same: neither counter 0 nor counter 1 support the duty cycle function, but both counters work on the MAX interface and are also mentioned in the manual.

 

I've taken a look at other C functions that may help, and since this morning, I've been trying to read the signal using DAQmxCreateCIPulseChanFreq, with identical results: error 200430/1 for fpi/counter. Maybe I'll try out some other ones.

 

Thanks

0 Kudos
Message 6 of 9
(2,591 Views)

Sorry, I only use LabVIEW and don't know anything about the available functions or specific syntax in the text API.

 

In LabVIEW, there are numerous DAQmx properties (channel properties, timing properties, buffer properties, trigger properties, etc.) that are accessible as part of the API.  I suspect they're in the text API too, but I don't know what to look for.

 

What device are you using?  And can you find a DAQmx function that includes a term like "SemiPeriod"?  That particular measurement mode has been around in NI devices for a *very* long time.  The mode known as "Pulse" measurements is newer (though it's probably been around somewhere near a decade now) and may not be supported on older devices.

 

 

-Kevin P

CAUTION! New LabVIEW adopters -- it's too late for me, but you *can* save yourself. The new subscription policy for LabVIEW puts NI's hand in your wallet for the rest of your working life. Are you sure you're *that* dedicated to LabVIEW? (Summary of my reasons in this post, part of a voluminous thread of mostly complaints starting here).
0 Kudos
Message 7 of 9
(2,577 Views)

So far I've tried using the following C functions:

- DAQmxCreateCIDutyCycleChan

- DAQmxCreateCIPulseChanFreq

- DAQmxCreateCICountEdgesChan

- DAQmxCreateCITwoEdgeSepChan

All of them have "counter" as a parameter, and all of them return error code -200431 either with ctr0 or ctr1.

 

The good news: DAQmxCreateCISemiPeriodChan seems to be working, or at least it doesn't return an error code.

 

The bad news: I still need to figure out how to associate a terminal to the SemiPeriod counter.

 

In the MAX interface, you first need to select a counter and then an input source or terminal, so I'm guessing this should be similar.

 

Thanks again for your help!

0 Kudos
Message 8 of 9
(2,568 Views)

What DAQ device are you using?

 

"Count Edges" functionality is the absolute most basic possible counter capability.  On certain cheap USB devices, it's the one and only counter mode that's supported.  It strikes me as very odd that "SemiPeriod" seems to be supported while "CountEdges" isn't.  The other error cases are less surprising.

 

For reference, common devices that support "SemiPeriod" have been around at least about 25 years (E series and later), "TwoEdgeSep" devices for about 15 (M series and later), "Pulse" devices for only about 8-10 (X series and later).  Dunno about "DutyCycle" devices, I've never encountered that task type (though again, the same *information* can be derived from "SemiPeriod").

 

Sorry I can't help with the syntax for specifying a terminal.  An alternative is to physically wire to your device's default terminal.

 

 

-Kevin P

CAUTION! New LabVIEW adopters -- it's too late for me, but you *can* save yourself. The new subscription policy for LabVIEW puts NI's hand in your wallet for the rest of your working life. Are you sure you're *that* dedicated to LabVIEW? (Summary of my reasons in this post, part of a voluminous thread of mostly complaints starting here).
0 Kudos
Message 9 of 9
(2,562 Views)