Experimental Physics and Industrial Control System
Hi Tom,
We have started to design a specific version of CSS dedicated to the SPIRAL2 control system, currently under construction.
Our system is based on a Linux hosts sharing the same NFS file system. A unique operator account controls the facility. This account is used by a team of 3 operators plus beam experts and equipment responsible fellows.
This specific CSS distribution, named CSS-op, mainly oriented to BOY, can work on a unique workspace shared by several nodes. (We succeeded to persuade eclipse not to put toolbars everywhere.)
On one hand, CSS BOY will be mainly used for interactive supervision screens.
On the other hand, we planne to use CSS BOY for whole facility synoptic screens displayed on four fixed monitors.
Specify widgets dedicated to SPIRAL2 equipment were developed, adapted to this two needs described above.
We are currently packaging a Spiral2 CSS distribution for our collaboration, and we hope to finalize this work by the end of January 2014. We will invite you to test/evaluate this distribution if you want to. Let us known if you are interested in.
You can see a snapshot (slide 14) :
https://indico.cern.ch/materialDisplay.py?contribId=59&sessionId=11&materialId=slides&confId=274807
Dominique Touchard
________________________________________
De : [email protected] [[email protected]] de la part de [email protected] [[email protected]]
Date d'envoi : mercredi 18 décembre 2013 17:37
À : [email protected]
Objet : Design strategies for CSS BOY screens
Hi all,
We're currently evaluating CSS and BOY as an EDM replacement, and I am considering how display screens on beamlines might look in this framework.
Currently we have an EDM "Synoptic" view of the beamline, with icons that show the status of each component on the beamline. Clicking on one of these icons brings up a summary screen for the objects that make up the component (motors, temperatures, diode readings, etc.) These summary screens are mainly auto-generated from tags in the EPICS database, but a significant minority are manually created. Clicking through from one of the summary screens takes you to manually created detailed screens for that object.
All of this means that a typical desktop might look like this:
http://controls.diamond.ac.uk/downloads/other/files/EDMScreenShot.png
Multiply this by 4 monitors and 8 Linux workspaces and users have an awful lot of screen real estate to get lost in. The main synoptic typically gets buried in the background, so the users open another one, then you have multiple copies of everything and can never find what you're looking for.
Now the simplistic approach when converting to CSS BOY would be to translate every EDM screen into a BOY screen, launched in its own window. But then we aren't really solving any problems, we're just making BOY look like EDM, and it takes a lot of work to persuade eclipse not to put toolbars everywhere...
Another simple solution would be to use tabs, default action is open in current tab, with an option to open in a new tab. This solves the mess of windows, but all our EDM screens are different sizes, so if we assume a large central area for the current BOY screen, then small screens with only a couple of widgets on them mean rather a lot of wasted space.
So how have other sites designed their BOY screens? Are most of your opi screens similar sizes? Do you make use of the various different tear off tabs that eclipse offers you? Do you open multiple windows on multiple workspaces? Do you try to manage how the users perspective should look, or do you leave it to the users to dock their windows where they like?
Any feedback/screenshots gratefully received, anything that helps us get better at GUI design has got to be a good thing!
Thanks,
Tom Cobb
--
This e-mail and any attachments may contain confidential, copyright and or privileged material, and are for the use of the intended addressee only. If you are not the intended addressee or an authorised recipient of the addressee please notify us of receipt by returning the e-mail and do not use, copy, retain, distribute or disclose the information in or attached to the e-mail.
Any opinions expressed within this e-mail are those of the individual and not necessarily of Diamond Light Source Ltd.
Diamond Light Source Ltd. cannot guarantee that this e-mail or any attachments are free from viruses and we cannot accept liability for any damage which you may sustain as a result of software viruses which may be transmitted in or with the message.
Diamond Light Source Limited (company no. 4375679). Registered in England and Wales with its registered office at Diamond House, Harwell Science and Innovation Campus, Didcot, Oxfordshire, OX11 0DE, United Kingdom
- References:
- Design strategies for CSS BOY screens tom.cobb
- Navigate by Date:
- Prev:
Re: Design strategies for CSS BOY screens Pearson, Matthew R.
- Next:
New sequencer release fixes build problem on Windows Benjamin Franksen
- 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: Design strategies for CSS BOY screens tom.cobb
- Next:
RE : Design strategies for CSS BOY screens Touchard Dominique
- 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