Visual Basic Timer Control - Real time control application


Thread Starter

Len Klochek

I am using VB6 to generate timer events at 500 msec intervals for a control program. The timer control event seems to occur with a greater delay than 500 msec. The error seems to be about 30%, That is the actual event occurs every 650 msec. The PC is a Pentium 350 MHz running Windows 98. Has anyone used the timer control to generate events for real time control and is there is way to get around this error? I would appreciate any suggestions you may have. Len Klochek Seneca College
To answer your question about the timer control, no you can not. It isn't designed to be that accurate. However, in the zip file I attached to this msg there is a VB6 module "timer.bas" and a class "timer.cla". If you insert both of these into your application you can create a high resoulition multimedia callback timer. This code was taken from someplace online about a year ago, but I can not remember where or who. VB Example <General Declarations> Private WithEvents MyMMCTimer as CTimer <Form Load ~ Class Initialize> Set MyMMCTimer = New CTimer MyMMCTimer.Interval = 500 <Form Unload ~ Class Terminate> MyMMCTimer.Interval = 0 Set MyMMCTimer = Nothing <><><><><><><><><> Notes: Always Set The Interval To 0 Before Destroying The Object Always Destroy The Object Before Ending, VB Does Not Manage API Created Objects. Do Not Be Suprised If You Have To Reboot Your PC Several Times Before You Get Everything Working At 100% You Can Not Debug Your Application In The VB Debugger, Unless You Put The Timer Class And Module In An ActiveX DLL. The VB IDE Can Not Handle Multiple Threads, But It Can Be Debugged In The C++ IDE. .... So, I Hope This Helps Jake
The timer control is based on the windows clock that ticks 18.+ times per second approx 50 ms granularity. As you try to shorten the interval the error gets worse. These WM_TIMER messages are handled just like any other windows message. Suggest you investigate multimedia timers that can have a granularity of 1 ms. They are not vb controls though and require some programming. thanks Joe Bingham

Michael Griffin

Visual Basic and Windows have limits as to how fast they can respond to events. Other responses have dealt with this issue already, so I won't contribute my limited knowldge to this. However, Mabry Software has a high resolution timer which you may be interested in. I tried out a demo version a couple of years ago, but I haven't used it in an actual application. The following is a direct quote from their web site: "HiTime VBX/OCX is a high resolution timer. You use this control just like the default Timer control that comes with Visual Basic. Visual Basic's Timer control can only fire an event every 55 milliseconds (18.2 times per second). HiTime can fire events at a much higher rate. How high depends on the speed of your machine. 486DX2/66's can handle more than 500 ticks per second. 66mhz Pentiums can handle 1000 ticks per second." ********************** Michael Griffin London, Ont. Canada [email protected] **********************
Disclaimer: I am just going to answer your question and hopefully avoid the "holy war" that could possibly erupt because you used the words "real-time" and "Visual Basic" in the same sentence. Just make a note that there are some questions as to the capabilities of VB and Windows (DOS or NT based) to perform real-time control. Even debates rage as to the definition of "real-time control". Answer: By Microsoft's own admission, the timer control will not run on the interval specified. The interval isn't a indication of the time elapsed since the last execution, but more an indication of how often you wish to be woke (resolution). So, you need to set the interval at one-half the desired precision. (250 ms in your case). Have your code check the system clock to see when you need to perform actions. Obviously, if your code takes longer than 250 ms to execute, then the event will be skipped. The minimum resolution is 1/18th of a second. The timer control is mainly used for UI tricks and background tasks. Dustin Beebe, P.E. ProSys, Inc. Process Systems Consultants

Vladimir E. Zyubin

Hello Len, Try to set 385ms (500/1,3) interval. BTW, any control system is "real time" by definition. Have a nice day. Vladimir

Matt L Myers

Len, You can use the GetTickCount() function to return a number that increments every mS. Using a simple compare it can be utilized as a timer. Depending on CP overhead, other applications running, you may get some better response. I usually use it in a tight loop for mission critical timing. Private Declare Function GetTickCount Lib "kernel32" () As Long Dim StartTime As Long StartTime = GetTickCount() Matt Myers, E.I.T.

Greg Schiller

