Error -200587 arrghhh

[Chrispbrown2255]

---

Error -200587 occurred at Recording Data.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: Dev2

Task Name: _unnamedTask<33>

---

The project was mostly written by a student on a summer placement, and to be fair he did really well, there are just a few small bugs remaining to be worked out.  However there is one that I cannot resolve.

I am getting the above error when I try to run the program.  The first run through is always OK, however when I try to perform a second run and call the 'recording data.vi' a second time I get the above error.

As far as I can tell the only place that this particular line gets written to on the DAQ is in the recording data.vi, and there shouldn't be anything else running in parallel trying to access port 1 line 3 on the device.

Any suggestions on where to look would be much appreciated.

[James.M]

If something runs once and it's okay, but throws an error the 2nd time then it's most likely a close-out issue. Make sure that the DAQmx tasks are all cleared at the end of the program, or when they are no longer needed.

Which VI in this project is the main program? Usually you have one top-level VI that is at the top level of the project and all the subVIs are in folders.

Nevermind figured that out.

It looks like there's not much dataflow control in this project. Each VI is it's own entity and doesn't share references with the others. Your issue is in Recording Data.vi, which utilized a DAQ Assistant and some native DAQmx VIs. Your DAQmx code in general seems to be doing a lot of mix-and-match with express VIs.

If you want to really improve this software, you would track down all of the DAQmx code work with your data flow to group all of the references together. Ideally you would create all of your DAQmx tasks at the start, read and write to them during the program, and then clear them at the end.

The simple fix is probably just to close that task in Recording Data.vi at the end. The DAQ Assistants automatically take care of the tasks they work with, but your native DAQmx VIs in that VI don't.

[Chrispbrown2255]

Thanks, I'll look at closing off the native VI's.

I will also think about creating tasks on initialisation then just referencing them as I need them.

I'm sure there are many many improvments to efficiency to be made.  At this moment I jsut want it to work though, then I'll focus on tidying it up.  This is what happens when someone hands over a project and it isn't picked up for 5 months.

[ben64]

I think DAQ Assistant terminates the task automatically if not set to run continuously. However there are some task that are not terminated in your code so the ressource will not be available at the second iteration. See following screen capture.

Ben64

[James.M]

---

@ben64 wrote:

I think DAQ Assistant terminates the task automatically if not set to run continuously. However there are some task that are not terminated in your code so the ressource will not be available at the second iteration. See following screen capture.

Ben64

---

Yup, Ben is pinpointing the native VI that needs to be followed with a task clear. I would like to reiterate, this is not the best way to do this. You take a performance hit with starting and stopping tasks all the time. If this performance hit isn't an issue, then your job is done quick. 

[ben64]

Totally agree with you James, this is the quick fix. I didn't went throught the multiple vis I just open the recording one and from what I've seen it probably is a non negligible task to correct everything.

Ben64

[Chrispbrown2255]

Thanks Ben and James,

  I've not looked yet, that's my job for this afternoon when I get back to the lab.

Out of interest though

---

James.Morris wrote: 

Yup, Ben is pinpointing the native VI that needs to be followed with a task clear. I would like to reiterate, this is not the best way to do this. 

---

In this case the performance hit isn't an issue, however if it were how would I correct it?

Can I have multiple tasks running but have each task address a line on the DAQ individually?  So in theory for the DO's on my DAQ I could have 8 tasks (one for each line) running simulataneously?

[ben64]

---

@Chrispbrown2255 wrote:

Thanks Ben and James,

  I've not looked yet, that's my job for this afternoon when I get back to the lab.

Out of interest though

---

James.Morris wrote: 

Yup, Ben is pinpointing the native VI that needs to be followed with a task clear. I would like to reiterate, this is not the best way to do this. 

---

In this case the performance hit isn't an issue, however if it were how would I correct it?

Can I have multiple tasks running but have each task address a line on the DAQ individually?  So in theory for the DO's on my DAQ I could have 8 tasks (one for each line) running simulataneously?

---

Usually the good way is to start a task before a loop, to read or generate the values inside the loop and to stop/clear the task after the loop. The exception is when you need to reconfigure the DAQ between iteration to perform a different task.

As for the multiple task question it depend on the type of task (and of the module/DAQ). For a multifunction DAQ you can perform a digital I/O task and an analog task simultaneously but can't run 2 digital I/O task simultaneously) You will generally not be able to have 8 tasks running simultaneously for each line. For that you create a task that include the 8 lines (you will read an array of 8 values instead of a single value).

Ben64

[Chrispbrown2255]

Thanks Ben.  I'll take note of that for future work.

However in this case I am no closer to solving this issue, I am still getting the -200587 error when I try to run the task for a second time.

I have found all tasks that write to the DO's and changed them to native vi's and put a stop task and clear task at the end of each task.

There are two things that I am finding really strange:

1) This is only affecting this DO task, other DO tasks start/stop as many times as I need without issue.

2)  I am sure that this used to work on this computer with this exact DAQ module.

[James.M]

Now that you have everything as native DAQmx VIs, do you have smart names for the tasks? The error you included with this post was generated at an unnamed task, so it's hard to narrow it down within Recording Data.vi. Narrowing down to a specific task might help. Also, please include your new code.