I want to draw a realtime output-time graphic with vb. but mschart is not enough for that. i have looked up several URLs but nothing useful. can u advise any source for this?
What type of graphic, and what kind of response are you looking for? You can draw graphs directly with VB. You can also send data to another program if you like.
No disrespect intended, but I have found VB to be
fairly responsive in soft realtime apps. I once was
reading PLC registers serially and updating the screen
every 50 MS. I'm sure that it could get screwed up
somehow, but for me it seemed pretty decent.
I have used their DOS version in some products and didn't experience major problems.
Notice that when it comes to graphics linux won't give you any advantage (or just marginal improvement), nor will rtlinux because you can't update the graphs from a real time task, which means that you will have to update your
charts from a low priority linux task. If you need perfomance look in to QNX's direction or some of the "real time extensions" for windows... but that's another story.
50 ms _is_ a very generous definition of realtime.
I suppose it would depend on how you were doing it, and exactly what you are looking for, but VB wouldn't be my choice for time interval dot plotting (chart recorder type) unless the measured quantity changed very slowly so the uncertainty was a small part of the interval. It should be adequate for tank level or most temperature profiles, etc. Less so for motion or hydraulic pressure. A screen width (1024 pixels) would be 50 seconds.
But, it's apples and oranges anyways because Linux doesn't (Thank God) run VB. But, it's reasonable to assume that with careful coding you could be video frame rate limited. With a "normal" kernel, no RTL or RTAI.
I believe Mr. Wuollet's point about "real time" was valid, in that VB and Windows are not capable of real time response. If your I/O scanning and graph plotting are timed by software (VB) and you are using this to draw a graph where the 'x' axis is time, you cannot assume you can reliably achieve equal time increments (i.e. real time data plotting).
For example, if you use a VB timer control to trigger a "scan" every 50 ms in which you read an input and plot each new point on a strip chart scaled at equal 50 ms increments, you will have a randomly distorted graph. The
*actual* time interval will not always be 50 ms. Sometimes it will be some unpredictable longer period. The resulting distortion can be enough to be quite significant if you know what the graph is really supposed to look like.
One way of dealing with this can be to time stamp each data point and use the recorded time intervals to correctly scale each 'x' interval. Since the actual time interval is recorded and we are not assuming equal intervals, this is no longer a real time problem. In other words, since real time operation with Windows and VB is impossible, we could try to turn the problem into something that doesn't require real time.
The "soft real time" approach of assuming equal time intervals could be used if we were dealing with an operating system and programming language which were more capable of predictable response than Windows and VB.
--
************************
Michael Griffin
London, Ont. Canada
************************
I think the OP should clarify what he means by "real-time". Unfortunately, it is one of the least precise terms in common usage, as everyone is sure they know the "real" meaning, as with the blind men and the elephant.
It may be that what is meant here is "real-time" as in real-time stock quotes, which only means "as it happens", versus reading about the closing prices in the next day's paper. Probably the softest of soft real time. VB and Windows are certainly adequate for this type of work.
But Michael has a good point, in that your input data should be received timestamped by the device capturing the data, because the messaging will not be deterministic enough for accurate graphing (depending on your resolution requirements). You may also need to do some interpolation of the data points to match the native graphic resolution.
However, if you are looking to make a true "virtual oscilloscope", VB and Windows aren't the best at handling this natively.
And many of the calculations typically done om sampled datasets magnify this time distortion, it can even give bogus results, if for instance, one does an FFT on the dataset. Working on waveform acquisition and sample analysis and watching an analog scope on the same data can cause one to approach anything that is not a DC measurement with caution, if not skepticism. And even on DC measurements, I never trust a single sample to indicate much more than polarity. This is learned behaviour. Most PLC analog cards mitigate this with heavy filtering, but that has it's own infelicities.