Something seems to be stealing time from LabView execution time.
I have a problem that I assume is caused by LabView being kept from executing properly a
few times per day. There are many interresting facts, but I have no clue as to what is
actually the source of the problem, or how it can be circumvented.
The task:
The task is created in LV 8.6 and runs under Win XP with all current updates.
It reads analog data from a USB-6221.
In simplified pseudocode it does..
While Measuring
Wait for "sensor in position" (true every 41-42 seconds)
For 80 times (8 seconds) sample data every 0.1 second during 40 ms each.
Sampling: Do DAQmx- Create Channel, Timing, Start Task, Read, Clear Task.
Process results.
Loop through a millisecond counter until the next 0.1 second reached
EndFor
Store data to disk and Send the sensor to a new position
EndWhile
Typically the millisecond counter reveals that the actual sampling and processing leaves
the program idle for about 50 ms after every sampling event (the overhead thus leaves
enough margin to be ready for the next sampling event in good time).
Storing the data to disk involves opening, appending data and closing the file again.
The problem:
I have not logged the results of the millisecond counter, but I am confident that the
0.1 sampling has not been performed as it should on at least 13 occasions over 3 days.
What evidently happens is that LabView is hindered from executing its 0.1 second
sampling in time, not only once, but even for several seconds at a time.
Odd observation 1:
When it comes to the number of "missing 0.1 second cycles" they seem to be clustered
according to the approximate formula 0.3 seconds + N* 0.95 seconds where N={0;3}
WHY would that be???
Odd observation 2:
When looking at the time of the occurrances it seems clear that there is no obvious
correlation to anything (it occurs at any time of the day or night).
However, when looking at the interval between events, it becomes clear that the interval
is always an integer amount of hours, OR an integer amount of hours + 10-11 minutes
(varying from 1 hour sharp, to 20 hours 11 minutes, between events)
WHAT could possibly explain such a behaviour.
My thoughts:
- It cannot be related to the LabView code as such, as it works as expected most of the
time
- Further, the sampling is (unnecessarily) set up and closed every 0.1 second interval,
therefore it should execute "freshly" every time and not be able to "acumulate" errors.
- It could perhaps be related to the A/D converter occasionally returning the results
with a delay of several seconds...
- It could be related to LabView being kept on hold by windows (or a competing
process??) every now and then...
- I do not currently know where in the sequence of 80 times 0.1 seconds that the problem
appears, although my gut feeling tells me that it is only one contiguous sequence of 0.1
second samplings that are delayed.
-The "odd observations" are really odd...
Any ideas about what has happened, and/or why, are most welcome.
Kind regards / Ake
------------------------------------------------------------
APPENDIX, The list of problem events.
Time for event Interval Integer duration
from last (in units of 0.1s)
2011-03-07 13:33 2
2011-03-07 16:44 3h 10min 14
2011-03-07 19:44 3h 11
2011-03-07 20:43 1h 12
2011-03-08 07:54 11h 11min 19
2011-03-09 04:05 20h 10min 2
2011-03-09 04:14 10min (?) 5
2011-03-09 06:25 2h 10min 22
2011-03-09 08:25 2h 31
2011-03-09 14:36 6h 11min 23
2011-03-10 00:46 10h 10min 2
2011-03-10 02:46 2h 13
