>
>Thanks for the info! We have some real short interval timers, 50 and 200 ms timers... So that we can continuously read from our probe-devices. They work good, although sometimes we have 2 timers running at once which I don't care for, but it seems to work ok. But it seems we should be able to streamline the code better to get faster response times, and maybe we wont need to have the timers run that quickly? Then maybe the buttons would work better?
>
>Let me ask you something, in most cases I am assuming that with a 50ms timer, the timer is up before the timer-code is finished. Does that mean that the timer-code will re-run immediately, or not until the timer-code is finished, then it runs it again?
>
>I think there is a lot of potential to clean up our code and make it run better/faster, especially with timers. I just need to understand them better.
>
>Basically, we have one primary timer. the PROBE timer will read one probe, display its results, go to the next probe, read it, display the results, and so on until all probes are read and displayed, then it starts over again at PROBE 1. So there really is only the one timer. We also have a 'pedal timer' that reads from a foot pedal, which can run at the same time, that slows things down I bet.
>
>Increasing the timer to 1000-2000 ms from 200ms seems to work great for our slower probes, and make the buttons work more responsively... but it may slow
>down the display-screen of the probes, and people want to see the value that the probes are reading as fast as possible.
>
>Thanks!
>Seth

As I remember, timer events que up, so if the code on a 50ms timer takes more than 50ms, the next event will come out of the que immediately and the code will run. This means if your event code takes longer than 50ms to run, it is running continuously.

I'm a little unclear from what you said if your code loops through all the ports in each timer event or one probe is read per timer event. If you are reading them all every timer event, you might change it to only update those that need to be updated. This would complete the code sooner, hopefully freeing up time for buttons, etc. With only three probes, the timer event might look something like this...

 Probe1_time = 50
Probe2_time = 100
Probe3_time = 2000
STORE SECONDS() to LastProbe1, LastProbe2, LastProbe3

IF SECONDS() - LastProbe1 > Probe1_time 
   *: update probe1
   LastProbe1 = Seconds()
ENDIF
IF SECONDS() - LastProbe2 > Probe2_time 
   *: update probe2
   LastProbe2 = Seconds()
ENDIF
IF SECONDS() - LastProbe3 > Probe3_time 
   *: update probe3
   LastProbe3 = Seconds()
ENDIF

You could adjust the updates to the optimum per probe, and not waste time updating the slower probes every timer event. You could even set the time to fire at smaller intervals to update critical probes more often withour too much of a performance hit.

You might put the faster probes at the top of the list to be sure they fire at the beginning fo the timer event.