Error 200587 occurred at DAQmx Start at Task.vi:

[Ibanez]

Hi,

I am having a similar problem to what is described in this post .

It's a pretty simple setup, but I can't get it to work right.

I created a class to help me control the motor of a valve.

One of my method takes in a number of pulses and direction and using DAQmx I set the direction and call another method to generate the square wave.

When I execute everything separate I have no problem [slow enough] when I change the pulses by hand. When I try to put this into a PID loop I get an error. I've tried a couple different approaches, but I'm starting to run out of ideas... Any help I can get I'll much appreciate.

One of my guesses is that I'm trying to send a new pulse[sqw] before the channel is free again, but I got the even after I tried slowing down my pid loop to 5000ms.

DAQ USB-6009, LV2011, Win7

I am using 3 digital out:

- D00 for a software clock [square wave pulse +- 200hz]

- D01 for direction

- D02 for on/off.

---

---

Error 200587 occurred at DAQmx Start at Task.vi:

Possible reason(s):

Requested operation could not be performed, because the specified digital lines are either reserved or the device is not present in NI-DAQmx.

It is possible that these lines are reserved by another task, the device is being used through the Traditional NI-DAQ interface, or the device is being reset. You might also get the error if the specified resource is currently in use by LabVIEW network variables bound to the DAQ Channel, or if the DAQ Channel is being used in any OPC Client software.

If you are using these lines with another task, wait for the task to complete.  If you are using the device through the Traditional NI-DAQ interface, and you want to use it with NI-DAQmx, reset (initialize) the device using the Traditional NI-DAQ interface. If you are resetting the device, wait for the reset to finish.

Device:  Dev1

Task Name: _unnamedTask<3FFB>

---

[Chris-G]

Hi Ibanez,

It's difficult to tell exactly what might be going on based on these screenshots. As the error implies, somewhere in the program there are two DAQmx tasks that are trying to call the same hardware lines. You need to ensure that only one task is being created by the program. It's hard to tell because it looks like you posted two screenshots on top of each other, but do you have the while loop and for loop actually in parallel?

You said you are creating the DAQmx task in the class you are calling. If these loops are running in parallel then that's likely the problem. The class (or Valve subVI possibly) is creating a task using these ports, and then your main VI is also trying to create a task using these ports at the same time. Is the error coming out of the DAQmx task created in the for loop?

Chris G

[Ibanez]

Hi Chris,

Sorry about the screenshot they are a little confusing.

I have my main vi calling a "driver.vi" that sets some flags, and then calls my "clock" vi that output a software generated square loop. [good enough for my application]. When I test everything separte things seem to work fine.

The For loop is generates a Boolean array that represents my signal out. I think the error comes from the start-task before the loop.

"clock" VI is the only VI that writes to that line. [Are the lines indepent from the port? P00, and P01 not related at all, right?]

I was trying to  have my valve class know everything there was to know about Valves and just call the necessary methods to accomplish my tasks. I stopped using labview in version 7 and in my new job I get to use it again with version 2011 and so far I was liking what I was seeing, and I wanted to take advantage of the OO capability of it.

If I can't get it to work this way I might try using queues and have it writing and dequeueing what ever the PID sends...

Thanks you for your help,

[Chris-G]

Hi Ibanez,

Without diving too deep into exactly what the deeper layers of your code are doing, I think I may see the issue. The different lines are effectively independent as long as you are only writing to one line. So, you can have one VI/Task writing to Dev1/port0/line1 and another writing to Dev1/port0/line1. However, each of these DO tasks must be configured such that the line grouping has one channel for each line.

In your second screenshot, you have the DO task configured for one channel for all lines. Depending on the value in the Lines control, the DO DAQmx task may be trying to access all of those lines. This might be why the error is coming up.

To clarify, the following two VIs accessing different lines on the same device can successfully run at the same time:

However, the following two VIs cannot run at the same time:

Running these second two VIs gives error 200587.

Again, it's difficult to know exactly what is causing the VI to access the same line twice without digging deeper, but this looks like a possiblity.

Hopefully this helps!

Chris G

[Ibanez]

Hi Chris,

Thank you for the clarification that was very helpful. The example + your comments are helping me demystify tasks and DAQmx.

I tried adding the "one channel for each line" to all my tasks, but no love there. I was trying the same concept than the example, but using a finite FOR loop to get the sqw. So I can send the stepper motor to the desired position as needed. If comment out the clear task vi at the end of that task I stop getting the error, but also I think I stop controlling that output.

I also tried using as the example shows it by creating and the clearing the task "once" and using a while loop and queues to get new values inside plus a little extra logic. [consummer/producer]

When I use queues and while loops things seemed to work fine. I think I might be able to still find a good balance for using classes and old school lv. [I'm jumping from lv7 to 2011, I wanted to take advantage of the OOP]

Maybe I need go back to the "drawing board" and plan it better, but I would still like to know why isn't working as it stands.

Again thank you for helping me out.

[Esteban_B · Accepted solution]

Hi Ibanez,

The suggested VI should work, and if you write one channel for each line, that should work too. In resume what will be the main task that you would like to achieve?

Regards,

[Ibanez]

Hi Steve,

Well my final objective is to be able to profile a valve I got. Ranges and how accurate and repeatable every step is. It's not a fancy project at all, but I was trying to set it up so in the future if/when I am ask to integrated into another system or test other valves I would have most of the work done already. [building a library] I decided to postpone the use of classes for now. Since the project it's so small. I might try again later.

I think your advice solved my problem also I think I might have had scope-ing problems in my code. I should be able to test it live by the end of the week and find out of wack my code is

I am curious about best practices when it comes to send/receive data from DAQmx?  I got the impression that people were frowning at me creating/stopping/cleaning my tasks at every call.

I saw from the examples posted and the help, that they all use loops creating and stopping tasks at the beginning and end of life cycle of it.

Is this the recommended implementation?

How is the data transferred in and out the loops? [using Queues? And logic to keep it "synchronized"]

Thank you for your help,

Cristian

[Chris-G]

Hi Christian,

Yes. In general, it is recommended that you don't create, stop, and clear the task at every call if you are continuously acquiring from (or writing to) the hardware. The main reason for this is to save time. Creating and clearing the task every iteration will slow down the execution rate of your program. For this reason you typically only have the DAQmx Read/Write inside the loop. The task will remain open as you iterate through the loop, and then close once you exit the loop at the end.

In terms of the data itself, there is a hardware buffer that stores the data as its acquired. The software then pulls the data from that buffer. This compensates for any non-deterministic processes in the OS that would otherwise cause the SW to miss samples. The data itself doesn't need to be passed between different iterations of the loop. What is passed between the different iterations is the reference to the hardware. This essentially just means that the VI maintains its line of communication to the hardware while it is running inside the loop.

Hopefully this helps,

Chris G