timer
-
Hello everyone, really struggling here......Can someone clear up a few issues for an inexperienced C# student...I need to implement a precise timer (ie not the ones supplied invisual studio.net)I need the timer component to act 1) like the .Net timers available ie. i set a time say 2 seconds and when this time has a elapsed an event is raised? 2) the elapsed time that raises an event may be less than 1 second that is something like miliseconds. 3)i implement several of these timers in one single application (perhaps using threads)? Basically I am communicating serially with another computer (was quite difficult using C# until I discovered somewhere that you can use the MSCOMM control)... and I need to set up several timeouts. For instance I send several messages to the other computer and for each message I expect a reply in a certain amount of time. So I send a message and then I want to start a timer... when a certain amount of time elapses say 500 milliseconds then i want an event to be raised as a visual studio timer would do..... If anybody has any comments advice snippets of code with a little explanation or even other sources of help .... i would be truly grateful! Maria (phillips_maria@hotmail.com)
-
Hello everyone, really struggling here......Can someone clear up a few issues for an inexperienced C# student...I need to implement a precise timer (ie not the ones supplied invisual studio.net)I need the timer component to act 1) like the .Net timers available ie. i set a time say 2 seconds and when this time has a elapsed an event is raised? 2) the elapsed time that raises an event may be less than 1 second that is something like miliseconds. 3)i implement several of these timers in one single application (perhaps using threads)? Basically I am communicating serially with another computer (was quite difficult using C# until I discovered somewhere that you can use the MSCOMM control)... and I need to set up several timeouts. For instance I send several messages to the other computer and for each message I expect a reply in a certain amount of time. So I send a message and then I want to start a timer... when a certain amount of time elapses say 500 milliseconds then i want an event to be raised as a visual studio timer would do..... If anybody has any comments advice snippets of code with a little explanation or even other sources of help .... i would be truly grateful! Maria (phillips_maria@hotmail.com)
What's wrong with
System.Threading.Timer? TheTimerCallbackis executed in a separate thread which is one of your requirements. For even more accuracy (according to the .NET Framework SDK), you can use a server-based timer likeSystem.Timers.Timer. If you want to use native function, you have to P/Invoke it and worry about marshaling parameters (depending on the native function called). The very act of marshaling could degrade accuracy over time, whereas theSystem.Threading.Timeris internally managed by the CLR. The other two callCreateWaitableTimer. So, basically, either you P/Invoke the methods or use the timers that do, or useSystem.Threading.Timerwhich should be about as accurate as you can get with the class library since it's managed internally by the CLR.-----BEGIN GEEK CODE BLOCK----- Version: 3.21 GCS/G/MU d- s: a- C++++ UL@ P++(+++) L+(--) E--- W+++ N++ o+ K? w++++ O- M(+) V? PS-- PE Y++ PGP++ t++@ 5 X+++ R+@ tv+ b(-)>b++ DI++++ D+ G e++>+++ h---* r+++ y+++ -----END GEEK CODE BLOCK-----
-
What's wrong with
System.Threading.Timer? TheTimerCallbackis executed in a separate thread which is one of your requirements. For even more accuracy (according to the .NET Framework SDK), you can use a server-based timer likeSystem.Timers.Timer. If you want to use native function, you have to P/Invoke it and worry about marshaling parameters (depending on the native function called). The very act of marshaling could degrade accuracy over time, whereas theSystem.Threading.Timeris internally managed by the CLR. The other two callCreateWaitableTimer. So, basically, either you P/Invoke the methods or use the timers that do, or useSystem.Threading.Timerwhich should be about as accurate as you can get with the class library since it's managed internally by the CLR.-----BEGIN GEEK CODE BLOCK----- Version: 3.21 GCS/G/MU d- s: a- C++++ UL@ P++(+++) L+(--) E--- W+++ N++ o+ K? w++++ O- M(+) V? PS-- PE Y++ PGP++ t++@ 5 X+++ R+@ tv+ b(-)>b++ DI++++ D+ G e++>+++ h---* r+++ y+++ -----END GEEK CODE BLOCK-----
Firstly I thank you for your reply (i have never used a message board before). Secondly to bug you some more... I don't know if i was told the wrong thing but i was told that for automation purposes using operating system timers wasn't a good idea... do u have any thoughts on this? When i say automation... my application will control a couple of robots.... If say I were to use the timers that you have mentioned above ... is there a way of finding out the resolution of their Ticks? also which of the above timers should i use? And you say that this is as accurate as i'm going to get?
-
Firstly I thank you for your reply (i have never used a message board before). Secondly to bug you some more... I don't know if i was told the wrong thing but i was told that for automation purposes using operating system timers wasn't a good idea... do u have any thoughts on this? When i say automation... my application will control a couple of robots.... If say I were to use the timers that you have mentioned above ... is there a way of finding out the resolution of their Ticks? also which of the above timers should i use? And you say that this is as accurate as i'm going to get?
As far as the resolution of the three timers in the .NET base class library go, the
System.Windows.Forms.Timeruses the nativeSetTimerAPI, which uses time in milliseconds.System.Timers.Timeruses the nativeSetWaitableTimerand then uses aWaitableTimer(internal class) which callsSetWaitableTimer. This native function uses ticks - or 100 nanoseconds. Unfortunately, theSystem.Timers.Timer.Intervalproperty takes time in milliseconds, thus decreasing the resolution. :( TheSystem.Threading.Timeris mostly managed internally, so we can't know for sure how it works, but the documentation states that the interval is also specified in milliseconds. So, the resolution of the timers in the .NET base class library is 1 millisecond. If you want to wrapCreateWaitableTimer,SetWaitableTimer, andCancelWaitableTimerin order to use ticks for better resolution, you can. The difference in time may make up for any time spent marshaling parameters. Of course, as long as you stick with the intrinsic types (int,long,double,byte, etc.), the SDK states that no time is spent marshaling since it is unnecessary. As far as using timers besides those provided by the OS, I'm not really sure what else you'd use besides a timer card[^]. The resolution of a few of those cards isn't any better (some are even measured in seconds!) but you might get more accurate results taking only the hardware into account. Since each will most likely come with a C SDK, you might find yourself worrying about marshaling again. Since you mentioned in your last post that these are to control robots, I would recommend you find some resources online regarding programming robots to find out how others accomplish that. The only experience I've had is reading a little about programmable robots with their own controller boards (a former-coworker of mine did the work, but I was passively curious at best).-----BEGIN GEEK CODE BLOCK----- Version: 3.21 GCS/G/MU d- s:
-
As far as the resolution of the three timers in the .NET base class library go, the
System.Windows.Forms.Timeruses the nativeSetTimerAPI, which uses time in milliseconds.System.Timers.Timeruses the nativeSetWaitableTimerand then uses aWaitableTimer(internal class) which callsSetWaitableTimer. This native function uses ticks - or 100 nanoseconds. Unfortunately, theSystem.Timers.Timer.Intervalproperty takes time in milliseconds, thus decreasing the resolution. :( TheSystem.Threading.Timeris mostly managed internally, so we can't know for sure how it works, but the documentation states that the interval is also specified in milliseconds. So, the resolution of the timers in the .NET base class library is 1 millisecond. If you want to wrapCreateWaitableTimer,SetWaitableTimer, andCancelWaitableTimerin order to use ticks for better resolution, you can. The difference in time may make up for any time spent marshaling parameters. Of course, as long as you stick with the intrinsic types (int,long,double,byte, etc.), the SDK states that no time is spent marshaling since it is unnecessary. As far as using timers besides those provided by the OS, I'm not really sure what else you'd use besides a timer card[^]. The resolution of a few of those cards isn't any better (some are even measured in seconds!) but you might get more accurate results taking only the hardware into account. Since each will most likely come with a C SDK, you might find yourself worrying about marshaling again. Since you mentioned in your last post that these are to control robots, I would recommend you find some resources online regarding programming robots to find out how others accomplish that. The only experience I've had is reading a little about programmable robots with their own controller boards (a former-coworker of mine did the work, but I was passively curious at best).-----BEGIN GEEK CODE BLOCK----- Version: 3.21 GCS/G/MU d- s:
-
As far as the resolution of the three timers in the .NET base class library go, the
System.Windows.Forms.Timeruses the nativeSetTimerAPI, which uses time in milliseconds.System.Timers.Timeruses the nativeSetWaitableTimerand then uses aWaitableTimer(internal class) which callsSetWaitableTimer. This native function uses ticks - or 100 nanoseconds. Unfortunately, theSystem.Timers.Timer.Intervalproperty takes time in milliseconds, thus decreasing the resolution. :( TheSystem.Threading.Timeris mostly managed internally, so we can't know for sure how it works, but the documentation states that the interval is also specified in milliseconds. So, the resolution of the timers in the .NET base class library is 1 millisecond. If you want to wrapCreateWaitableTimer,SetWaitableTimer, andCancelWaitableTimerin order to use ticks for better resolution, you can. The difference in time may make up for any time spent marshaling parameters. Of course, as long as you stick with the intrinsic types (int,long,double,byte, etc.), the SDK states that no time is spent marshaling since it is unnecessary. As far as using timers besides those provided by the OS, I'm not really sure what else you'd use besides a timer card[^]. The resolution of a few of those cards isn't any better (some are even measured in seconds!) but you might get more accurate results taking only the hardware into account. Since each will most likely come with a C SDK, you might find yourself worrying about marshaling again. Since you mentioned in your last post that these are to control robots, I would recommend you find some resources online regarding programming robots to find out how others accomplish that. The only experience I've had is reading a little about programmable robots with their own controller boards (a former-coworker of mine did the work, but I was passively curious at best).-----BEGIN GEEK CODE BLOCK----- Version: 3.21 GCS/G/MU d- s:
I read this on code project.... "Not long time ago, I was programming an application for Windows that every certain time had to execute a task; in the development of the project everything went with normality but arrived the day to prove the program in the definitive machines where it had to remain working, and we observed that once in a while timers stopped working. We did thousand verifications always reaching the same result, sometimes, timers provided by the Framework don't tick, no events fired. It was then when we began to look for a solution to replace these timers and the solution that seemed better to me was the one to replace them by timers of the API of Windows. We looked on the Internet in case somebody had had the same idea that I had, without success, and therefore put hands to the work." the address for this article is http://www.codeproject.com/csharp/FTwin32Timers.asp?target=timers Does anyone have any comments? In my application i really cannot afford for a timer not to fire. maria
-
I read this on code project.... "Not long time ago, I was programming an application for Windows that every certain time had to execute a task; in the development of the project everything went with normality but arrived the day to prove the program in the definitive machines where it had to remain working, and we observed that once in a while timers stopped working. We did thousand verifications always reaching the same result, sometimes, timers provided by the Framework don't tick, no events fired. It was then when we began to look for a solution to replace these timers and the solution that seemed better to me was the one to replace them by timers of the API of Windows. We looked on the Internet in case somebody had had the same idea that I had, without success, and therefore put hands to the work." the address for this article is http://www.codeproject.com/csharp/FTwin32Timers.asp?target=timers Does anyone have any comments? In my application i really cannot afford for a timer not to fire. maria
I have commented on this before. The timers in .NET use the Windows APIs! Perhaps there's a bug when they encapsulated the API calls, or perhaps the thread in which the elapsed handler was executed and the base .NET implementation didn't account for that. Either way, they still rely on the Windows APIs as most things do in .NET. Use FTwin32Timers if you want. At most, maybe it has better exception handling. If you write your program well-enough, you shouldn't experience any problems since they most likely call the same APIs. Otherwise - as I mentioned before - look into a hardware-based solution but you'll be forced to encapsulate their APIs as well.
Microsoft MVP, Visual C# My Articles