Experimental Physics and Industrial Control System

For the SPIRAL2 project in construction at Ganil and aiming to start its commissioning next year,  we decided to carry out an investigation concerning the GUI design, our specific needs for the control command being:

Could we define a special beam line widget library according to the machine specificities ? 
Could the tool be used by operators in order to let them developing their own synoptic?
Is there the ability when in operation mode to lock the functionalities to prevent users making mistakes or being lost within the GUI panel ?

In 2010 we have started to use CSS BOY to develop beam lines command control screens. Charles Henry Patard in our lab has made a special work to adapt this IDE to operators' needs. The CSS product presented for operation only supports a restrictive BOY implementation and a data browser instance. We are presently showing the work to our future users for feedback, aware that it is not yet an operational feedback.
We hope in the times to come to share this experience with other labs.

On the same way, we are going to develop an accelerator "widget" library to standardize the look and feel.

These high level needs expressed over mean that CSS/BOY is a mature product. To go further, CSS/BOY is the best GUI tool we have ever seen in the EPICS community.


Thanks again to Kay and Chen for their work and help.

The SPIRAL2 control command team.

-----Message d'origine-----
De : [email protected] [mailto:[email protected]] De la part de Dalesio, Leo
Envoyé : mercredi 29 février 2012 15:57
À : Kasemir, Kay; Matthieu Bec; [email protected]
Objet : RE: Operator display description, to get off QT-based tools: Expressions of interest requested

Underlying any good display tool, is a robust communication layer that separates the communication threading and performance from the display behavior. This communication layer has a lot of different aspects other than caching/queing - connection management, combining requests to optimize performance, optimizing memory management as connection are made and broken, cache connections through reconnect events.

In addition to these synoptic display issues - are the idea of an integrated operator tool set. For me, an appealing part of CSS is the ability to drag and drop things from the synoptic display tool to the operator log and from the operator log in into the archive data browser. These interactions between tools are a very important aspect.

Then on the other side - is the ability of the commissioners and testers to use scripts to do ad-hoc data analysis and manipulation. The tools to display these results should be readily available. 

It would be great if you could get all of this and outrageous performance in one environment. Perhaps the requirements push toward different solutions.

Looking forward to the iscussion.

Bob

________________________________________
From: [email protected] [[email protected]] on behalf of Kasemir, Kay [[email protected]]
Sent: Wednesday, February 29, 2012 9:31 AM
To: Matthieu Bec; [email protected]
Subject: Operator display description, to get off QT-based tools:       Expressions of interest requested

Hi:

Well, you did it! I was sitting on my hands trying to
stay out of this, but now Matthieu brings up the key point:

>"what really makes a user interface"?
>
>buttons, textbox, graphics, etc - they all do that...
>
>Could there be a reasonably (good) standard to define user interfaces?
>can it be modeled? formally (xsd like) defined?
>
>Would that bring cross compatible DMs (qt/eclipse/etc)..

It's relatively easy to create the basics of a new display tool,

something that can edit and display lines, rectangles, labels,
text-updates,
plus it has a cute meter widget.
I think the first cut of EDM was done in two months,
and it looks like there are already many Qt-based tools at that level.

What comes next is that people build displays for whatever tool they pick,
while the remaining 10% of the display tool features require 90% of the
time
to make it all robust.

Finally, you're stuck with your display tool because your display
descriptions
contain more representation than meaning.
Way back at LANL I remember edd/dm screens that used many rectangles,
offset by just one pixel and using different shades of a color
to simulate "raised" or "sunken" borders.
At SNS, many edm displays have rectangles with a label on top
of the top-left corner to create a "named group" of widgets.
Or hidden buttons writing to local PVs combined with conditionally
visible stuff and embedded displays to create "tabbed" panels.

In principle we know better!
We prefer source code over binaries;
HTML with style sheets and "<h1>" over "<b><huge><font color=...>";
Docbook or LaTeX over MS Word.
If you do use MS Word, employ styles like "Emphasis" and not "italic,
Comic Sans MS, ...".

A good display tool should have widgets with options to select


"alarm sensitive border", "alarm sensitive foreground color", "alarm
sensitive background color",
"raised border", "sunken border" because that describes the meaning of
what you want.
Sure, if you add one black and one white rectangle on top of the widget
you can get
the same "raised border" effect.
If you associate your background color with a "dynamic color" you can get
the same
"alarm sensitive background color".
But when you later want to translate that display for another tool, you'll
have a hard time
figuring out if that rectangle is part of a very essential piping diagram,
a "raised border"
that you might want to translate, or just visual gimmickry that you would
rather omit.
.. if the flickering color is essential for alarm info, or if it's just a
light show
that seemed like a good idea at the time.

A good display tool should also have
* Macros for fonts and colors so you can define TITLE etc.
  instead of Times-bold-...
* an "LED" widget so you don't need to add
  circles that happen to change color if you
  want to create an LED-type indicator.
* a Group widget that can wrap other widgets
  to create a real 'group' of widgets both
  visually (border, label, ...) and semantically
  (editor can move, resize, copy, paste them as a group, ...)
* a Tab widget that can wrap other widgets
  to create a real set of 'tabs' both
  visually and semantically

Thanks,
Kay

References:

Operator display description, to get off QT-based tools: Expressions of interest requested Kasemir, Kay

RE: Operator display description, to get off QT-based tools: Expressions of interest requested Dalesio, Leo

Navigate by Date:

Prev: RE: ASYN Communication through windows serial port (via USB) Mark Rivers

Next: References about EPICS Florian Feldbauer

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: Operator display description, to get off QT-based tools: Expressions of interest requested Dalesio, Leo

Next: Re: Operator display description, to get off QT-based tools: Expressions of interest requested J. Lewis Muir

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