Is VB a suitable language for ...

Is VB a suitable language for ...

Post by Naran Hiran » Mon, 07 Jul 2003 07:01:10



Hi,

I need to re-write a very old C/C++ real-time application written in the
days when MS/PC-DOS was king.  The reason for the re-write is that the
application needs some new functionality, but more crucially, some
existing functionality does not seem to work on the current MS OSs.

The application works with a bespoke electrical gadget which emits a
radio wave signal at a fixed frequency.  This gadget is mounted on a
trolley, and when switched on sends radio waves back to a receiver
attached to a pc via its com port.  As the trolley is moved forward, the
receiver picks up the signals emitted from the device on the trolley.
The captured signals are read by the application via the PCs com port.
The application then analyses these signals in real-time plotting a
graph based on the distribution of the signals over time, measured using
the PCs clock ticks etc.  The data collected in this way gets further
analysed off-line using fairly basic statistical techniques to calculate
variance, co-variance, average trolley speed, etc.

The application does not seem to be able to display this graph correctly
in real time on the more modern OSs, e.g. W2K and WME.

I suspect this may be something to do with how things have changed so
much at the bios/com level and the best way forward may be to simply
re-write the darn thing rather than try to figure out the real problem.

I was therefore wondering what you guys think about using VB for this
all new application?

Do you think VB can cut it? or is there a better, more appropriate
language for this sort of application?

Any ideas, comments or suggestions would be very welcome.

Naran Hirani

 
 
 

Is VB a suitable language for ...

Post by Pat Kohl » Tue, 08 Jul 2003 12:45:03



> (snip)

> The application does not seem to be able to display this graph correctly
> in real time on the more modern OSs, e.g. W2K and WME.

Do these OSes support real time operation?

W/ the kernel running virtual memory tasks, I'd suspect that one would need
to get kernel level priority to preempt other tasks and run your app in real
time.

I have the impression that Win2K supports time slicing to resolutions of 10
milliseconds; I don't know if ME is any better.

(snip)

Best wishes!
- Pat
kohli at ameritel.net

 
 
 

Is VB a suitable language for ...

Post by Stev » Wed, 09 Jul 2003 12:20:30


From your description, it doesn't seem to be so much of a programming
language issue as a timing requirements issue.

While I haven't used much VB myself, there should be no reason you can't
meet your requirments using VB equally well as any other programming
language IF you can meet your timing requirements under W2K.

Do you have any idea what your timing constraints are?

Steve
(The Duck)


Quote:> Hi,

> I need to re-write a very old C/C++ real-time application written in the
> days when MS/PC-DOS was king.  The reason for the re-write is that the
> application needs some new functionality, but more crucially, some
> existing functionality does not seem to work on the current MS OSs.

> The application works with a bespoke electrical gadget which emits a
> radio wave signal at a fixed frequency.  This gadget is mounted on a
> trolley, and when switched on sends radio waves back to a receiver
> attached to a pc via its com port.  As the trolley is moved forward, the
> receiver picks up the signals emitted from the device on the trolley.
> The captured signals are read by the application via the PCs com port.
> The application then analyses these signals in real-time plotting a
> graph based on the distribution of the signals over time, measured using
> the PCs clock ticks etc.  The data collected in this way gets further
> analysed off-line using fairly basic statistical techniques to calculate
> variance, co-variance, average trolley speed, etc.

> The application does not seem to be able to display this graph correctly
> in real time on the more modern OSs, e.g. W2K and WME.

> I suspect this may be something to do with how things have changed so
> much at the bios/com level and the best way forward may be to simply
> re-write the darn thing rather than try to figure out the real problem.

> I was therefore wondering what you guys think about using VB for this
> all new application?

> Do you think VB can cut it? or is there a better, more appropriate
> language for this sort of application?

> Any ideas, comments or suggestions would be very welcome.

> Naran Hirani

 
 
 

Is VB a suitable language for ...

Post by Paul Keinane » Wed, 09 Jul 2003 16:06:48


On Tue, 08 Jul 2003 03:20:30 GMT, "Steve"


>From your description, it doesn't seem to be so much of a programming
>language issue as a timing requirements issue.

>While I haven't used much VB myself, there should be no reason you can't
>meet your requirments using VB equally well as any other programming
>language IF you can meet your timing requirements under W2K.

It is possible to write a console (command line mode) application in
WinNT based operating systems with soft real time performance well
below 100 ms, but trying to get any timing accuracy from a GUI based
(windowed) _single_ thread application is pointless, unless your
timing requirements are in the order of seconds.

The time critical part should definitively run in a separate high
priority thread that does not use the ordinary Windows message queue
mechanism. The user interface part can run in an ordinary priority GUI
thread.

I have no idea, if current versions of VB supports directly
multithreading, but at least the normal VB part is good for data
representation and display as an ordinary priority thread.

As far as I understand, the VB allows execution of programs written in
other programming languages to be loaded into the VB environment as
DLLs. You could write a DLL in C, which starts a high priority C-thrad
that does all the time critical processing and delivers the results to
the VB environment for post processing and display.

In this high priority C-thread use multimedia timers,
WaitForSingleObject (with timeout parameter) functions for relatively
good timing accuracy. Stay away from the SetTimer function, since it
uses the message queue even if no window handle is provided, thus
destroying any timing accuracy.

Even if VB would directly support multithreading, you have to check
that the other threads can be run independently of the Windows message
queue.

Paul