|
very useful, easy implementation. Thank you!
|
|
|
|
|
The title describe the problem. When the timer Tick in OneShot mode, I think the timer should be set to running = false.
I had problem when changing the period of a OneShot timer after the tick because it was trying to Stop the non-running timer (timeKillEvent returned NOCANDO error).
I just want to advise you and make sure this is the proper fix. I know some user just ignored this error in the assert but I don't think it's good because the timer just don't have to be stopped.
Thanks
DM
Dominic Morin
|
|
|
|
|
simple and easy to use. Also works perfectly!
|
|
|
|
|
It works very well. Much more precise than the standard .NET timer.
|
|
|
|
|
Its solve windows timer delay problem. It works really nice
|
|
|
|
|
This just made my life easier. Thanks!
|
|
|
|
|
|
Yeah, except your article (Stop self advertising btw, it makes you look desperate) doesn't work. As many people have pointed out to you, windows is NOT a real-time OS, it is IMPOSSIBLE to have a timer on windows accurate to 1us, 10us or even 500us. Unless you use the MMTimer, windows will ALWAYS slice it to around 15ms. Stop being so ignorant please.
|
|
|
|
|
So according to you Poll should only accept a number between 1 and 15? And I think that you are also saying that 15 ms is greater than 15 μs which is not correct...
If you 15ms you have 15000μs so achieving something when there is such a large excess seems trivial to me, it's when you start taking into account small fractions of the 15ms slice used that you get into the realm where you may not get 15 whole ms and thus reliability can't be guaranteed beyond a 15ms window... but that is still more then you should need.
I appreciate your input and hope you gained something from reading this article!
|
|
|
|
|
I hope you realise your reply made no sense.
Firstly, how is 15ms not larger than 15us when 15ms is 15000us?
Secondly, I never once mentioned Poll.
Finally, let me re-iterate what I was saying.
No matter what you do, it is impossible to be guaranteed intervals of less than 15ms on Windows. You seem to think this isn't important, when it clearly is.
I've seen a lot of people posting on here and on StackOverflow giving valid reasons for needing guaranteed intervals of less than 1ms. I personally only need guaranteed 10ms, but I can't even get that.
|
|
|
|
|
What about my reply made no sense, That semantic (kernel scheduling) is performed in all operating systems which use threads.
Sometimes the kernel is written in a way so that it's context switches from user mode to supervisor mode can be sliced to make efficient use of the threads. This is where Time Slicing comes from....
During the time this switching is occurring the kernel may take more or less time than you like,t his is the semantic of a Real Time Operating System.
Unix also performs the same context switching so Windows or Unix or Linux does not matter.
What matters is the ability of the kernel to set a priority to the threads which can indicate that certain threads should not be blocked because they require a real time context.
Both Windows and Linux/Unix can do this but then you have the problem that the context switch itself takes time.
In short, I was simply stating that if you have 10ms then you have 1000μs, if you need guaranteed intervals you must either perform a few extra or a few less intervals at one point to maintain in sync with the scheduler.
Changing the scheduler frequency isn't going to reduce the amount of time your code takes to execute, it will only ensure that the switches are happening while your logic is executing.
|
|
|
|
|
Works like a charrm, thanks!
|
|
|
|
|
I'm using this timer to schedule task that we need a consistent wait duration for. I have been using the MM Timer to wait for about 300 ms on "OneShot" then if it meets a criteria then it fires again. I've been timing the MM Timer calls with the Stopwatch and it is giving very regular inconsistencies. Every time we run the software, every 4-10 waits will be high by about 30-40 ms and on each individual run the number of waits between error is about the same, i.e. it'll error every 4-5 waits one trial and every 9-10 waits another trial. Additionally I time the inter-wait times which we know fairly well and the SW times this with no hiccups.
Has anyone else seen this happen with the MM_Timer? Or does anyone have an idea about what might be going wrong? Is it possibly because my resolution is set too high?
Here's the relevant code:
private Multimedia.Timer mmTimer = new Multimedia.Timer();
private Stopwatch scanClock = new Stopwatch();
mmTimer.Resolution = 1;
mmTimer.Period = 330;
scanClock.Start();
runDwell();
private void runDwell()
{
dwellPreTick = scanClock.ElapsedTicks;
mmTimer.Start();
}
private void mmTimer_Tick(object sender, EventArgs e)
{
dwellPostTick = scanClock.ElapsedTicks();
transPreTick = scanClock.ElapsedTicks();
if(stuffIsDone){
transPostTick = scanClock.ElapsedTicks;
scanClock.Stop();
storeTimingInfo();
}
else{
transPostTick = scanClock.ElapsedTicks;
storeTimingInfo();
runScanDwell();
}
}
Let me know. Thanks.
|
|
|
|
|
Hi,
The thread on which the timer runs remains alive after the timer is disposed. Is there any way to kill that thread, or is this behaviour by-design?
Thanks
Lee
|
|
|
|
|
Thank you Leslie Sanford!!
|
|
|
|
|
Love the control. It's great and allows me to get very close to 100ths of a second accuracy in triggering my reads. I'm finding that over time (even just 3 or 4 minutes) the timer will drift slightly and end up straying off the time I set (at least according to the system clock)
Is there any way to correct for that?
Thanks.
P.S. I posted this as a question on the VB.Net board as well to get other peoples input.
|
|
|
|
|
You will get timer drift in windows xp, the only way to address this is to do a manual check of the time when the event fires and if necessary then fire the event twice to make up for the timer drift. Its not ideal but it's the only way to address this.
Microsoft fixed the timer drift in windows 7, but it appears that they too just fire the event twice when they see that the timer has drifted. I suspect that the timer drift is directly related to the hardware you're using.
|
|
|
|
|
I have written an application that uses several (at one time, up to 4) MultimediaTimers running simultaneously. Some perform GUI update tasks while others talk to hardware. When all of them are running, resource-usage is high, but does not seem to be overwhelmingly so.
I have run into a few situations where I am repeatedly able to show that a MultimediaTimer will not re-start properly (e.g. no Tick events will occur after a Stop()/Start() cycle - verified with breakpoint debugging). My evidence that it is the MultimediaTimer causing this issue is that when I replace it with a System.Timers.Timer, the issue disappears (albeit with less than desirable timing characteristics).
I do like the accuracy advantages that the MultimediaTimer brings, but I cannot use it if it does not function well in a multiple-timer environment.
Has anyone else seen this? Is there a fix/workaround?
|
|
|
|
|
I 've found the same problem when i used this class.
it seems that after several start and stop ,the timer will work with start very well, but its Tick will not work property, partially in fact, and will never stop.
Winform's Timer doesn't have this kind of problem, although it is not accuracy at all with teen-ms.
|
|
|
|
|
hello,
I have a WPF application using the above timer, and it works perfect, but from time to time I get the following error:
CallbackOnCollectedDelegate was detected
Message: A callback was made on a garbage collected delegate of type 'CWUserInterface!Multimedia.Timer+TimeProc::Invoke'. This may cause application crashes, corruption and data loss. When passing delegates to unmanaged code, they must be kept alive by the managed application until it is guaranteed that they will never be called.
I need to specify that each timer instance goes into it's own thread, and I think that is where the error is coming from, now I also have read in some posts that I have to keep a pointer during the lifetime of the application to the control handler or something like that and frankly I don't quite get hot to do this, any help would be much appreciated
Thank you in advance
L.E.
Ok so I have placed try catch blocks all over the Timer code too try to catch the exception and I did at one point, seems it crashes in the OnTick event with an OutOfMemory exeption so something weird is going on
modified on Wednesday, April 13, 2011 3:50 AM
|
|
|
|
|
Quite long time I busy with development of integration none standard hardware with windows software, the software can talk simultaneously with different hardware and above that talk through tcp communication line with other software and other computers. Due to this I am looking for timers which can give better possibility to handle and synchronize such kind processes.
Last time I read about multimedia timers and found on internet this article.
First question which have been raised is how far the multimedia timer is better that let say System.Timers.Timer.
I have built simple test program with two timers. There are instantiated two timer (the class from this article and System.Timers.Timer). Two buttons on the form: Start and stop.
Both buttons start and stop both timers at the same time.
Each timer has own tick event, within the event they write when the event happaned (Console.Writels("Timer 1/2" & Now.TimeOfDay.TotalMilliseconds.tostring))
Both timers always had the same interval. I played with different intervals (5,10,20,50,100,200,500 ms).
The behavior was always the same: at the same time there were events from both timers up to 1 ms precision, no exceptions was found.
Only difference was in multimedia timer:
It gives more events inside the same timestamp. Suppose interval is 5 ms. if the program had not time chunk from CPU then after receiving the chunk the program shows simultaneously 3-4 fired events.
But from mine point of view it is pure waste of computer resources.
So, then is the question: What is advantage of using multimedia timer in comparing with System.Timers.Timer?
The test shows: there are no advantages.
Regards, Jamal
|
|
|
|
|
It sounds like your test is flawed due to its simplicity. Are there any resource-consuming processes or threads running in the background during this test? If not, I would not expect a significant difference in performance between the two timers as the message queue used by the System.Timers.Timer has relatively low traffic and can respond to timer messages in an accurate fashion. Try the same test, but with multiple background threads consuming resources (e.g. performing GUI changes), and see if the results remain the same. If they do, then you may have a point. I certainly have noticed a difference in my graphical application between the two timers.
That being said, it sounds like you are looking for a timer for the synchronization of TCP communication, and I would guess, without experience, that both of these timers are insufficient for that application.
All the best.
|
|
|
|
|
Thank you very much for this code - it's solved a nuggety little issue I was facing in 10 minutes flat instead of hours of doing my own coding. So thanks again.
|
|
|
|
|
Can I start up several instances of the timer? whit key work "new Timer"
br, Patrik
|
|
|
|
|
First of all, thanks for wrapping mmtimer. However, I did some bench marking and here are the results:
Period = 50, Res = 1, Min = 41.308, Max = 61.152, Avg = 49.994
Period = 20, Res = 1, Min = 16.921, Max = 21.685, Avg = 19.996
Period = 10, Res = 1, Min = 4.899, Max = 14.656, Avg = 9.996
Period = 5, Res = 1, Min = 0.033, Max = 17.212, Avg = 4.993
Period = 1, Res = 1, Min = 0.031, Max = 3.503, Avg = 0.993
Period = 1, Res = 1, Min = 0.031, Max = 2.24, Avg = 0.993
Period = 1, Res = 1, Min = 0.032, Max = 2.569, Avg = 0.993
Period = 1, Res = 1, Min = 0.019, Max = 3.452, Avg = 0.992
Period = 1, Res = 1, Min = 0.017, Max = 2.622, Avg = 0.996
I integrated the HiPerfTimer to get the exact tick count since elapsed event. I am not sure where is the problem, but reading msdn about managed vs unmanaged code I can see why the performance degradation.
http://msdn.microsoft.com/en-us/library/ms973872.aspx
Any hints why? I used the mmTimer on native C++ and I used to get exact timing. Wrapping mmTimer in managed code breaks its accuracy. Any help will be greatly appreciated. I apologies if I am double posting of this issue.
thanks
Laith
modified on Thursday, June 10, 2010 1:50 PM
|
|
|
|
|