 |
|
 |
Hello, I have problem with accuracy. I try make capturing time with 100ms period:
private void timer1_Tick(object sender, EventArgs e) { pole_dat.Add(DateTime.Now); }
where pole_dat is instance of arraylist
Timer has period 100 and accuracy 1.
Is it possible, thah i make some wrong. Thank you.
Full code:
using System; using System.Collections.Generic; using System.ComponentModel; using System.Data; using System.Drawing; using System.Linq; using System.Text; using System.Windows.Forms; using System.Collections;
namespace Vyzarovani { public partial class Form1 : Form { public Form1() { InitializeComponent(); } ArrayList pole_dat = new ArrayList();
private void button1_Click(object sender, EventArgs e) { if (!timer1.IsRunning) timer1.Start(); else { timer1.Stop(); foreach (DateTime polozka in pole_dat) { richTextBox1.Text += polozka.ToLongTimeString() + "." + polozka.Millisecond.ToString()+"\n"; } } }
private void timer1_Tick(object sender, EventArgs e) { pole_dat.Add(DateTime.Now); } } }
|
| Sign In·View Thread·PermaLink | |
|
|
|
 |
|
 |
I have found this article and source code very useful. Thank you for taking the time to put it together.
I have an issue that I hope someone can help me with:
In my application, I control hardware devices (e.g. a water pump that keeps a cup of water half full). I need to communicate with the water pump at accurate time intervals (100 milliseconds) to ensure that it keeps the water in the cup at the right level. I don't want to overfill the cup nor do I want the cup to be empty at any time. In order to control the pump correctly, the software needs to communicate with it at accurate time intervals. A periodic multimedia timer appears to be perfect for this job.
Using the sample application from this article, I set the Period to 100 millseconds and the Resolution to 1 milliseconds. When I run the sample application the events are fired at the expected 100ms (+-1ms) intervals. Great!
However, if I then MAXIMISE and MINIMISE the application, everything goes out the window. The MMTimer events are delayed by more than 300 milliseconds !!! 
The MMTimer events are also delayed when:
- Opening, closing, minimising, maximising a windows explorer window - When my screensaver fires up while the application is running. Note: My screensaver displays my photos on the PC, standard windows screensavers do not appear to cause such a big problem.
I investigated further by building a console application (using timeSetEvent etc). Not using a form appears to improve things, but still not all the events are accurate.
Can anyone indicate what is preventing my events from firing at accurate time intervals?? Is there anything that I can do to fix this problem?
Any help is greatly appreciated. 
|
| Sign In·View Thread·PermaLink | |
|
|
|
 |
|
 |
Windows is not a REALTIME OS. Avery timer can "flash" only if there is empty processing timeslots for its thread. Try to increase process priority level for your application but be careful with hanging your PC. PS. Sorry for my English: can read, but cant write.
|
| Sign In·View Thread·PermaLink | |
|
|
|
 |
|
|
 |
|
 |
i have an error when i open the form1 in the demo like this:
Could not find type 'Multimedia.Timer'. Please make sure that the assembly that contains this type is referenced. If this type is a part of your development project, make sure that the project has been successfully built.
and i am looking for answers in the discussion board.
i see "1 2 3 4 5",and i think they are pages, so i click "2" to enter the next page.but system told me i vote 2.
sorry for a mistake.
|
| Sign In·View Thread·PermaLink | |
|
|
|
 |
|
|
 |
|
 |
Hello
I found an issue with the design. OneShot Mode does not work if you do not specify a SyncronizingObject. In most cases this is probably ok, it is not a good restriction to live with though.
Thanks, Patrick
|
| Sign In·View Thread·PermaLink | 1.00/5 (2 votes) |
|
|
|
 |
|
 |
patrickcbrown wrote: I found an issue with the design. OneShot Mode does not work if you do not specify a SyncronizingObject. In most cases this is probably ok, it is not a good restriction to live with though.
Here's the code from the callback that handles the one shot mode:
if(synchronizingObject != null) { synchronizingObject.BeginInvoke(tickRaiser, new object[] { EventArgs.Empty }); Stop(); } else { OnTick(EventArgs.Empty); Stop(); }
So even if the synchronizingObject is null, the Tick event should still be raised. Have you found this not to be the case?
|
| Sign In·View Thread·PermaLink | |
|
|
|
 |
|
 |
