LabVIEW

cancel
Showing results for 
Search instead for 
Did you mean: 

Error -200022 Resource Reserved Using Tasks on Different Modules

Solved!
Go to solution

@nasa-rand wrote:

I could group the AI and Accelerometer channels but the thermocouples and RTDs sample rate is much slower.


In your task, everything is set to 1000 Sa/s.

 

 

[DAQmxTask VPETS ACC]
Channels = VPETS ACC/Acceleration_0, VPETS ACC/Acceleration_1, VPETS ACC/Acceleration_2, VPETS ACC/Acceleration_3, VPETS ACC/Acceleration_4, VPETS ACC/Acceleration_5, VPETS ACC/Acceleration_6, VPETS ACC/Acceleration_7, VPETS ACC/Acceleration_8
SampQuant.SampMode = Continuous Samples
SampClk.ActiveEdge = Rising
SampQuant.SampPerChan = 2
SampClk.Rate = 1000
SampTimingType = Sample Clock

[DAQmxTask VPETS AI]
Channels = VPETS AI/Voltage_0, VPETS AI/Voltage_1, VPETS AI/Voltage_2, VPETS AI/Voltage_3, VPETS AI/Voltage_4, VPETS AI/Voltage_5, VPETS AI/Voltage_6, VPETS AI/Voltage_7, VPETS AI/Voltage_8, VPETS AI/Voltage_9, VPETS AI/Voltage_10, VPETS AI/Voltage_11, VPETS AI/Voltage_12, VPETS AI/Voltage_13, VPETS AI/Voltage_14, VPETS AI/Voltage_15
SampQuant.SampMode = Continuous Samples
SampClk.ActiveEdge = Rising
SampQuant.SampPerChan = 2
SampClk.Rate = 1000
SampTimingType = Sample Clock

[DAQmxTask VPETS RTD]
Channels = VPETS RTD/Temperature_0, VPETS RTD/Temperature_1, VPETS RTD/Temperature_2, VPETS RTD/Temperature_3, VPETS RTD/Temperature_4, VPETS RTD/Temperature_5, VPETS RTD/Temperature_6, VPETS RTD/Temperature_7
SampQuant.SampMode = Continuous Samples
SampClk.ActiveEdge = Rising
SampQuant.SampPerChan = 2
SampClk.Rate = 1000
SampTimingType = Sample Clock
SampClk.src=

[DAQmxTask VPETS TC]
Channels = VPETS TC/Temperature_0, VPETS TC/Temperature_1, VPETS TC/Temperature_2, VPETS TC/Temperature_3, VPETS TC/Temperature_4, VPETS TC/Temperature_5, VPETS TC/Temperature_6, VPETS TC/Temperature_7, VPETS TC/Temperature_8, VPETS TC/Temperature_9, VPETS TC/Temperature_10, VPETS TC/Temperature_11, VPETS TC/Temperature_12, VPETS TC/Temperature_13, VPETS TC/Temperature_14, VPETS TC/Temperature_15
SampQuant.SampMode = Continuous Samples
SampClk.ActiveEdge = Rising
SampQuant.SampPerChan = 2
SampClk.Rate = 1000
SampTimingType = Sample Clock
SampClk.src=

0 Kudos
Message 11 of 16
(162 Views)

As I said in the previous post, the timing was just the default that was there when I inherited this project and I changed it back after trying different values so that I did not have a bunch of changes to the original that had no effect on the problem.

The attached zip contains a MAX config and LabVIEW files for v2024.

DAQ Read TEST VI.vi can be used to demonstrate the problem using the Unmodified enum value or to try variations.  Simple block diagram is easy to follow.  All the cases are the same except for the change noted by the enum value.

The problem is periodic with AI and ACC tasks "handing off" the error about every 2500 mS, TC will throw the error about every 58000 mS and RTD at  about 203000 mS intervals. Disabling any one of the four tasks and the error does not occur.  These timings held true on both the real equipment and the simulated equipment.

 

The fix I am going to use is in the DAQ Read TEST VI Combined Tasks.vi where I am combining the ACC (accelerometer) tasks (3 modules) and the Ai (single module) tasks into a single task.

It is interesting to note that the timing mode property node has no effect on the TC/RTD acquisition time.  The sample clock does.  I have not used these modules very much so I will need to learn more about how they work.

 

Here is a screenshot of the test application showing the time from application start when the error first occurred for each task, and the average interval and which the error occurred. The arrays below the errors show the mS timing of the first occurrence of the error for that cycle.  Once the error occurred in the AI or ACC task it would repeat for the interval amount of time and then the other task would start experiencing the error.  TC and RTD would only experience the error once each interval.

nasarand_0-1742240629364.png

Thanks again for looking at this mcduff, and for the idea of combining all the tasks which led me to the fix I am going to implement.

 

0 Kudos
Message 12 of 16
(126 Views)
Solution
Accepted by topic author nasa-rand

I don't have 2024 on this computer but will look at later when I have it. (Always best to down save to ~2020 so more eyes can look at it.) But I may already know the cause of your problem.

 

From your screen shot and message it looks like you have FOUR separate tasks. But your device only has 3 AI timing engines available and thus can only do a max of 3 concurrent AI input tasks. (It may be only 2 for certain DSA devices.) That would be why combining tasks would work. It also explains your error.

 

Check out this link.

https://www.ni.com/en/support/documentation/supplemental/18/number-of-concurrent-tasks-on-a-compactd...

 

If I am wrong about the number of tasks, sorry.

Message 13 of 16
(116 Views)

Looking at your code and the manual for the 9179, the issue is the number of AI tasks. Below is quoted from the manual:

 

The cDAQ chassis has three AI timing engines, which means that three analog input tasks can be running at a time on a chassis.

 

Hope that answers your question. Combine tasks where possible. 

 

Lastly, if you have multiple tasks with different sampling rates, start the task with the highest sampling rate FIRST. This ensures the largest buffer is used for this task.

Message 14 of 16
(99 Views)

I didn't read all of the topic, but lately I came across this

https://www.ni.com/en/support/documentation/supplemental/18/number-of-concurrent-tasks-on-a-compactd... 

which also states that only three tasks are possible.

 

Edit: Sorry, I now see that mcduff already linked to that page.

0 Kudos
Message 15 of 16
(83 Views)

Thanks mcduff.  It didn't connect for me that RTD and TC modules are considered AI tasks.  I generally combine all my AI into a single task so coincidentally I've never had this problem.  Thanks the article link, very useful.  I've always "assumed" that each module just used its own clock for timing unless synchronizing which would then use the common timing engine.

0 Kudos
Message 16 of 16
(71 Views)