All the displays managers for Epics *look* far behind what is available
from commercial systems, say Schneider or Rockwell. Which are themselves
far behind what programmers are doing today with, a modern operating
system or video games (also control interfaces). And that's what we're
talking about right, at least in part, how it looks, or how we display
data? Otherwise we could just use camonitor on a terminal with caput.
I think the key to having a decent display manager, one that adapts to new
technologies, better/different formats (say HTML5/PHP, Qt, text a la Lynx,
or some fancy Virtual Reality / VTK / QT3d initiative) is to have Epics
easily push/pull from a database (say MySQL, PostgreSQL). Once that is
done one could use any language, any system, to control and display data
as long as said language or method can access a typical database.
As a side benefit to using a properly setup database one would
automatically get an archive, and the benefits of database
synchronization/backup, and seamless data compression.
(Also if someone is excited and jumping in to do this my vote is for
submitting it the Package Management Debian/Ubuntu repository. I'm a
control systems engineer, and want to spend my time controlling systems,
not compiling very particular versions of modules, libraries, plugins, and
endless environment variables just to begin my work.)
My two cents & cheers!
James Richard Larsson
> On Wed, Feb 28 2018, Pete Jemian <[email protected]> wrote:
>> At this time, MEDM is an orphan piece of software. There are no
>> developers assigned to maintain it. Fantastic that it still works and
>> is still useful. Great job to its developers! MEDM's true end of life
>> will coincide with that of MOTIF, which library it uses. Recently, some
>> have made code changes in response to specific problems, but MEDM has no
>> maintainer.
>
> Despite it's annoying limitations, MEDM has a lot going for it. For
> instance, the simplicity of the file format makes it easy to dynamically
> generate screens, which is a very nice feature.
>
> At LIGO we're pretty stuck with MEDM just because of the sheer amount of
> work required to translate and test all of our existing screens. This
> problem exists no matter which new system we eventually decide to move
> to, so a requirement for any new system is a good translator.
>
> The activity on this thread is a pretty clear indication of the chaotic
> state of things on the display manager front right now. Hopefully the
> community will start to coalesce into a few good projects with strong
> backing. Here's hoping that the various, almost indistinguishable QT
> projects merge into one...
>
> jamie.
>
> ps: CSS is an abomination.
>
- Replies:
- Re: Idea for new Display Manager Pete Jemian
- Re: Idea for new Display Manager Matt Newville
- Navigate by Date:
- Prev:
Re: Idea for new Display Manager Jameson Graef Rollins
- Next:
Re: Idea for new Display Manager Pete Jemian
- 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: Idea for new Display Manager Hartman, Steven M.
- Next:
Re: Idea for new Display Manager Pete Jemian
- 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
|