LabVIEW error -200284

[KSINADA]

Hello all, 

I have a labview -200284, program was running without any issues for a very long time. we got max data base corrupted error, NI configuration manager and NI device loader not running on system config. but were are able to recover from these. 

could it be a software issue given that no one touched the program? what are some of the solutions I could try out?

Thanks in advance. 

Khalid

[Kevin_Price]

Can you post the code?  There are *way* too many possible causes to start speculating without it.

Have you had any long successful runs since recovering from the MAX database and other errors?  Or did the -200284 start showing up immediately *after* those recoveries?

-Kevin P

[KSINADA]

I can't post the code its too big file beside we didn't mess with the code at all, however after recovering from corrupt MAX database error we didn't have a successful run at all.

[Kevin_Price]

Well, it sounds like the recovery process made a change to your system configuration somewhere.

That particular error code is a DAQmx timeout.  It gets thrown if a call to DAQmx Read has to wait too long to accumulate the # of samples requested.  Both timeout value and #  of samples are values that can be specified by the programmer.  Unfortunately however, neither seems particularly likely to have been modified by a MAX database recovery.

    Another way to get timeouts is to rely on an external signal for a sample clock and have that signal be absent.  But that seems like a pretty unlikely scenario as well, especially under the theory that a MAX database recovery would have caused it.

I would have expected a failed recovery to result in different kinds of errors than a timeout -- devices not found, resource conflicts, things that go along with MAX reverting various config settings to their defaults.  A DAQmx timeout suggsts that the device was found ok, the task configuration generally checked out, and the task was able to be started.

I'm afraid I can't come up with a short list of clear and obvious things to try.  If you post the code, someone might be able to help more.  (Can't promise it'll be me though.)

-Kevin P

[billko]

---

@Kevin_Price wrote:

Well, it sounds like the recovery process made a change to your system configuration somewhere.

That particular error code is a DAQmx timeout.  It gets thrown if a call to DAQmx Read has to wait too long to accumulate the # of samples requested.  Both timeout value and #  of samples are values that can be specified by the programmer.  Unfortunately however, neither seems particularly likely to have been modified by a MAX database recovery.

    Another way to get timeouts is to rely on an external signal for a sample clock and have that signal be absent.  But that seems like a pretty unlikely scenario as well, especially under the theory that a MAX database recovery would have caused it.

I would have expected a failed recovery to result in different kinds of errors than a timeout -- devices not found, resource conflicts, things that go along with MAX reverting various config settings to their defaults.  A DAQmx timeout suggsts that the device was found ok, the task configuration generally checked out, and the task was able to be started.

I'm afraid I can't come up with a short list of clear and obvious things to try.  If you post the code, someone might be able to help more.  (Can't promise it'll be me though.)

-Kevin P

---

I think if a predefined task were missing, you'd get different errors, right?

[Kevin_Price]

---

I think if a predefined task were missing, you'd get different errors, right?

---

Yeah, there's distinct errors for referencing devices or tasks or channels by names that are different than what MAX has configured.  Those are the kinds of errors I'd look for after an auto-recovery of the MAX database.  Not a mere timeout error after a task was successfully configured and started.

-Kevin P