Countdown Timer

sentry07

I've got a couple systems that the client wanted countdown timers. I'm using timelines set to a single absolute time value of 1000 to decrement a counter and display the resulting value on the touchpanel using some math and string formatting to get the mm:ss format. These are fairly code-heavy systems (~10000 lines of code) with a particularly processor heavy set of functions (for parsing JSON). The client complained that one system, over the period of 1 minute, was 9 seconds fast and the other system was 14 seconds slow. I'm assuming that they were not using any other functions on the system beside the timer since they were basically watching a stopwatch at the same time. I'm kind of at a loss on what to do next, really.

The timeline event looks like this:

TIMELINE_EVENT[1]
{
    IF (Timer1Remaining[1] > 1)
    {
	Timer1Remaining[1] = Timer1Remaining[1] - 1
	SendText(1,CRTimerText[1],"itoa(Timer1Remaining[1] / 60),':',FORMAT('%02u',Timer1Remaining[1] MOD 60)")
	IF (Timer1Remaining[1] < 5)
	    SEND_COMMAND daTp[1],'ABEEP'
    }
    ELSE
    {
        Timer1Remaining[1] = 0
        SendText(1,CRTimerText[1],'0:00')
	TIMELINE_KILL(Timer1Timeline[1])
	SEND_COMMAND daTp[1],'ADBEEP'
    }
}

There's 3 available timers on 2 touchpanels so there's 6 timelines. This is the system that's 9 seconds fast. On the other system, there's 15 timelines (3x5). This is the system that's 14 seconds slow. All timelines have the exact same code with different indexes.

Auser

sentry07 wrote: »

I'm using timelines set to a single absolute time value of 1000 to decrement a counter and display the resulting value on the touchpanel using some math and string formatting to get the mm:ss format.

[...]

I'm kind of at a loss on what to do next, really.

Have a look at the first post on page 2 of http://www.amxforums.com/showthread.php?7279-AMX-for-industrial-control/page2&highlight=industrial regarding the (in) accuracy of waits and timelines.

I would recommend storing the timer "start" or "finish" date-time as a Unix (ordinal) time value which you can then compare with the current Unix time value when your timeline event fires to determine (accurately) the value of the timer. In this scenario the timeline only serves to update the values on the touchpanel and its minor lack of accuracy has no compound bearing on the accuracy of the timer value.

It's quite possible that there are functions for converting Gregorian system date-times to Unix time values in the Netlinx Common Libraries project (but I haven't checked).

DHawthorne

Timelines execute when their timers are due, then pass control on until the next time. They should not bog your system down in any measurable form. I cannot imagine that once a second is significant to the master. If anything, your other code is bogging down the timelines, since their timers only get checked with each pass through mainline, and other code could delay those passes in a manner that accumulates.