Multifunction DAQ

cancel
Showing results for 
Search instead for 
Did you mean: 

continuous DAQ failure

aloha!

i have a problem with continuous DAQ failing sometimes: my program sets up a continuous acquisition loop and retrieves data from the buffer periodically, and does some calculations and then displays data, everything inside a big loop. normally the VI runs without any problems at all, but sometimes (once a day or once a week or so) it gives the following error:

+++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
Warning -10845 occurred at an unidentified location.

Possible reasons:

NI-DAQ LV: Because of system and/or bus-bandwidth limitations, the driver could not read data from the device fast enough to keep up with the device throughput; the onboard device memory reported an overflow error.
+++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++

i have read and understood (i hope...) the article on continuous acquisition:
http://zone.ni.com/devzone/conceptd.nsf/webmain/F2DDCBAD754C687C86256802007B8514?OpenDocument
and made sure that the VI is by far fast enough to retrieve data from the buffer - i can retrieve, compute
and display data at 10 times the rate i'm actually doing, so the VI is really not doing much most of the time.
only sometimes, it fails (after running for minutes or hours) and gives me the error above.

my questions:
-> what could be causing this problem? could it be other software on the computer doing something (like a virus scanner)? or that windows wants to shut down the harddisk to save energy or something?
-> is there a way of finding out what is stopping labview from reading the data? the above error message is rather general...
-> once my VI fails like this, it fails very ungracefully - it crashes. is there a way of programming a continuous acquisition
in such a way that it recognizes such errors and resumes the acquisition?

i have attached an image with the diagrams of the main VI (top) and the subVI for the data acquisition (bottom). the DAQ subvi is the VI with the icon "EDB cont meas" in the top left of the main VI. all the rest of the top loop are just data treatment and display things.

cheers
martin
0 Kudos
Message 1 of 5
(2,956 Views)
There are dozens of possibilities that could cause this the way your program is written.
Try reading( or attending) the Labview Basics course. It will help with simplifying your code.
The way you are running the error cluster only gives you the last error. you have no clue what happened, where or when.
Greg Bush CLAD
0 Kudos
Message 2 of 5
(2,933 Views)

@bushman wrote:
There are dozens of possibilities that could cause this the way your program is written.
Try reading( or attending) the Labview Basics course. It will help with simplifying your code.
The way you are running the error cluster only gives you the last error. you have no clue what happened, where or when.




hehe, labview basics course - i have seven years of experience with labview! i really don't think i need that course...

anyway, i found what is causing the trouble; the program only fails to read data when the computer is allowed to turn off its harddisk after a certain period of inactivity. not too surprising, my top-level VI writes data to disk, and if that takes too long, the buffer overflow will occur.

i know i can ask my users to disable the windows power management; but it would be even better if my program could somehow tell windows that it is not in idle state. is there any way to do this?

cheers
martin
0 Kudos
Message 3 of 5
(2,920 Views)
Why all the locals???
With seven years experience you should know that the redundant use of locals as you have in your program adds size, uses more memory than needed, and breaks data dependancy.
I have played golf for many years, it hasn't made me better.
Greg Bush CLAD
0 Kudos
Message 4 of 5
(2,917 Views)

@bushman wrote:
Why all the locals???
With seven years experience you should know that the redundant use of locals as you have in your program adds size, uses more memory than needed, and breaks data dependancy.
I have played golf for many years, it hasn't made me better.



what makes you think that my usage of locals is redundant? it is the only sensible way i know of to display data in the same graph from different events of the event loop; which is something i want to do.
this is getting rather off-topic compared to the original question though 🙂

cheers
martin
0 Kudos
Message 5 of 5
(2,911 Views)