-200088 error on DAQmx Read

[niNickC]

Hi,

I have been seeing intermittent (eugh) -200088 errors on DAQmx read. (Task specified is invalid or does not exist)

The test rig can run 100s of cycles successfully but every so often I get this error.

It will throw it mid-way through an acquisition but not the same time everytime.

We have 3 similar stations running the same code (slightly different parameters) but this only seems to affect 1 of the 3.

I've seen it on frequency input tasks and RTD input tasks. 

Does anyone have any experience of this?

Any ideas on debugging?

Nick

[Kevin_Price]

Pretty tough to debug your code without, well, the code.

Only 2 vague guesses:

1. You've lost the task refnum somewhere.  Perhaps you have a case structure with a lot of cases, and one rarely executed case passes out a default (null) value instead of passing through the original task ref?   A similar thing can happen if you pass a refnum through For Loop tunnels, and the For Loop auto-indexes on an array that can (rarely) be empty.

2. The task in question gets cleared somewhere, perhaps by some exception handling code?

-Kevin P

[niNickC]

Thanks. Sensible suggestions. 

I've checked for shift registers on all the for loops... no indexing on the references...

The DAQ code is running in a single thread so I can't see how the task can be accidentally cleared. 

Still food for thought... I will check again

  > Pretty tough to debug your code without, well, the code.

ha! yes. Its a pretty large actor based application it'd probably only be helpful to post some snippet which wouldn't really help!

[Kevin_Price]

So the same error code from either of two different kinds of tasks, which I presume are run on two different devices?

Really just spitballing here, but I pay fairly close attention to the DAQ stuff around here and am not aware of this kind of thing as a recurring complaint.  So I'm not quick to point the finger at some flaw in DAQmx.

From my experience with commonplace DAQmx errors, the task ref output will still be a valid task ref, even if the task is in a state that requires stopping before it can be restarted.   But I suppose there *could* be error states where DAQmx has to silently kill the task in the background, rendering the app-level task ref invalid.  I wouldn't count on it, but I can't totally rule it out I guess.

Any other clues about what led up to this situation from your logged data?  Or does it all look just fine until it suddenly errors out?

-Kevin P

[niNickC]

Thanks for your input.

Always great to find the expert on the forum!

Its a single cDAQ chassis.

I did go sniffing for clues but couldnt find anything.

Looking at the codebase again I have spotted something. Its not entirely consistent with my symptoms as it would only effect right at the beginning of a task but maybe my evidence collection was just wrong.

I have a floating 'clear'. I've put a snippet to illustrate. I think this was added at somepoint as we were seeing occasional 'this device is reserved' errors if the rig was shutdown improperly at any point.

This could execute after the create tasks. From what I see, this *shouldn't* cause a problem but maybe task IDs are recycled and sometime I get unlucky. Red herring or?

 

Anyway, I have connected it up to properley serialise the VIs and we'll see.

[Kevin_Price]

That does look like a good place to put some suspicion.  I have a somewhat old and vague memory as well that calls to DAQmx Clear might *start* the process of cleanup and freeing of resources, but that execution might return to your app before that process has finished up.

By memory, this led to a resource already in use type of error even thought the Clear and Create were properly sequenced.  The dirty workaround was simply to pause for 1/4 or 1/2 second between the Clear and Create, after which there were no more such errors.

But as you said, this is the kind of error that ought to show up right at task creation rather than much later.  The "invalid task ref" should only be a secondary error if the task creation initially failed due to resource conflict.

-Kevin P

[mcduff]

---

@niNickC wrote:

Thanks for your input.

Its a single cDAQ chassis.

---

This is along shot, but what error do you get when you unplug the USB? cable to the cDAQ chassis when it is running? That could be the cause of losing the task. I have had issues where it looks like the cable becomes disconnected  due to high CPU use, once an EM pulse would disconnect the connection, etc.

mcduff

[niNickC]

Its an ethernet chassis.

Its a very electrically noisy environment (motor inverters) so I'm worried that this could be a noise issue.

Would I not expect a more descriptive error in this case though?

[niNickC]

I realise that I am resurrecting and old thread here but this is still haunting me every now and again.

I have evidence I missed on first inspection.

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

Its almost like the new task is 'stealing' the reference.

Any thoughts DAQmx guru?

[Kevin_Price]

Not really.  Without a LOT more description of the app, the troubleshooting process, etc. I really don't know how to speculate usefully.  Even with it, I'm not confident I'll have any ideas.  Among the questions that come to mind:

- what task gives you the error?  what's the one you start 2 seconds earlier?

- is one or both of those tasks always involved?  Or can it be more or less any task pair?

- have you tried to manually start that other task mid-run to see if you can force the error?

- are you creating tasks from scratch in code or using tasks defined in MAX or your project?

- did you check on the longshot mcduff suggested to see what error shows up on a disconnect?

- how about if you remove a module mid-run?  (Note: first verify that it's hot-swappable.  I think all cDAQ's are, but I've only done a little bit of cDAQ stuff so you'd better double-check me on that)

- what tasks are on-demand and what tasks use hardware timing?

- do you create a lot of tasks on the fly as this app continues through long run times?

- if so, are you sure you're clearing them?

- any other related observations?  (growing memory use, sluggish UI, etc.)

And so on.  I'm not so much demanding every specific answer above, just illustrating that there's an awful lot of unknowns as seen from over here.  I need a longer story.

-Kevin P