OPCWARE

Software components for automation users to assemble interconnections between industrial devices and applications, productively.

Data Layers
Industrial Software Solutions

Home

Products

Download

Order

About

Contact

Multimedia Timers Overview

System Timers - Win32 API and Visual Basic's Intrinsic Timer

Every Windows application processes messages that derive from the operating system, and a Windows timer is simply an object that is managed by the operating system. When the specified time has elapsed, a WM_TIMER message is posted into the application's message queue. When this WM_TIMER message is processed by the application's message queue, one of two possible activation modes occur, depending on how the timer is configured.

The first possible activation mode is that the WM_TIMER message is sent to a window that was specified when the timer was created. The alternative activation mode is that the operating system triggers a designated callback function within the application that will be executed when timer event fires (this is the better approach to take if you use an API timer).

You can use system timers directly using the Win32 API. Both activation modes are supported, though it's easiest to use the callback scheme under VB because you can use the AddressOf operator to specify a callback function. You can also intercept the WM_TIMER messages by subclassing the specified window, but it's more work that way.

Using the WM_TIMER message under any circumstances (including VB's intrinsic timer) suffers from a couple of major limitations:

The standard timer supplied with VB is based on the system timer and is great for most tasks. It's the easiest way to access system timers, though it does suffer from the serious limitation of supporting only 16-bit timer intervals (up to 65,535 ms or 65.5 seconds). In addition, the frequency at which it updates isn't acceptable for high-performance applications such as multimedia or data acquisition. In Windows 3.1 the multmedia timer was the solution to this problem. One of the great new features of Win32 and Windows 95 was preemptive multitasking, where users are free to do something other than meditate while the cursor is busy. However, a side effect of this feature is an increase in multimedia timer latency - the latency is much greater than was the case under Windows 3.1. It is not uncommon to observe latency of several hundred milliseconds with Windows 95. In audio applications the system must be capable of firing audio events with a 1ms resolution, otherwise the ear will be able to discern the timing inaccuracy. Likewise, in critical data acquisition applications where process data is being gathered in real-time, if timer latency becomes excessive, loss of data can occur, which is very evident on a graph or in a mathematical analysis for example.

The VB timer is based on the standard Win32 system timer, which simply was never intended for time critical tasks such as these. Whilst one alternative to this sort of problem is using a DoEvents, Sleep and QueryPerformanceCounter loop, this is rarely what you want in a real world application.

Win32 Multimedia Timers

Multimedia timers are implemented using the Win32 multimedia library (winmm.dll). Multimedia timer services allow applications to schedule timer events with the greatest resolution (or accuracy) possible for the hardware platform. These multimedia timer services allow the user to schedule timer events at a higher resolution than other timer services.

These timer services are useful for applications that demand high-resolution timing. For example, a MIDI sequencer requires a high-resolution timer because it must maintain the pace of MIDI events within a resolution of 1 millisecond.

Before creating a timer, it is important to be aware of a number of system limitations and VB problems which can occur when using multimedia timers.

Timers are a Limited Resource - In Win9x, the system is limited to a maximum of 32 multimedia timers. (In NT, 2000 and XP, things are much better and each process on the system can have up to 16 timers.) To provide full Win9x support it is therefore desirable to minimise the number of timers you create to reduce the chance of running out of timer resources. A single application should not normally create more than one timer regardless of how many controls, DLLs or modules within that application require the timer's services.

Multimedia Timers are remorseless - If you build a multimedia timer directly into a VB application, you will almost certainly not be able to debug it with any consistency. Any time the application stops for an error or a break-point, the timer keeps on firing from its own separate thread in the background. This immediately crashes or locks up the VB IDE. Adding Debug. Print messages doesn't help either - the debug window can't keep up with the high rate of messages fired by the timer and VB IDE locks up in a loop again.

While this allows the multimedia application to execute its code and play a sound on time, it also degrades overall system performance. Microsoft tests have found that, while lowering the timer tick frequency to 2 milliseconds has a negligible effect on system performance, a timer tick frequency of less than 2 milliseconds can significantly degrade overall system performance. On faster systems, the cost of lowering the clock interrupt period below 2 milliseconds may become affordable, but the subtle effect of the increased interrupt frequency on cache consistency and power management may not be desirable.

What is XtraTimer™?

XtraTimer™ is Data Layers High Resolution Multimedia Callback Timer, providing a powerful, lightweight, wrapper ActiveX class for the multimedia timer, and is capable of servicing an unlimited number of events or callbacks with up to 1ms resolution in VB code. You can buy just the component itelf or the full source code to kick start your time-critical VB applications

XtraTimer™ provides high performance timer objects for sequential, synchronous timer events and OLE callbacks. This approach is good for predictable, deterministic, soft real-time control applications.

"Soft real-time" may be loosely defined as when a brief discontinuity of control does not result in loss of life or limb, or in grave financial loss.

The timer events available in this wrapper class are synchronous, i.e. if a timer event has been fired and the code is still being executed when another event is due, the due event will be cancelled and another event will not occur until the currently executing event is complete. This ensures sequential, single-threaded processing which is easy to debug in the VB IDE.

If all events are due together, the order of firing will be: Time events in order of [TimerIndex], followed by Countdown events in order of [CountdownIndex]. Unless the code in your timer events is slow to execute, this approach will work well. Obviously, if you are using an interval of 1ms, and if you put code in the event that takes 12 ms to execute, then you would only expect to achieve a resolution of 12ms at best, i.e. the events would fire at 12ms interals rather than the requested 1ms intervals. The same applies to code in any event for any interval.

In some situations, such as printing or updating a database, it would be preferable to delegate this work to an asynchronous thread (or out-of-process) to avoid tying up the system with lengthy synchronous events.

The relationship between the resolution of an XTraTimer object (called a CXTLite object) and the length of the timer interval is important in CXTLite events and ITimer callbacks. For example, if you specify a resolution of 5 and a timer interval of 100, the timer services notify the callback function after an interval ranging from 95 to 105 milliseconds.

Product Focus

 

Some Recent Testimonials

 

Pricing | Buy Now

What is OPC?

Data Layers is a member of the OPC Foundation

Order | Download | Products