Hi
Yes, the tick was raised, the issue in my implementation is that it would only be raised one time because I was calling Start in my TickHandler - which was immediatly followed by your call to Stop(). It is right that it was called once, my issue is that it was not restartable.
Thanks Patrick
|
| Sign In·View Thread·PermaLink | |
|
|
|
 |
|
 |
patrickcbrown wrote: Yes, the tick was raised, the issue in my implementation is that it would only be raised one time because I was calling Start in my TickHandler - which was immediatly followed by your call to Stop(). It is right that it was called once, my issue is that it was not restartable.
Oh, I see! I will have to change that.
|
| Sign In·View Thread·PermaLink | |
|
|
|
 |
|
 |
Hi
You know what it is. I use the timer in a ManualReset kind of mode. So, in my tick handler I do some work, change the Period, then tell it to start again. The current TickCallback in your code calls my tick handler, I do my work, then tell the timer to restart, you get control back then tell my started timer to Stop! Darn you - not nice - j/k. I swapped the Stop and OnTick lines, I am in business.
Old Code
private void TimerOneShotEventCallback(int id, int msg, int user, int param1, int param2) { if (synchronizingObject != null) { synchronizingObject.BeginInvoke(tickRaiser, new object[] { EventArgs.Empty }); Stop(); } else { OnTick(EventArgs.Empty); Stop(); } }
New Patrick Brown version
private void TimerOneShotEventCallback(int id, int msg, int user, int param1, int param2) { if (synchronizingObject != null) { synchronizingObject.BeginInvoke(tickRaiser, new object[] { EventArgs.Empty }); Stop(); } else { Stop(); OnTick(EventArgs.Empty); } }
Thanks Patrick
|
| Sign In·View Thread·PermaLink | |
|
|
|
 |
|
 |
Hi, in a C++ program of mine I carried out timeBeginPeriod before timeSetEvent and accordingly timeEndPeriod after timeKillEvent. I wonder why you haven't done so. Well - I set breakpoints in timeBeginPeriod/timeEndPeriod and realise, that timeSetEvent or timeKillEvent call timeBeginPeriod or timeEndPeriod, respectively. However, every single source I found on the internet recommends seperate timeBeginePeriod/timeEndPeriod. Even the Platform SDK seems to distinguish: "After you have established your application's timer resolution," [ie, by timeBeginPeriod] "you can start timer events by using the timeSetEvent function.".
What do you think?
Well - before I forget it: Thanks for this great example and demonstration!
|
| Sign In·View Thread·PermaLink | |
|
|
|
 |
|
 |
Hello and thank you for the code.
I also think you have to explicitly call timeBeginPeriod and timeEndPeriod.
I started out to use this class but didn't get the desired effect, there was a lot of jitter in my output signals. I use the multimedia timer to switch off the transmitter with RTS in a half duplex RS485 application. Changing the resolution parameter didn't seem to change anything. I stripped down everything and just used timeSetEvent as a one shot timer and a callback function. This still didn't change anything.
All of a sudden all seemed to work just fine. Rock solid timing events with no jitter. At first I didn't understad what had changed but it turned out to be a multimeda application running in the background. In this case it was Quick Time player that was started and running in the background (paused though).
Closing Quick Time player got my jitter back. Calling timeBeginPeriod with the desired reolution before using the timer fixed it.
Just thought I should mention it if there are others with the same problem.
Again, thanks for the code.
/Ruben
|
| Sign In·View Thread·PermaLink | 5.00/5 (3 votes) |
|
|
|
 |
|
 |
I loaded the demo project in VS 2005 and tried to look at Form1.cs in the designer. I got the following errors:
Warning 1 The path is not of a legal form. 0 0 Warning 2 Could not resolve this reference. Could not locate the assembly "StateMachineToolkit". Check to make sure the assembly exists on disk. If this reference is required by your code, you may get compilation errors. MultimediaTimerDemo Warning 3 The referenced component 'StateMachineToolkit' could not be found.
It also didn't display the form but just an error message about "The path is not of a legal form".
I can run the demo though and it displays the form correctly.
Other than that, this seems to be a great contribution. Very well written and commented as far as I can tell. I'm still studying it -- I haven't figured out how to "drag and drop" it as a component yet, but I will figure it out...
Thanks!
David Messer mailto:DLMSoftware@pobox.com
|
| Sign In·View Thread·PermaLink | 2.00/5 (2 votes) |
|
|
|
 |
