DaqMX timing with DI and DO tasks

[GOB34]

I have a question about applying sample clocks to multiple tasks, as I keep getting errors. I know this is a fundamental issue that I am misunderstanding, so I appreciate everyone's help and suggestions.

I am using multiple CDaq chasis with multiple AI, Thermocouple and DIO modules.

I have created 4 tasks:

1 for all AI

1 for all TC

1 for all DI

1 for all DO

When I run the code pictured above, it works. When I try to apply timing to the DI and DO modules, though, I get an error that the hardware conflicts. I applied continuous samples with the same rate that is wired into the AI and TC tasks.

I've researched into the issue and tried some of the examples, but I am still a bit baffled.

I want to avoid having an uncontrolled data rate from my DI and DO modules which could overwhelm the system.

How can I assign timing to those tasks?

Also, should I fundamentally change the framework I am using for the tasks?

Thanks for all the help.

[santo_13]

What cDAQ chassis do you use?
https://www.ni.com/en/support/documentation/supplemental/18/number-of-concurrent-tasks-on-a-compactd...

Have you tried a very basic example that generate/acquire hardware timed task per type (AI, AO, DI, DO) for all types?

[GOB34]

Hi -

I appreciate your help!

It is a cDaq 9189.

Hardware Timed Tasks	# of Tasks per Chassis	# of Tasks per Module
Analog Input	3*	1
Analog Output	1	1
Counter Input/Output	4, 6†	4, 1‡
Digital Input	1	1
Digital Output	1	1

I am using 2 chasis's.

I am trying to use 2 DIO modules (both are 9403).

Both of these modules are on the same chasis.

Should I change the timing source on the sample time settings?

I tried that a bit but still got the error - but maybe I missed something.

[GerdW]

Hi GOB,

---

@GOB34 wrote:

I am trying to use 2 DIO modules (both are 9403).

Both of these modules are on the same chasis.

---

The table shows "1 DI task per chassis" and "1 DO task per chassis".

And it says "only one DI/DO task per module".

Those are the rules.

Unfortunately all the details of your implementation is hidden in a subVI - and you don't provide information on that subVI…

[GOB34]

Thanks for the reply @GerdW.

 I understand the limitation noted in the table, the thing is it works when I don’t include the timing for the DI and DO tasks - so i don’t see how it is an issue with number of tasks but more I am messing up some timing setting.

If I don’t specify the timing for a DI or DO module, and I am using a producer/consumer QMH structure like the “continuous measurement and logging(daqmx)” template, then what rate is it running at?

Regarding any sub VI - there is nothing else going on besides the tasks get initiated (with false and then the task references brought in here.

Appreciate the help!

[GerdW]

Hi GOB,

---

@GOB34 wrote:

I understand the limitation noted in the table, the thing is it works when I don’t include the timing for the DI and DO tasks - so i don’t see how it is an issue with number of tasks but more I am messing up some timing setting.

---

The timing engine is the limiting part in here: this engine only supports a limited number of tasks…

---

@GOB34 wrote:

If I don’t specify the timing for a DI or DO module, and I am using a producer/consumer QMH structure like the “continuous measurement and logging(daqmx)” template, then what rate is it running at?

---

It will run at the rate of the measurement/producer loop: when you don't set a timing in the DAQmx task then you should set a timing in your producer loop…

[GOB34]

Could I make the DI and DO one task?

[GerdW]

Hi GOB,

---

@GOB34 wrote:

Could I make the DI and DO one task?

---

How would you distinguish between inputs and outputs when using DAQmxRead/DAQmxWrite on your task?

No, you cannot mix inputs and outputs within one task…

[GOB34]

OK, so in the future with this hardware, I will need to separate DI and DO onto different modules in order to get hardware timing. I can't do that for my current project.

That is somewhat limiting and frustrating but I understand now!

Also annoying because it effects the rest of the system timing wise -

i.e. I am acquiring from all tasks in the same loop - all the other input modules have timing set via hardware.

Now I have this "rogue" other DI module that does not have hardware timing possible. So I have to introduce a wait because of that module.

[GerdW]

Hi GOB,

---

@GOB34 wrote:

it effects the rest of the system timing wise - i.e. I am acquiring from all tasks in the same loop

---

NOBODY enforces you to put all DAQmx code into just one loop!

I usually use one loop per task…