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
- Replies:
- Re: MEDM widgets Robert Soliday
- References:
- Re: MEDM widgets Ken Evans
- Navigate by Date:
- Prev:
Re: MEDM widgets Ken Evans
- Next:
Re: MEDM widgets Robert Soliday
- Index:
1994
1995
1996
1997
1998
1999
<2000>
2001
2002
2003
2004
2005
2006
2007
2008
2009
2010
2011
2012
2013
2014
2015
2016
2017
2018
2019
2020
2021
2022
2023
2024
- Navigate by Thread:
- Prev:
Re: MEDM widgets Ken Evans
- Next:
Re: MEDM widgets Robert Soliday
- Index:
1994
1995
1996
1997
1998
1999
<2000>
2001
2002
2003
2004
2005
2006
2007
2008
2009
2010
2011
2012
2013
2014
2015
2016
2017
2018
2019
2020
2021
2022
2023
2024
|