DAQmx Channel Property node for mixed counter task, error 200452

[Jasper88]

Hi Folks,

I've a task where I'm measuring 4 frequencies and 1 encoder (A/B).I want to enable and set the filter on the frequency channels. This works, if I remove the encoder channel from the task, but when I include the encoder channel again, it results in the error below.Error:

 How could I prevent this error for counter tasks? Selecting a channel only works for the analog inputs.

Thanks,

Jasper

[Kevin_Price]

Does it work to specify the "Active Channels" property first, and only wire in the frequency measurement channels?   (I wasn't aware that counter input tasks could be combined in a single task this way.  Is this for a cDAQ system?)

-Kevin P

[Jasper88]

Unfortunately, in "Active Channels" I can only specify the analog inputs, not the counter inputs. And yes, this is indeed a cDAQ system.

[Kevin_Price]

1. I suspect there's a way to get there from here but it may require approaching from a different direction

2. It appears you're making a global task in MAX that you then reference in the LabVIEW code.  I personally almost never do that, but it seems quite plausible to me that certain kinds of properties and things get locked in tighter and are less re-programmable on the block diagram when starting with a MAX task. 

   I generally start on the block diagram with DAQmx Create Virtual Channel.vi and wire in the physical channels for the task.  Using this kind of approach, I know it's possible to configure individual channels differently within a given task.  For me, these differences are usually related to input ranges or scaling for analog channels.

3. I'm not super familiar with some specific things that make cDAQ different than desktop boards.  For example, I've never put multiple counter input channels into a single task.  I didn't think it was supported.   If this is allowed on cDAQ, I don't know the pros and cons.  (Pros would include convenience, Cons *might* include the illusion of better starting sync than what's actually delivered.)

   I definitely wouldn't have expected to be able to put a freq channel and an encoder channel in the same task.  Even if possible, it seems to complicate the process of interpreting the data.

4. In your response you mentioned *analog* inputs for the first time.  I even more definitely wouldn't expect to combine analog channels with counter channels in the same task.

I have to stop short of being definitive of what you can and can't do on the cDAQ and with MAX global tasks.  But I'm pretty suspicious that you might be expecting them to do more than what they can actually deliver.

I'd be inclined to view this as 3 or more tasks.  One for the encoder, one for the analog, and one (or else one per channel) for the freq measurements.   I'd make all of them in code on the block diagram, starting with physical channels and DAQmx Create Virtual Channel.  With that kind of approach, I'm pretty confident there'll be a way to get where you're heading.

-Kevin P

[Jasper88]

I did not mention the analogue channels before because they are in a different task indeed. Having both analogue channels and counter channels is indeed not supported. Frequency inputs and encoder inputs however, are basically the same kind of signal, just the processing is different. (About the starting sync by the way; it's not a big deal for us concerning the nature of our measurements).

The reason for putting as many channels in one task as possible is that we quite often add a sensor at some point, and the code is now written in such way that all that is required to "record" that channel, is to add it to the task. Working with virtual channels would require a lot more programming every time we add some sort of sensor. (It is an r&d hydraulic test bench that is under constant development for testing our prototypes. Since the purpose of the measurements differs from time to time, ad hoc changes are not uncommon.)

What I've also tried: instead of enabling/setting the filter for the frequency channels, setting the filter for the "general" counter channels. This unfortunately, also yields the same error, but then for all of the counter channels in the task.

[Kevin_Price]

I'm taking a couple steps back to take a "big picture" perspective here.

I *do* hear you about the the advantage of being able to change task defs in MAX rather than in code.  I did that before when I was the one who would be running the tests, and it *was* handy.  I went away from it when I started making more test systems for *others* to run, especially stuff used to validate assemblies and devices.  In those cases, pre-defined configurations and locked down version-controlled software were the big priorities.

One HUGE help toward driving both flexibility and pre-defined configurations (via .INI files) is the free, open source utility package from Moore Good Ideas called "MGI Read/Write Anything".   It's been my "magic beans" for over a decade.  If you define a typedef'ed cluster to associate distinct bundles of config information, MGI does all the dirty work of converting between arbitrary clusters and human-readable .INI files.

Now let's zoom back in to the nitty-gritty details.

1. Temporarily comment out all of the filter config.  Can you confirm expected functionality when you combine:

A. multiple freq channels (and nothing else) in 1 ctr task?

B. multiple freq channels *AND* 1 or more encoder channels in 1 ctr task?

I still haven't heard confirmation that your desire to combine ctr channels into 1 task is feasible on your cDAQ system.  I have confirmed that both scenarios above are *not* possible on a PCIe X-series board.

2. The DAQmx API for filter config that you've shown is task-specific (requires a task refnum input), measurement mode specific (this is the root of the property tree used to select the signal to apply filtering),  and functional in nature (terminal to filter is defined by the function it serves in the task rather than by physical PFI # identity).

   Long, long ago in the era of what we now call traditional NI-DAQ, filtering was configured by reference to the physical PFI #, with no reference to measurement mode.  I'm not at a LV box now to check, but *maybe* this method of configuring a filter is still available under a different path down the DAQmx property node trees?

   If so, I'm not sure how how well you can make that approach fit with your desire to maintain flexibility via MAX-based config.

-Kevin P