Experimental Physics and
Industrial Control System

Geoff Savage <[email protected]> · Wed, 29 Mar 2000 13:12:26 -0600

Here's my plug for using Python for specialized tasks instead of Tcl/Tk,
Java, or Perl.  We have developed a Python module that implements channel
access.  Our GUI interfaces use Tk.  There are other window managers
available.  For increased speed you can code in C/C++ and then wrap the
code for use in Python.

Geoff

Ken Evans wrote:

>  > I'm Isabelle YAO and I work for the CEA-Saclay.
>  > I use EPICS R3.13.0.beta11, with a SOLARIS workstation.
>  > I'm in charge of the design of a vacuum synoptic using MEDM
>  > 2.3.5a.
>  > I would like to know if vacuum objects, like pumps, gauges,
>  > valves, already exist.
>  > Another question : is it possible to upgrade the library of
>  > MEDM by creating new objects (like magnets, DCCT, or
>  > insertion devices like Faraday cup, profilers, ...) ?
>
>      2.3.5a is the latest released version of the original MEDM, which
> was developed and continues to be developed at Argonne.  What I say
> here applies to this MEDM, not the European version, with which I have
> no experience.  Thomas has already responded in regard to the European
> version.  Also it should be noted that MEDM 2.3.6 has been released in
> beta and is nearly ready for release.  There are a lot of new
> features.
>
>     MEDM consists of a small number of objects.  It is not easy to add
> new objects because the code was not designed that way, unfortunately.
> There is no intention of adding new objects, especially large numbers
> of them.
>
>     So you have two choices.  (1) Make screens using the existing
> objects, or (2) write other applications to do more specialized tasks.
> We do both here.
>
>      (1) Most of the vacuum control here at the APS is done with MEDM
> screens using the existing objects.  Some of these screens are pretty
> complicated.  It might be worth a trip here to see what has been done
> and get samples, etc.  It's hard to communicate about GUI objects via
> the internet, and it could save a lot of your time and give you ideas.
>
>       Be assured that a great variety of screens can be designed with
> the small number of objects.  They are more than sufficient to control
> the APS, which is a reasonably large project.  We have literally
> thousands of MEDM screens, as do other sites like Jefferson Lab.  Some
> of these are pretty sophisticated.
>
>      (2) MEDM cannot be all things to all people.  The first
> consideration of MEDM is that it be stable and reliable.  This is not
> commensurate with feature bloat.  To let MEDM do what it does well, it
> is better to make separate applications for specialized and
> complicated tasks.  These are called Application Programs here and
> probably elsewhere.  At Argonne, we have done this through things like
> Tcl/Tk scripts, IDL, and C/C++ programs.  Mostly we have used Tcl/Tk
> to make small scripts that do specific tasks.  It is relatively easy
> to make a nice GUI interface with Tk.  We have a library of basic
> objects like the main menu bar, entry boxes, etc.  One feature of the
> objects in our library is that they have help built in, so it is hard
> not to program it.  That is, the user can get help on each entry box,
> etc. by clicking on it.  (This is something programmers tend to not
> provide well.)  For more information on the library and what we have
> done you could contact Michael Borland ([email protected]).
>
>      Nowdays, Perl or Java would be candidates for these types of
> programs, but Tcl/Tk has worked well.
>
>      The major advantage of writing Application Programs is that *you*
> have control and don't have to rely on someone far away to fix things
> for you.  You can do just what you want.
>
>      People with just basic programming skills can learn and use
> Tcl/Tk.  However, there are some applications that do require
> performance.  These are best written in C/C++.  If they need a GUI
> interface, it probably best implemented in Motif.  Programming Motif
> requires more than basic programming skills and far more code to do
> the same thing than in Tcl/Tk, but there are usually people around who
> are competent to do this.  Also there are several programs of this
> nature already written as EPICS Extensions.  One example is the Array
> Display Tool (ADT).  It is designed to handle arrays of PVs, such as
> BPM readings around a ring.  Or, vacuum readings around a ring.  It
> was originally written after discovering that MEDM could not really do
> that for several hundred BPMs to say nothing of having all the
> features that ADT has.  It and the other EPICS Extensions are
> available through the regular EPICS distribution channels.
>
>      At the APS the tendency has been to write C/C++ programs only
> when absolutely necessary.  The bulk of the Application Programs are
> Tcl/Tk, and this has worked out well.
>
>      I should say that part of the need for advanced programs has been
> supplied by the SDDS toolkit, also available as an EPICS Extension.
> This is a topic in itself, and you should refer to the EPICS
> Documentation or contact Mike Borland for more information.  These
> tools are more used for analysis than control.
>
>      Finally, in light of what Thomas said, I will say that MEDM 2.3.6
> has the ability to replace all or parts of the screen based on the
> values of a CALC expression involving up to five PVs.  These parts can
> be read from other ADL files.  This is a new feature of the MEDM
> Composite object and seems to be similar to what Thomas described.
> There are also animated GIFs where the frame displayed depends on a
> similar type CALC expression.  You could use these to display the
> state of a vacuum valve pictorially.  There is even a new Epics
> Extension called Simple GIF Animator (SGA) to help make the animated
> GIFs.  My advice, however, is to follow the KISS principle and keep it
> simple (and hence manageable and reliable).
>
>              -Ken

Experimental Physics and Industrial Control System

Experimental Physics and
Industrial Control System