|
 |
Followup: I removed the reference to 'StateMachineToolkit' and now it displays in the form designer.
David
|
| Sign In·View Thread·PermaLink | |
|
|
|
 |
|
 |
I used the StateMachineToolkit assembly in a previous version of the Timer. I must have forgotten to remove the reference from the project for the lastest version; it no longer uses the StateMachineToolkit.
|
| Sign In·View Thread·PermaLink | 2.00/5 (1 vote) |
|
|
|
 |
|
 |
http://blogs.msdn.com/larryosterman/archive/2005/09/08/462477.aspx http://blogs.msdn.com/oldnewthing/archive/2005/01/05/346888.aspx
Is it still save to use this class?
|
| Sign In·View Thread·PermaLink | |
|
|
|
 |
|
 |
Hi,
Thanks for the links. I will have to study the problem a little more before drawing any conclusions. I know that in the time I've used timeSetEvent I've not run into any problems. Maybe I can switch out timeSetEvent for timeBeginPeriod? I'll check into it.
|
| Sign In·View Thread·PermaLink | |
|
|
|
 |
|
 |
Thank you Leslie for the fast reply!
I think, as stated in the first article, CreateTimerQueueTimer (Kernel32.dll) should be used instead of timeSetEvent. Here's the C Sample code http://msdn.microsoft.com/library/default.asp?url=/library/en-us/dllproc/base/using_timer_queues.asp
|
| Sign In·View Thread·PermaLink | 2.00/5 (1 vote) |
|
|
|
 |
|
 |
Note that when timeSetEvent is configured to use a callback and not an event, the PulseEvent API is never used. In fact, the two methods use separate code paths in the internal dispatcher (WINMM!TimerCompletion).
|
| Sign In·View Thread·PermaLink | |
|
|
|
 |
|
 |
Leslie,
First off let me say thanks for one of the best examples of well commented and written code!
Question about threads and events? Does a fired event always occur in its own thread or, should I say, is each instance of a timer created on its own thread or is the SynchronizingObject only needed if one creates a new thread and then starts the timer on the new thread?
Thanks, David
|
| Sign In·View Thread·PermaLink | 2.00/5 (1 vote) |
|
|
|
 |
|
 |
dmbrider wrote: First off let me say thanks for one of the best examples of well commented and written code!
Thank you!
dmbrider wrote: Does a fired event always occur in its own thread or, should I say, is each instance of a timer created on its own thread or is the SynchronizingObject only needed if one creates a new thread and then starts the timer on the new thread?
Each multimedia Timer instance runs in its own thread; it doesn't matter which thread the Timer was created in. So at least with the Tick event, you're receiving an event that's occuring on its own thread. If you're responding to this event in a Form, I would recommend always initializing the Timer's SynchronizingObject property with that Form. This way, the Timer takes care of marshaling its events to the Form's thread so you don't have to check the Form's InvokeRequired property. Hope this helps.
|
| Sign In·View Thread·PermaLink | |
|
|
|
 |
|
|
 |
|
 |
On my NT4 machine I get app lockups when stopping the timer if it's going on a rapid rate. above 100ms I've yet to see a fairure, below 10ms it always freezes, between those two values the lockup rate seems dependent on the speed, with a faster timer freezing more often than a slower one. When it freezes my handler for the stop event doesn't fire.
My 1.1 testapp only handles the tick and stop events. Tick writes System.DateTime.Now with the ms into a listbox. Stop just spits up a messagebox.
Is this an NT4 issue, or am I missing something in my tester?
|
| Sign In·View Thread·PermaLink | |
|
|
|
 |
|
 |
dan neely wrote: Is this an NT4 issue, or am I missing something in my tester?
It could be, but I don't know. I haven't seen this behavior before. Have you initialized the Timer's SynchronizingObject property with the form that displays the listbox?
Since I can't reproduce this behavior, all I can do is guess that the form can't keep up with timer events occuring below 10ms, at least on NT4. Can you trade out the timer with one of the .NET timers and use a tick interval lower than 100ms just to see what happens?
You could also try a console app to see if it also freezes there as well.
Sorry I don't have more to offer. This is one of those times when it's frustrating because I can't reproduce the behavior on my end.
|
| Sign In·View Thread·PermaLink | |
|
|
|
 |