When reading an encoder the computer performance suffers with program duration.

[photolab guy]

I�m working with a PCTIO-10 counter/timer card with Atmel AM9513A microcontrollers and a LAB-PC-1200AI Card. The Computer I�m using is an older Compaq proliant 600 MHZ server running NT and Labview 5.1
The objective of our application is to create a VI that controls a photometric lab. We swing a boom with a photocell attached to the end through a light source and collect intensity measurements along the way. We use the 1200AI card to activate a solenoid that controls direction of the boom and the TIO card is used to count encoder pulses and monitor boom location. The application then collects intensity measurements at specified boom angles. This is where we start to have problems� The application works, as it should, monitoring boom location and collecting data at the correct angles: 10 deg, 20 deg, 30 deg, etc� I wrote the application to execute in a do while loop constantly reading the TIO card and generating a boom angle. I then poke the results into a shift register. As soon as I read the correct angles from the shift register I collect the photocell data. The problem comes in after the program executes for a few minutes. The machine performance degrades as execution time elapses until ultimately the machine starts to miss pulses. Let me clarify this statement: the card/machine seem to keep track of all pulses emitted by the encoder BUT the machine can�t get back to read the cards register before it misses the required angles. E.g. I want to collect data at 50 deg boom angle. The register is counting the pulses but the computer reads the register in a loop as: 46, 46, 46, 46, 47, 47, 47, 48, 48, 51, 51, 52, 52, etc� The machine is counting the encoder pulses but the software can�t seem to �get back� to the register in time to pick up on the correct angles. This problem is amplified as program execution time elapses until the machine starts to miss a series of numbers and also has trouble with monitor redraws/updates. The Windows NT task manager shows no memory leaking. I�ve also tried to add small wait durations in the program to allow Windows time to multitask and do maintenance. It didn�t help. I then scraped the original program and wrote a new one that starts and stops the counters when not needed for short periods. I also reset the registers at the top and bottom of the boom stroke in an effort to free up the processor and/or memory, but the problem persists. I�m either writing a poor program or I need a way to dedicate to processor to this task. Any input will be appreciated.

[Kevin_Price]

It's difficult to pinpoint without any code posted. However, a sluggishness that increases with run time can be a symptom of a program that keeps resizing and/or copying fairly big arrays. Can you post some of the code?

Also, there may be a different approach that will let you hardware-capture excess data, then extract the subset of interest in a post-processing step. This way you can be sure not to miss any points.

The idea would be to perform a buffered analog acquisition of your photocell(s), using the encoder pulses as an external scan clock. There are shipping examples that show how to do such things, and I think the Lab-PC-1200AI should support them.
You could set up an acquisition buffer a bit bigger than the # of encoder pul
ses in your boom's range of travel. After collecting one scan for each encoder position, you can then extract data at or around the positions of particular interest. Just note that the data at index i corresponds to your previous method's position i+1.

-Kevin P.