I assume that you are running this on a PC.
Timer events cannot be guarenteed to be accurate because of the overhead of the operating system.
Some of your Timer Events will occur around 1sec inteverals, but you may see gaps.
You don't even have to be loading you PC down with other applications. For example the Mouse and Keyboard events under windows have a higher priority than your TimeEvent.
This is why some people install 3rd party hardware that have high quality time ccts on them, or even better if more cruical, use a Real Time Operating system, (and hence interupts).
If you don't need absoulte accuarcy but a bit more accurate than you are seeing, you can sort of fudge it.
Imaging you had a timer that fires every second,
if you miss one, you are out a maximum of two seconds.
If you had a timer that fires every 100ms, and you miss one you are out a max of 200ms.
likewise
If you had a timer that fires every 10ms, and you miss one, you are only out a max of 20ms.
So I decided I have a timer of 10ms.
Within the event that handles the time I have the following code.
EVENT
etxern ilocalCount += 1 \\ Just define it outside somewhere else
if (100 = iLocalCount)
{
\\Do some stuff at 1 sec intervals or set some flag
iLocalCount = 0;
}
END OF EVEN CODE
Using the above, my error will be proportionate to the number of 10ms events that I miss, not 1sec events.
If you decrease the timer value, you will decrease your error, (but place more load on the CPU).
You cannot really guarentee accurate time on a PC, just because it is trying to behave like a multitasked operating system, but all it is doing is splitting each task up and giving it an alloted amount of time, but it always has to wait for the taks to complete its function.
If yours was program A, and I had created program B, and program B had the following lines of code
PROG B ENTER
Print "In Prog B"
FOR LOOP = 0 to SOME BIG NUMBER THAT TAKES 2 SECS ON PC TYPE XXXXX
NEXT
Print "Leaving Prog B"
END OF PROG B
Windoes OS will split CPU time between A & B.
Say it does some of A, then gets to B, but quits after getting to the first PRINT.
It then goes back to your prog, does a few more lines of your code, and then goes back to Prog B.
It will now be locked within the Loop for over 2 secs until it completes.
When it gets back to your program, several timer events are queued up or some may have been missed.
Now if Prog B had been written by a half decent CVI programmer, he would have of course placed a PROCESS SYSTEM EVENTS Call inside his big time consuming FOR LOOP.
The FORCE SYSTEM EVENTS is basically a function that sends the process that calls it to Sleep for a finite period, giving control of the system back for that period while it snoozes.
Hope this helps more than it confuses... Depending on what you application for this one second timer is, project, interest, work, course work, would then determine what other help you need.
If its just to make an LED flash on and off at 1 sec intervals, then no need to worry...
If its a keep alive signal for some Nuclear Control System, then its time to go looking for some other solutions....
Regards
Chris