-
Dec 7th, 2017, 09:41 AM
#41
Re: Timer not acting as I expect
Originally Posted by kpmc
Also, it's not too often I need to consult MSDN for deep dives. This would have been one of them, I simply cant do that while im on the clock. I figured it would be faster to pick your brains.
Except this would certainly not have been one of them. It would have been five minutes to get what I posted, tops. In my opinion, you should try first and if it looks like it's going to be too hard or take too long then by all means ask, but let us know what you've already looked at. If you just assume that it's going to be a deep dive every time then you really are taking advantage. Sure, we have the option to ignore your posts if we don't want to answer but you have the same option to ignore our posts if we point out that you're being lazy. I'm often accused of being rude if I do point out such things. I can live with that, because I think it's rude to assume that it's OK to get other people to do your work for you. The fact that some will doesn't make it any less rude. Again, I'm not saying that people shouldn't post questions here. I'm saying that they should make an effort for themselves first and avoid posting the easy questions because they can't be bothered looking it up or they just assume that it will take a long time when, in fact, they have no good reason to believe that without having made an effort first.
-
Dec 7th, 2017, 09:51 AM
#42
Thread Starter
Fanatic Member
Re: Timer not acting as I expect
If you look back at post#1 it is clear that there are all sorts of reasons it didnt work as I expected, the last thing I figured was the interval resolution was not that of what I would expected. Technically I didnt even know what to research, thus would have been reading the entire class documentation, Which yes, I could have probably read twice by now.
-
Dec 7th, 2017, 10:09 AM
#43
Re: Timer not acting as I expect
I agree. I was a bit surprised at the answers to this. While they were right, I felt the original issue was a misunderstanding as to what the timer did, and I don't feel that MSDN explains that as well. MSDN is good for getting the details of how something works as long as you already have a reasonable correct mental model as to how it works. A tutorial works better if your mental model is either wrong, or if you don't have one yet, and that seemed more the case.
My usual boring signature: Nothing
-
Dec 7th, 2017, 11:25 AM
#44
Re: Timer not acting as I expect
I agree, MSDN is like a math textbook in that it's most efficient if you sort of already know what you're looking for but need some refreshers. Once you have some degree of experience you start to get intution about where you might look, but even 10 years in there's still days where I hit 20+ pages and still can't find precisely what I want. I don't really get a big boner out of bragging that I can navigate to a thing you already knew. It's like someone asked you how to whistle and you gave them sheet music for the Star Spangled Banner.
As to the behavior of the Tick event, it's good to know the WinForms one isn't "greedy" like that. It makes using Timer for a high-speed render loop still a bad idea, but for different reasons. I thought about playing with the other timers I mentioned, it's a Windows API so you can always wrap it with P\Invoke, but it's a project for another day. There are promising StackOverflow posts indicating it mostly does what you ask for, but you still have to handle an interesting scenario:
Say you ask for a 1ms interval. Because Windows does preemptive multitasking, there's always some chance a higher-priority process will starve the time slices and delay your timer ticks. When that happens, you'll get all of the ticks you "missed" in quick succession. That's fine for this progress bar case but disastrous if you're trying to poll a device at regular intervals.
Again, I have to speak as an engineer who did work in data acquisition.
Decent hardware that needs to sample at very high intervals comes with its own internal clock and large buffers. That hardware will let you configure it to sample at high rates into its buffers, and your WinForms application will empty and process the buffers at a lower rate. This lets the hardware sample at rates Windows can't imagine (gigasamples per second are common in even mid-range equipment) and Windows can chew through the data at its leisure.
Cheaper hardware can still be decent, but won't come with those features. High-speed clocks and buffers are pretty darn expensive, as are the data buses you need for them. But you can't really make Windows behave like anything other than a preemptive multitasking system. If you have this kind of hardware and need very high-speed sampling at reliable intervals, your only real option is to drop Windows in favor of a specialized real-time OS.
So in short:
- In general, most PCs don't provide hardware capable of high-resolution sampling.
- The Windows architecture doesn't make reliable polling intervals possible.
- Most WinForms applications have no need for an interval faster than 250ms.
- DAQ applications that do need high-resolution timers tend to use hardware that provides high-resolution sampling with buffers to account for Windows' irregularities.
- The hungriest DAQ applications can't use Windows because it isn't designed for their use case.
This answer is wrong. You should be using TableAdapter and Dictionaries instead.
Posting Permissions
- You may not post new threads
- You may not post replies
- You may not post attachments
- You may not edit your posts
-
Forum Rules
|
Click Here to Expand Forum to Full Width
|