-200088 error on DAQmx Read

[mcduff]

Don't think this applies to you, but ...

I am in the process of writing a program to control multiple DAQmx Devices. Some issues that would lead to a "disconnected" task (don't think they apply to you but will list anyway):

1. Simulated Devices disconnect when running at a high sampling rate. The problem is the CPU is both making and consuming the data. My low-end laptop sometimes not good enough with all the company stuff running in the background. This would occur when I had multiple channels with each above 1MSa/s.
2. I am scanning for instruments in the background, to see if any new instruments are connected or disconnected. Using a full scan with the System Configuration tools would sometimes disconnect the scan. The better option is using the DAQmx System property node along with the DevNames and only using the System Configuration tools when absolutely necessary. I haven't had an issue since I made the switch.
3. When testing with a real device, USB-4431, I would get disconnects when IT would push updates, during WebEx, similar to Zoom, meetings, etc.
4. Lastly, another long shot, check your AV settings make sure the Firewall or whatever network protection is not dinging your ethernet device.

mcduff

[mcduff]

---

@niNickC wrote:

The error is coming 2 seconds after a different DAQ task is created in some async process.

---

Is this a different task on the same device, for example AI for first task, AO for second? I should have added to the list, reading properties from a Task sometimes can be problematic.

Not sure about your program, but here's a suggestion, Create Both Tasks at the beginning of your program before starting any of them, then just start the tasks when needed.

mcduff

EDIT: Create Both Tasks at the beginning of your program and RESERVE THE TASK before starting any of them

[niNickC]

So this is an actor framework based application.

I have actors which create a single task based on some external trigger. There are analog input actors and frequency input actors. They all run continuous hardware timed acq. Once they have finished their work they clear the DAQmx tasks.

These actors can be spawned at different times.

One actor can be happily doing its task then will throw the error when a different once creates its task. It doesn't always do this and sometimes they run just fine.

Note that groups of actors are instructed to create tasks simultaneously on the same chassis (say 2 AI and one CI). This happens without error. Its when an actor creates a task on a different chassis one of the other running tasks will crap out. I've seen it happen to the AI and CI tasks. (I hope thats clear...)

I can always re-create the tasks without error (this is my workaround, I just catch this error and try again but it would ne nice to know whats going wrong).

I have some feeling that the driver is reusing session IDs or something...

Thanks for all your input.

[BertMcMahan]

Sounds like a race condition, which will be very hard to track down unfortunately.

Make sure your task creation error handling is bang-on. In other words, don't discard errors. For example, if your error *actually* happened at Create Task, but that error didn't propagate, then your next task would fail with your "task does not exist" error despite not being a problem there.

I'd look for things happening that normally execute back to back and that you depend on happening in quick succession, but that COULD be bottlenecked by a non-reentrant common VI shared among multiple actors, or with a functional global/action engine VI that has the wrong reentrancy settings. In fact, if you're using shared clone reallocation in a functional global, then this could cause the issue you're seeing when it spawns a new clone. If there are any functional globals in your code, make sure they're preallocated clones, though beware: they will NOT be cleared across actor restarts. This is a general note with uninitialized shift registers; they will persist across actors if they share an instance.

Basically, check for code that you assume to be executed back to back but that COULD have something else steal a reference and for uninitialized shift registers (including functional globals).

You may have mentioned this earlier but could you at least provide your DAQ actors so we could see them?

Also, do you have the Desktop Execution Trace Toolkit? That might help.

[niNickC]

Thanks for the reply.

Error propagation is pretty sound, I have seen errors generated from all parts of the task through the development of the project.

I find myself coming back to a post I made earlier in this thread concerning this bit of code:

My initial concern was with sequencing here as it was floating but maybe this is the cause altogether. Maybe a DAQmx task reference is being reused somewhere by a clone. The initial reason for it was to try and remove occasional 'device is reserved' errors during improper shutdown but maybe this should only be done IF there is an error on initialise. Any thoughts Bert?

The code has become a bit 'rube goldberg' over time but I will see if I can post something

No Desktop Trace Execution Toolkit I'm afraid.

[BertMcMahan]

I don't think it reuses task names, unless it's a bug. The Help specifically mentions that not specifying a task name will create a unique task.

Unfortunately I don't have a DAQ handy, and creating tasks with simulated DAQ's isn't particularly helpful.

I'd try a couple things. First, have all of your actors that use the task inspect the Task name and see if it equals an empty task name. If it does, have it send a message or log something somewhere. You should be able to see the moment the reference gets killed, unless something is killing it in a background process or something.

I don't see an issue with your code as posted unless, like you said, it's reusing task names but I don't think that's the case. The fact that it always happens when one card tries to make a task on another card makes it sound like some sort of race condition, and I'm a little confused as to why one AI actor is making another AI actor on a different card.

[mcduff]

---

@niNickC wrote:

Thanks for the reply.

Error propagation is pretty sound, I have seen errors generated from all parts of the task through the development of the project.

I find myself coming back to a post I made earlier in this thread concerning this bit of code:

My initial concern was with sequencing here as it was floating but maybe this is the cause altogether. Maybe a DAQmx task reference is being reused somewhere by a clone. The initial reason for it was to try and remove occasional 'device is reserved' errors during improper shutdown but maybe this should only be done IF there is an error on initialise. Any thoughts Bert?

The code has become a bit 'rube goldberg' over time but I will see if I can post something

No Desktop Trace Execution Toolkit I'm afraid.

---

I'm a little more compulsive about closing/starting tasks, I would do the following to stopping a task, then make a new one (I use this is my program without issues). Your Snippet does not work for me.

mcduff

[RHadley]

I've been working with Nick on this issue privately within a Service Request, and we have found an explanation for the error that we have seen, and a method to workaround this issue in future.

In order the prevent the application from returning the Task is Reserved error if the application is shut down incorrectly, Nick's task creation code calls the DAQmx Clear Task VI for the reference used in the previous instance of that Task before creating a new instance of that task.

Having tested the process of repeatedly creating and clearing tasks, I found that these task references continue to iterate when creating and clearing tasks at runtime, or when stopping and starting a VI, or even through opening and closing the VI. However, I found that if the VI is aborted and then all LabVIEW processes are closed, the task references reset to 0, and iterate from there.

As such, my conclusion is that in this instance, when users aborted or shutdown Nick's Application was unexpectedly, Actors which handled creating were saving the references. Most of the time, this would be fine, but occasionally, the reset Task Reference number counter would assign a task with the same reference number as one saved by one of the Actors. If this Actor was called to create a new task while a task with the same reference as its saved reference was running, this would lead to the -200088 error that was being seen.

As such, I put forwards a pair of workarounds that I recommend to anyone who has this issue in the future:

1. It is possible to manually assign task names, which will then not use assigned references.
2. Manual error handling can be used to filter for the Task is Reserved error, and then clear that specific reference, as demonstrated in the VI snippet attached below.

 

[BertMcMahan]

Wow, that one must've been tough to find.

So if I understand you correctly, the Actors were manually saving values to some external file at some point, then when the whole application was restarted, the Actor could take that previous task reference upon initialization, then it would always try to close out the old "dangling" task from the last time it was run... which could actually be the same reference number that another task had. Is that right?

[mcduff]

---

@BertMcMahan wrote:

Wow, that one must've been tough to find.

So if I understand you correctly, the Actors were manually saving values to some external file at some point, then when the whole application was restarted, the Actor could take that previous task reference upon initialization, then it would always try to close out the old "dangling" task from the last time it was run... which could actually be the same reference number that another task had. Is that right?

---

Not sure if I understand correctly, but this is my understanding...

If the program was not shutdown correctly, maybe a CRT-ALT-DEL stop etc, then the tasks (or task list) may not properly close all the references. Usually no problem, but there could be a name collision for the task when restarted. This clears that possibility. I think I have seen something similar in the past with named tasks, I was using the same name; I would need to restart the computer to get rid of that error. Will try the work around.

@RHadley

Is there a private method to query all the current tasks? There is nothing in the open, only to query saved tasks. Maybe an idea exchange?

mcduff