LabVIEW

cancel
Showing results for 
Search instead for 
Did you mean: 

time delaying

I have a "time delaying" problem with VI program.
In other words, the time in VI is slower than a real time. This happens when I use many channels like 50 and doesn't happen when I use less than 20. I'm looking forward to hearing a good news. Thanks.
0 Kudos
Message 1 of 8
(3,421 Views)
A little more information would be helpful. Do you use software or hardware timing? What are your loop rates?
0 Kudos
Message 2 of 8
(3,421 Views)
The loop rate is set to 1000.
I tried to change that number, but
it doesn't solve the problem.
And I used a stop-watch to compare the time.
Thanks.
0 Kudos
Message 3 of 8
(3,421 Views)
We still need more info, are you concerned because the loop is not executing at exactly the frequency you specify? (In Windows it's not possible to get deterministic execution time) Are you using Timed Loops, or ordinary while loops?

Regards,
Ryan K.
0 Kudos
Message 4 of 8
(3,421 Views)
Sorry, I should have said more details.
My concern is the time in output file is different from the time we conduct the test.
For example, if we did a test for 600 seconds, a output file give us just the data for 350 sec.
I hope this helps a little bit.
Thanks.
0 Kudos
Message 5 of 8
(3,421 Views)
Have you included the time delay for vi's within the loop?

I am not sure of actual numbers but the number 4 ms comes to mind..

So if you expect a loop to occur every 10ms and you use a wait for delay.vi, the loop may actually be occurring every 15 ms, so a lot less readings within a given period of time.

A trick if you want samples at precise time interval is to set a trigger based on time increment from the original timestamp.

So, you take a timestamp as reference, multiply the delay times the number of iteration and trigger on when the next time occurence takes place. Care must be taken not to have too much delay within the loop so that it plays "catch up" at every iteration...

JLV
Message 6 of 8
(3,422 Views)
Hrm, could be a lot of things, you should probably try to do some debugging in your program (use probes or indicators). You should determine whether you have all the data and it just isn't getting written to the file, or whether all the data is getting written, but the timestamps are wrong, or something else. This still isn't enough information for us to provide any meaningful input. At the very least you should be able to narrow down whether the problem is with the timing, the data acquisition or the file i/o.

Regards,
Ryan K.
0 Kudos
Message 7 of 8
(3,422 Views)
It seems to me you are running out of resources and the operations per loop take longer than 1000ms to execute if you acquire so many channels at once.

There are many ways to address this issue: (1) Make sure the acquisition loop does not do any unecessary operation, don't update the front panel (charts, etc) but wait until all data is acquired. If you need a realtime chart, turn off autoscaling and use simple lines instead of fancy dots, etc. (2) Don't use highest level I/O that initialize the entire hardware for each reading. (3) turn off debugging, (4) don't run uneccesary other tasks, e.g. of you have several parallel loops that e.g. monitor front panel activity, make sure they contain at least a 100ms wait. If they don't contain a wait, they suck up CP
U cycles like a sponge while doing nothing. (5) get a faster computer, etc.
0 Kudos
Message 8 of 8
(3,422 Views)