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 | 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 |
<== Date ==> | <== Thread ==> |
---|
Subject: | Re: Recommended display manager? |
From: | "Elder Matias" <[email protected]> |
To: | <[email protected]> |
Date: | Wed, 20 Aug 2008 13:02:27 -0600 |
At the CLS in the 2002 time frame when we were choosing our
display manager we went with EDM and have been happy users since then. There
is a lot of really nice things going into Control System Studio and it
something we would look very closely at in the future. Applying the principle that every new project coming along
writes a new display manager we did not do a new display manager but we did
develop some EPICS/QT widget interface libraries. For the vast
majority of our applications EDM does the trick, however we have a few cases where
we need to integrate file handling for loading/saving data or some data
processing, or access into relational databases etc. For that we either
use our QT libraries or we use Matlab and some of the accelerator toolkit
libraries that come out of SLAC/ALS. In addition to Matlab and the QT
libraries there are also Python, Labview, Delphi, and several other approaches
that some of the other labs us. More recently we have started to move
towards using Java/AJAX for remote off-site applications. I agree with Bob and Kay on EDM and Control System
Studio. For the few cases where your user application needs to integrate
display manager functionality with other things such as file access/data
processing then there is quite a bit less consensus. Elder
Hi:
[email protected] on 8/20/08 11:29 : > 1) edm - mature, tested. nice edit features, good functionality and well > supported by John Sinclair who has done a fantastic job from the start. If you > need to deploy something in the next 6 months, I would use this one. Really looks like the best current pick of the medm/dm2k/edm group. But it's Unix-only. There is no integration with StripTool, ALH, Probe or your other contol system applications other than you may run them in parallel and copy/paste PV names between them.
> 2) CSS - goal is to create a more integrated operator environment. Great > progress and something to investigate. At NSLS II, we are installing and > investigating this one. We go operational in 3 years. DESY need to deploy it > in the near future. If you are a fan of Eclipse - this is your baby The "Synoptic Display" part of CSS would be my hope for a next display manager. No longer limited to Unix, based on the 'drawing program' idea of previous display managers, but much more flexible: There's no difference between a "Text Label" and a "PV Value Text Display". Both are just a text. The Label with value = "Some Text", the PV display with value = <current value of a PV converted to a string>. Each property (value, background color, position, font, ...) can be dynamically linked to PVs, and one can run the PV data through _javascript_ to for example change the color based on the PV's value, severity, time stamp, ...
And while previous installations had to use *edm, Striptool, probe, some custom tools and then duck-tape them together with something like tcl/tk so that operators could use them, CSS already ties them together much better: You can right-click on any PV anywhere and open Striptool (Data Browser) on them; when you add your site's PV name browser that looks at your LDAP repository (as for DESY) or relational database (as for SNS), that tool fits in with the other tools.
On the downside: - The synoptic display still has some issues. - What used to be tcl/tk duck tape is now called "bundling Eclipse plugins into an RCP application". I think the result is much better, but you still have to do it.
> 3) CAML - just out of the gate and perhaps a compliment to 1 and 2 - this is a > web based display manager as I understand it. It's a Channel Access client plugin for most web browsers (all but internet explorer) that allows you to use Channel Access from within _javascript_. But instead of writing your own _javascript_, you can create XML files in a certain format which describe what PVs you would like to display on your web page and how (text, meter, ...), and CAML creates the HTML and _javascript_ for you.
It probably offers the best performance for web-based channel access displays, because your web browser directly reads from channel access. One can argue about how easy it is to create the XAML XML files, compared to the drawing-program-type approach of the other display managers. At this time, if your users don't have the CA plugin installed, it just won't work. Better would be a 'Flash Player' type behavior where you get a popup that sais "To display this page, you need the Channel Access Plugin. Do you want to install it?" etc.
So actually I agree with Bob: 1) edm is the one you can use right now 2) CSS is a very interesting development, many pieces already usable, but still under development 3) CAML/web based displays are a great compliment, but unclear if a web interface will be a full replacement for all control room displays and applications.
-Kay
|