TCL for real-time control app? 
Author Message
 TCL for real-time control app?

        Can anyone give me some advice?

        I'm slated to develop a GUI console application for a
large mechanical system.  The current plan is to connect a
SparcStation to a number of separate VME chassis; each VME
chassis will in turn be controlling an independent
mechanism.  Communications between the VMEs and Sparc will be via
Sockets.

        One possibility that has been mentioned for this console
app is implementing it via TCL.  I don't know anything about TCL,
but, in view of what will probably be the asynchronous,
event-driven environment that the console needs to deal with, I
am worried that a script language will not be up to the task.

        Does anyone have any experience (good or bad) using TCL
to monitor and control real-time and/or event-driven processes?  
I don't (as usual!) have a huge amount of time to decide this
fundamental architectural question; I will make a substantial
contribution to the karma of anyone kind enough to give me their
wisdom.

        Thanks.

        Randall Smith



Tue, 14 Jul 1998 03:00:00 GMT  
 TCL for real-time control app?
        Can anyone give me some advice?

        I'm slated to develop a GUI console application for a
large mechanical system.  The current plan is to connect a
SparcStation to a number of separate VME chassis; each VME
chassis will in turn be controlling an independent mechanism.  
Communications between the VMEs and Sparc will be via Sockets.

        One possibility that has been mentioned for this console
app is implementing it via TCL.  I don't know anything about TCL,
but, in view of what will probably be the asynchronous,
event-driven environment that the console needs to deal with, I
am worried that a script language will not be up to the task.

        Does anyone have any experience (good or bad) using TCL
to monitor and control real-time and/or event-driven processes?  
I don't (as usual!) have a huge amount of time to decide this
fundamental architectural question; I will make a substantial
contribution to the karma of anyone kind enough to give me their
wisdom.

        Thanks.

        Randall Smith

--



Tue, 14 Jul 1998 03:00:00 GMT  
 TCL for real-time control app?
:       Can anyone give me some advice?

The best person to turn to on Real-time TCL applications is CPU. CPU has
a regular reader of this newsgroup in Gerald Lester. Or you might want to
try e-mailing him (he puts out the on Commercial Applications)

Company: Computerized Processes Unlimited
Contact: Gerald W. Lester

PS: Don't be surprised if he offers "training" :-)

jmi



Tue, 14 Jul 1998 03:00:00 GMT  
 TCL for real-time control app?

Quote:

>    Does anyone have any experience (good or bad) using TCL
> to monitor and control real-time and/or event-driven processes?  
> I don't (as usual!) have a huge amount of time to decide this
> fundamental architectural question; I will make a substantial
> contribution to the karma of anyone kind enough to give me their
> wisdom.

We made the jump to TCL/TK last year for the user interface portion
of our real time status mapping application.  We respond to events
generated from a Computer Aided Dispatch System, an E-911 interface,
and Automated Vehicle Location system (GPS), and a radio system.

Our system isn't strictly real time, but we're real time as far as
operator is concerned.  So far, TCL/TK doesn't seem to be getting in
our way.  In fact, the more we work with it, the more functionality
we keep moving out to the TCL/TK level rather than C code.



Fri, 17 Jul 1998 03:00:00 GMT  
 TCL for real-time control app?

Quote:

>    Can anyone give me some advice?
>    I'm slated to develop a GUI console application for a
>large mechanical system.  The current plan is to connect a
>SparcStation to a number of separate VME chassis; each VME
>chassis will in turn be controlling an independent mechanism.  
>Communications between the VMEs and Sparc will be via Sockets.
>    One possibility that has been mentioned for this console
>app is implementing it via TCL.  I don't know anything about TCL,
>but, in view of what will probably be the asynchronous,
>event-driven environment that the console needs to deal with, I
>am worried that a script language will not be up to the task.
>    Does anyone have any experience (good or bad) using TCL
>to monitor and control real-time and/or event-driven processes?  
>I don't (as usual!) have a huge amount of time to decide this
>fundamental architectural question; I will make a substantial
>contribution to the karma of anyone kind enough to give me their
>wisdom.
>    Thanks.
>    Randall Smith
>--


Yes,  I've used TCL/TK to control a couple of real-time processes
(some engineering system models with synchronized disgitized sound
playback to go along with them). This was done on some SGI machines
under UNIX.  We used pipes, shared memory and message queues from
TCL/TK.

It was really pretty easy to put together and the results were quite
good.  TCL/TK provided a quick means for producing a very professional
graphical front end to the application.



Sat, 18 Jul 1998 03:00:00 GMT  
 TCL for real-time control app?

Quote:

> >       Does anyone have any experience (good or bad) using TCL
> > to monitor and control real-time and/or event-driven processes?
> > I don't (as usual!) have a huge amount of time to decide this
> > fundamental architectural question; I will make a substantial
> > contribution to the karma of anyone kind enough to give me their
> > wisdom.

