Experimental Physics and
Industrial Control System

 

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

               

To:	"Dalesio, Leo" <[email protected]>, Carl Schumann <[email protected]>, [email protected]
Subject:	Re: Recommended display manager?
From:	"Kasemir, Kay (ky9)" <[email protected]>
Date:	Wed, 20 Aug 2008 12:04:03 -0400
In-reply-to:	<[email protected]>

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