What the problem may be is that there is file write operations going on inside the loop. A 10 msec loop is a pretty fast loop rate. If all you were doing was taking the readings and doing calculations, that is probably okay. But now you have write to file operations going on (twice!). Those express VI's open, write, and close the file every iteration of the loop, and that could probably take longer than 10 milliseconds. You may want to createt a graph where you track the tick timer (tick count on the timing pallete). Keep feeding it into a shift register and subtract the current timer from the previous iterations timer. Graph that on a waveform chart and see how consistent the loop rate is. I bet you'll find the loops take longer than 10 msec. The reason the apparent RPM is growing in time is that it may take each iteration of the loop a little bit longer to run than the last because the file size is growing.
There are at least 3 things that could be done to help.
1. Best. Move the file VI's out of the loop and pass those values to a parallel loop for the file writes by way of a queue. (See producer/consumer design pattern.)
2. Okay. Use lower level file I/O VI's where the files are opened before the loop, written to in the loop, and only closed after the loop ends. (Doing this type of operation based on the producer/consumer loop is actually the best.)
3. Track the timer from loop iteration to loop iteration to see the actual loop iteration time. Use that instead of the hardcoded divide by 10. That way if the loop still takes longer than 10 mseconds, it will account for the extra ticks in the counter within the calculation.
Message Edited by Ravens Fan on
02-11-2008 10:59 AM
![RPM1[1].png 10 KB](/ni/attachments/ni/170/296795/1/RPM1%5B1%5D.png){kind=link}