> We made the jump to TCL/TK last year for the user interface portion
> of our real time status mapping application.  We respond to events
> generated from a Computer Aided Dispatch System, an E-911 interface,
> and Automated Vehicle Location system (GPS), and a radio system.

> Our system isn't strictly real time, but we're real time as far as
> operator is concerned.  So far, TCL/TK doesn't seem to be getting in
> our way.  In fact, the more we work with it, the more functionality
> we keep moving out to the TCL/TK level rather than C code.

We use custom realtime extensions to pump realtime data around our
network, care has to be taken in the design and implementation to ensure
the code is fast, but we pump live market data from many exchanges
around the work using this stuff in our production systems and have
found it to be fine.

The key thing it does make you do is learn coding styles that are more
optimal, but I find that this has lead to easier to read code.

The typpical load can be up to several hundred 100+ byte messages per
section, the flat out spend of the system (nop consumers of data is
nearer 2000 messages per second, but at that speed you have only about
100 us to process the message, which is not very long.

In most cases I have found it perfectly fine if the callback processing
the data and do so in 2 ms, you would be suprised just how much you can
do in 2 ms if you really tighten the path of execution up to the bare
essentials



Sun, 19 Jul 1998 03:00:00 GMT  
 TCL for real-time control app?

Quote:

>    Can anyone give me some advice?

>    I'm slated to develop a GUI console application for a
>large mechanical system.  The current plan is to connect a
>SparcStation to a number of separate VME chassis; each VME
>chassis will in turn be controlling an independent mechanism.  
>Communications between the VMEs and Sparc will be via Sockets.

>    One possibility that has been mentioned for this console
>app is implementing it via TCL.  I don't know anything about TCL,
>but, in view of what will probably be the asynchronous,
>event-driven environment that the console needs to deal with, I
>am worried that a script language will not be up to the task.

>    Does anyone have any experience (good or bad) using TCL
>to monitor and control real-time and/or event-driven processes?  
>I don't (as usual!) have a huge amount of time to decide this
>fundamental architectural question; I will make a substantial
>contribution to the karma of anyone kind enough to give me their
>wisdom.

We've investigated just this situation for control of astronomical telescopes,
instruments and detectors.  We had a lot of success with a prototype interface.

Our architecture distinguishes command/status transactions (generally the
result of button pushes or menu choices) from the state data-flows driving the
mimic diagrams.  All user-invoked transactions are handled in subprocesses of
the GUI, which gives us easier parallelism and allows us to cancel
transactions. I would _hate_ to have to write all the transactions as
single-process event-driven code. The data-flows running the mimic diagrams are
wired directly into the GUI as each message can be handled separately and
independently of context.

The system is built over a message-passing system supplied by the
Anglo-Australian Observatory; the AAO have integrated their message facility
with Tcl/Tk which makes things a lot easier.

My experience so far is that it works, provided that the graphics can keep up
with the messaging.  Running on a SPARCstation 5/70, I have had an animated
diagram of a filter-wheel updating at 10 Hz; this is quite a complicated
redrawing cycle and uses about 25% of the CPU power.  Text output is a
potential problem as the Tk 4.0 text widget seems to run rather slowly.  I can
push messages into the text lot at a higher rate (believed to be >100Hz but I
haven't done accurate measurements) than I can get them displayed.

It may be that compiling the Tcl code, and using compiled versions of the
widgets will help.
_________________________________________________________________________

Software Engineering Group                      
Royal Greenwich Observatory                          Tel:    +44-1223-374767
Madingley Road, Cambridge, CB3 0HS, UK               Fax:    +44-1223-374700
____________________________________________________________________________



Sun, 19 Jul 1998 03:00:00 GMT  
 TCL for real-time control app?
The fact that TCL commands can always be optimized by converting them to C
commands with the same interface means that even if you experience throughput
problems with realtime events, you can always optimize the bottleneck code.
Chances are, you won't have to, since TCL is pretty darn fast for an
interpreted
language.  We have a system monitoring and graphing realtime data from
factory-floor equipment, all done in TCL/TK, and it's faster than the C++
system it replaced.  Much of that is due to the cleaner design that TCL/TK
allows.  The app I mentioned, by the way, hasn't required any C optimization so
far; it's pure TCL/TK.


Mon, 20 Jul 1998 03:00:00 GMT  
 
 [ 10 post ] 

 Relevant Pages 

1. Time to REAL & REAL to time

2. IMAQ for real time app?

3. Everyday Oberon + real-time apps.

4. ANNOUNCE: GroupKit 3.2 (real-time groupware toolkit + apps)

5. Lisp in real-time apps?

6. re Oberon / Real time control :-(

7. Oberon / real time control :-(

8. Real Time Control in the Micro-second Range

9. real-time run control

10. TCL and real time

11. Announce: Real-time 3D Graphics for Tcl/Tk

 

 
Powered by phpBB® Forum Software