Create DAQmx Channels consecutively

[mcduff]

---

@Quiztus2 wrote:

This looks maybe weird, but this would keep my HAL design easy.

---

I don't know anything about your HAL, but you DAQ loop could have some issues.

1. samples per channel specifies the number of samples to acquire or generate for each channel in the task if sample mode is Finite Samples. If sample mode is Continuous Samples, NI-DAQmx uses this value to determine the buffer size. HINT -> Leave it blank, let DAQmx determine the buffer size. This helps if you later change the sample rate.
2. You specify the channels then read them later for your Map. Physical Channels may not always be the same as the channel name. Why bother to specify them and read them later, just use the values you specify in the beginning.
3. Specify the number of points to read in your loop, use the DAQmx Read function. This has the following advantages, your loop rate will be controlled by the hardware task, not a timer, and in the future you can abstract you sample rate instead of hardwiring it for 10 Sa/s. It's good practice to read about 100 ms of data at a time. Now if your HAL wants data at a faster rate, you don't have to change anything.
4. You could acquire continuous data with an event, look in the examples for it. That way, your user could stop acquisition when they want, rather than 10 loops of data.

[Quiztus2]

---

@mcduff wrote:

---

@Quiztus2 wrote:

This looks maybe weird, but this would keep my HAL design easy.

---

I don't know anything about your HAL, but you DAQ loop could have some issues.

1. samples per channel specifies the number of samples to acquire or generate for each channel in the task if sample mode is Finite Samples. If sample mode is Continuous Samples, NI-DAQmx uses this value to determine the buffer size. HINT -> Leave it blank, let DAQmx determine the buffer size. This helps if you later change the sample rate.
2. You specify the channels then read them later for your Map. Physical Channels may not always be the same as the channel name. Why bother to specify them and read them later, just use the values you specify in the beginning.
3. Specify the number of points to read in your loop, use the DAQmx Read function. This has the following advantages, your loop rate will be controlled by the hardware task, not a timer, and in the future you can abstract you sample rate instead of hardwiring it for 10 Sa/s. It's good practice to read about 100 ms of data at a time. Now if your HAL wants data at a faster rate, you don't have to change anything.
4. You could acquire continuous data with an event, look in the examples for it. That way, your user could stop acquisition when they want, rather than 10 loops of data.

---

Thanks for sharing. I will consider your points. I plan to share the HAL design later here in a new thread when it is more mature.

[Quiztus2]

---

@mcduff wrote:

---

@Quiztus2 wrote:

My HAL design unfortunately doesn't support that.
Could I create 2 seperate tasks, running in parallel on the same device instead?

---

No. Only 1 AI hardware timed task per device.

EDIT: This won't help your problem, but you should specify the number of points to read per call instead of waiting 1 s like in your example.

---

It turned out this statement is wrong. NI just told me that it is fine to have two different tasks to run in parallel.

[santo_13]

---

@Quiztus2 wrote:

---

@mcduff wrote:

---

@Quiztus2 wrote:

My HAL design unfortunately doesn't support that.
Could I create 2 seperate tasks, running in parallel on the same device instead?

---

No. Only 1 AI hardware timed task per device.

EDIT: This won't help your problem, but you should specify the number of points to read per call instead of waiting 1 s like in your example.

---

It turned out this statement is wrong. NI just told me that it is fine to have two different tasks to run in parallel.

---

Factual answer is "it depends" on the hardware, majority of NI DAQ hardware support only 1 hw-timed AI task due to the availability of only ONE timing engine. Some special hardware, typically the ones with sigma-delta convertors have more than one TE and thereby can have more than one hw-timed tasks running simultaneously.

[Quiztus2]

AI means Analog In, yes? What about Counter? Is there maybe a difference? However, I couldn't try it out, yet.

[mcduff]

---

@Quiztus2 wrote:

AI means Analog In, yes? What about Counter? Is there maybe a difference? However, I couldn't try it out, yet.

---

Yes, there is a difference; they are spelled are pronounced differently. 🙂

You can have concurrent AI, AO, counter tasks, but for the majority of DAQmx hardware only one AI, AO, or counter task at a time. For example, you can have a AI and AO task, but not two AI tasks. There are some PXIe boards that offer more than one task, but these are the exception.

[Kevin_Price]

Sorry mcduff, but Cap'n Counter needs to make a correction...

---

@mcduff wrote:

---

You can have concurrent AI, AO, counter tasks, but for the majority of DAQmx hardware only one AI, AO, or counter task at a time. For example, you can have a AI and AO task, but not two AI tasks.

Counters are something of an exception.  Take the common X-series multifunction boards as a fairly typical example.  Generally speaking, the following holds true:

1. Only 1 hardware-timed task at a time possible for AI, for AO, for DI, and for DO.  This is because there's only 1 timing engine available for each of these I/O types to support hardware-timed acquisition.   But as mcduff mentioned, you *can* have 1 each of AI,AO,DI,DO at the same time.

2. Multiple software-timed tasks at a time possible for AO, DI, DO.  Not for AI, at least not on a multiplexing device.  (I'm not sure about this on simultaneous-sampling MIO devices, I haven't ever tried.)

    I don't totally trust my memory on this, but I *think* I recall that having a hardware-timed task running for AO prevents you from simultaneously doing software-timed AO on another channel.   The rules for DI, DO are (I *think*) more device dependent and the degree to which configurations apply to full ports vs individual lines.

3. You can generally run 4 simultaneous counter tasks on an X-series board, any combo of CI, CO, hardware-timed, software-timed.  Each task uses 1 of the 4 built-in counters, each one of which has lots of independent timing control available.  This flexibiilty remains true regardless of what you're doing with the other AI,AO,DI, and DO.

-Kevin P

[mcduff]

---

@Kevin_Price wrote:

Sorry mcduff, but Cap'n Counter needs to make a correction...

---

Did not know that. Thanks.

[mcduff]

Actually, the number of AI tasks may NOT be necessarily be one per device, depending on your definition of device. (Is a chassis a device or is the module the device?)

Current cDAQ chassis do NOT have a timing engine for each module. So it is possible to have 4 or 8 modules in a cDAQ chassis and not have 4 or 8 independent AI tasks.

From the manual

(cDAQ-9174/9178)

The cDAQ-9174/9178 has three AI timing engines, which means that three analog input tasks can be running at a time on a chassis. An analog input task can include channels from multiple analog input modules. However, channels from a single module cannot be used in multiple tasks.