Unknown -10403 error

[Zen]

I sometimes get an -10403 Error from NQ-LV in the AI-Control VI .

This Error code is not listed in the manual. What could it be?

Configuration:
PII/450 MHZ /128 Mo
LV 5.01
PC6023E card
SCXI-1000 Chassis (1100,1163R and 1180 modules)
NiDaq 6.5

Thanks.

[abrause]

Error code -10403 from LV Online Help

Warning -10403 occurred at an unidentified location.
Possible reasons:
NI-DAQ LV: The specified device does not support the requested action (the
driver recognizes the device, but the action is inappropriate for the
device).

Regards,

Alan


Rommeluere wrote in message
news:38834030.C3D36C4F@lure.u-psud.fr...
>
> I sometimes get an -10403 Error from NQ-LV in the AI-Control VI .
>
> This Error code is not listed in the manual. What could it be?
>
> Configuration:
> PII/450 MHZ /128 Mo
> LV 5.01
> PC6023E card
> SCXI-1000 Chassis (1100,1163R and 1180 modules)
> NiDaq 6.5
>
> Thanks.

[Zen]

Alan Brause a écrit :
>
> Error code -10403 from LV Online Help
>
> Warning -10403 occurred at an unidentified location.
> Possible reasons:
> NI-DAQ LV: The specified device does not support the requested action (the
> driver recognizes the device, but the action is inappropriate for the
> device).




Thanks.
But I don't understand what this error means. It appears after 20 hours
of running the same VI. This VI is running the same operations (DAQ,
computing, WHILE loops) from its beginning without errors and suddendly
this -10403 error comes.
Sometimes (but always after more than 20 hours of running), the whole
application crashes. No error message from labview then, only Dr.Watson
from windows NT4 saying 'Access violation' (0xc0000005) adress:
0x1f80dcd1

Can
't labview run more than a few hours without crashing, even on NT?

[Rolf Østvik]

On Tue, 18 Jan 2000 18:00:05 +0100, Rommeluere
wrote:
>> Error code -10403 from LV Online Help
>>
>> Warning -10403 occurred at an unidentified location.
>> Possible reasons:
>> NI-DAQ LV: The specified device does not support the requested action (the
>> driver recognizes the device, but the action is inappropriate for the
>> device).

I intepret this error message as that you are trying to do something
that the device can't do.

But you then say
>It appears after 20 hours
>of running the same VI. This VI is running the same operations (DAQ,
>computing, WHILE loops) from its beginning without errors and suddendly
>this -10403 error comes.

well, it seems that you are doing the same thing as you have done
before and sudden
ly it wont do it anymore. Could it be that there is
something with the driver and NI-DAQ.

>Sometimes (but always after more than 20 hours of running), the whole
>application crashes. No error message from labview then, only Dr.Watson
>from windows NT4 saying 'Access violation' (0xc0000005) adress:
>0x1f80dcd1


>Can't labview run more than a few hours without crashing, even on NT?
I would think it is a bad driver of some sort. They need access to the
hardware and have all rights and if it misbehaves then no one can stop
it.

Try NI knowledgebase at their web page http://www.ni.com/
(or directly http://digital.ni.com/public.nsf/$$Search)
and search for 10403. I didn't find anything like your problem there
but you may find some information.

--
Rolf

[Zen]

"Rolf Østvik" a écrit :

> I would think it is a bad driver of some sort. They need access to the
> hardware and have all rights and if it misbehaves then no one can stop
> it.


I'm only using NI material (PCI6023E card, SCXI Chassis), and NIDAQ 6.5
And there are no reported errors for the current drivers on NI site.

Sometone else said that he had the same kind of problem (application
crash) after running continuously an application on NT.
The problem came from a sub-vi that was "leaking" memory.

When I open the Taskmanager and note the amount of resources my code is
using, I see:
84 Mo memory used + 80% CPU charge on start up
96 Mo memory used + 80% CPU charge after 3 minutes
and it does not change after (it does not this grows anymore durin
g
operation of my application.)





> Try NI knowledgebase at their web page http://www.ni.com/
> (or directly http://digital.ni.com/public.nsf/$$Search)
> and search for 10403. I didn't find anything like your problem there
> but you may find some information.

No, there is nothing.
I'm currently contacting the support engineers of my country.

[Todd Cloutier]

There is an issue with Labview causing memory fragmentation when calling
external DLL's, which AFAIK all the NI-DAQ vi's do. I have seen error
10403 when attempting to perform a buffered DAQ operation on a device
that does not support buffered IO.

If you are performing repetative DAQ operations and are creating and
destroying the data buffer on each iteration (using the AI Config and AI
clear vi's) your system's memory may eventually become too fragmented for
NI-DAQ to allocate enough memory for the data buffer.

If you can provide a little more information about your code (what kind
of daq operations is it performing, etc.), I may be able to provide more
help.

Regards,
Todd Cloutier
(remove the XX to send me email)


I
n article <38859854.CB97C418@lure.u-psud.fr>, rommeluere@lure.u-psud.fr
says...
>
>
> "Rolf Østvik" a écrit :
>
> > I would think it is a bad driver of some sort. They need access to the
> > hardware and have all rights and if it misbehaves then no one can stop
> > it.
>
>
> I'm only using NI material (PCI6023E card, SCXI Chassis), and NIDAQ 6.5
> And there are no reported errors for the current drivers on NI site.
>
> Sometone else said that he had the same kind of problem (application
> crash) after running continuously an application on NT.
> The problem came from a sub-vi that was "leaking" memory.
>
> When I open the Taskmanager and note the amount of resources my code is
> using, I see:
> 84 Mo memory used + 80% CPU charge on start up
> 96 Mo memory used + 80% CPU charge after 3 minutes
> and it does not change after (it does not this grows anymore during
> operation of my application.)
>
>
>
>
>
> > Try NI knowledgebase at their web page http://www.ni.com/
> > (o
r directly http://digital.ni.com/public.nsf/$$Search)
> > and search for 10403. I didn't find anything like your problem there
> > but you may find some information.
>
> No, there is nothing.
> I'm currently contacting the support engineers of my country.
>

[Greg_McKaskle2]

> There is an issue with Labview causing memory fragmentation when calling
> external DLL's, which AFAIK all the NI-DAQ vi's do. I have seen error
> 10403 when attempting to perform a buffered DAQ operation on a device
> that does not support buffered IO.
>
> If you are performing repetative DAQ operations and are creating and
> destroying the data buffer on each iteration (using the AI Config and AI
> clear vi's) your system's memory may eventually become too fragmented for
> NI-DAQ to allocate enough memory for the data buffer.
>
> If you can provide a little more information about your code (what kind
> of daq operations is it performing, etc.), I may be able to provide more
> help.
>

I'm not aware of the fragmentation
issue with general DLLs. If it is
necessary for LV to convert data at the boundary of the DLL, then that
may cause some fragmentation, all memory management does, but that will
show up in the task manager and in the LV help window as LV using more
memory.

As for the DAQ VIs, they are currently calling CINs instead of DLLs.
Theres not much difference, but the CINs always use LV compatible
datatypes and while the buffers may need to be resized based on the
amount of data passing to the and from the CIN, there aren't any
temporary allocations because everything is a compatible type.

With a DAQ config, the buffer there is a special type of allocation
that the driver makes so that the memory pages are locked into memory
because they must be there at interrupt time. Redoing DAQ config
within a loop may have some special concerns about fragmentation, but
I'm not aware of any. Something like this should be in the Knowledge-
base if it is the case.

Greg McKaskle