OK, Whatever the definition of real-time anybody has at any point in time is subject to change based upon the product they have gotten to work or not work, sell or not sell. The real reason behind using consistent timing in control is that most of all Newtonian physics obey some kind of equation with respect to a consistent linear time factor. Take F=ma which is a static equation. The dynamic equation is also always true for Newtonian physics. F(t) = m * a(t). Let's say you are trying to control the acceleration of a device like in a motion controller. And let's say that we do not have a perfect controller but one that is real. One where the timing of the update rate on the output varies by deltaT. So our new equation now is. F(t + deltaT) a(t + deltaT) = ------------- m At the end of the day what you get is some physical systems are more forgiving than others to disturbances in the consistency of their control loops. Many of you have implemented control schemes with NT, with and without real-time extensions. Or even tried to do motion control through PLC analog cards. The results vary based upon the physics of your applications not the definition of real time. The PLC works and works often because it is fast enough and consistent enough for most machine applications. It is a dedicated constrained OS centered around meeting strict time schedules. In my opinion the most critical part of anybody's real-time definition is its guarantee that the control will be serviced at a given known frequency. It is not "the system is so fast that it doesn't matter." This approach erodes the very core of real time which is repeatability. Please have fun with this topic. My goal is a deeper understanding of it all. Regards, Greg Schiller Eason Technology 214B Center St. Healdsburg, CA 95448 E:[email protected]

Vladimir E. Zyubin

Hello List, It seems to me 55 ms resolution doesn't explain the delay of 150 ms (500->650). So, the most probable issues would be: 1. a hardware problem that lead to the reducing of frequence. 2. a software problem, e.g. the processor can not execute the task within 500 ms interval (time-consuming algorithm), VB program limits, etc. IMO. Regards. Vladimir.
Simply put, the behavior you are seeing from the timer control is how it was designed and expected to work. That doesn't solve your problem however. I suggest the following alternatives: (1) (easiest, preferred) Use the Windows Multimedia timer, which while still not perfect will provide higher granularity and better (but still not perfect) predictability. I believe some vendors have created VB controls based on the multimedia timer. (2) Use the windows Timer API's - SetTimer and KillTimer - this method has some nasty side-effects, but will provide some of the best performance from standard windows timers. This does not rely on the WM_TIMER windows message (this message is the real problem with using the Timer control itself) and will certainly perform better. If you are not an advanced VB programmer then you're likely best staying away from this approach. Declare Function SetTimer Lib "user32" (ByVal hWnd As Long, ByVal nIDEvent As Long, ByVal uElapse As Long, ByVal lpTimerProc As Long) As Long Declare Function KillTimer Lib "user32" (ByVal hWnd As Long, ByVal nIDEvent As Long) As Long ' Then add and write the following function in a standard .bas module Public Sub TimerProc(ByVal hWnd As Long, ByVal uMsg As Long, ByVal idEvent As Long, ByVal lngSysTime As Long) ' ... put your timed code here End Sub ' In the same standard .bas module create a timer using the following call dim lTimerID as long const interval = 100 lTimerID = SetTimer(0, 0, Interval, AddressOf(TimerProc)) ' Terminate the timer with the following call KillTimer(0, lTimerID) (Disclaimer: I didn't test this code, but I'm 99.99% sure the declarations are right) For every SetTimer, you -MUST- -ALWAYS- call KillTimer before you debug or stop your application. Failure to do this will cause the VB debug environment to crash. If you can live with that restriction, then everything will be ducky. QUACK! Jeff Dean [email protected]

Vladimir E. Zyubin

Hello List, the most valuable part of anybody's _control_ system definition is its garantee to provide demands of its "Technical specification for development". real time "problem" is an artificial problem (with marketing roots), as it seems to me the problem to measure 60V x 3000A within 0.5% inaccuracy is of 1000 times more actual than the "problem" to organize parallel functionality of a couple of control loops with 50 ms granularity, on Pentium-IV platform (e.g., see QNX docs... and the issue of the topic). Regards. Vladimir P.S. BTW, is anybody here who would like to suggest the method to measure current within 1500A-3000A diapasone with inaccuracy no more than 0.5%... the form of current is a "saw", after tiristors.

Nedeljko Pavlovich

Visual Basic is not professional language.
It is made with C++.
Visual Basic is good for increasing speed of work
but in some things such as Real time processing
Visual C++ is the best.
Visual Basic is very slow for operations with strings and many, many more.
When i have dead-line i use Visual Basic (it is easy for ado, trivial algorithms)
You can import kernel functions in VisualBasic project for time processing, and many more such as sockets...

Maybe it might have somethig to do with the fact that c++ is object oriented and visual basic is not. - dur