Need a Timer Component that counts up and down

I’m looking for a way to use a Timer Component that will count up to 5 and back to 0 by 1’s and have a configurable delay. Basically like this:


I want to bind the Delay to a Tag in order to speed it up or slow it down.

  1. The Timer Component works well but resets to 0.
  2. The Signal Generator does what I want but gives too many values and I can’t figure out a “good” way to change the delay between values
  3. We tried writing a Timer Script, and it works, but our Delay is usually 75-300ms so there’s a lot of CPU and network overhead and isn’t reliable.

I started looking at system.util.invokeLater and creating a function because it seems to be the best with regards to threading and running on a client with Swing. Unfortunately, it’s probably outside my level of expertise.

IMO, the Timer Component works the best and is easiest…I just have to figure out how to make it count backwards once it hits the Upper Bound.

What do you guys think?


The attached window has both methods. Enjoy! :wink:

Note: the timer will not work with a non-zero minimum number.
timer_and_sig_gen_2014-10-21_1543.proj (10.1 KB)

Try this.

Create a user property to store your adjusted value on the root container. Set the bounds on the timer to 10 and use this script in the timer’s actionPerformed event. Now you can use the adjusted value instead of the actual timer value and it will step from 0 to 5 and back to 0 again.

midpoint = 5
timer_value = event.source.value

if timer_value <= midpoint :
	adjusted_value = timer_value
	offset = timer_value - midpoint 
	adjusted_value = midpoint  - offset

event.source.parent.adjusted_value = adjusted_value

Thanks JordanCClark and JGJohnson. All three methods looks really good and more robust that what we were trying.

We’re going to do some stress testing on the clients to see which method performs the best and I’ll let everyone know how it goes.

The Signal Generator method from JordanCClark appears to be the most efficient (CPU% on client) and most “fluid” of the options mentioned…and better than what we were cobbling together.

Thanks to everyone for their input!