EPICS Controls Argonne National Laboratory

Experimental Physics and
Industrial Control System

1994  1995  1996  1997  1998  1999  2000  2001  2002  2003  2004  2005  2006  2007  2008  2009  <20102011  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  <20102011  2012  2013  2014  2015  2016  2017  2018  2019  2020  2021  2022  2023  2024 
<== Date ==> <== Thread ==>

Subject: Re: How to use BOY/OPI to produce standalone simple displays
From: "Kasemir, Kay" <[email protected]>
To: Jimmy Johnson <[email protected]>, "[email protected]" <[email protected]>
Date: Wed, 01 Dec 2010 09:10:05 -0500
Hi:

On 11/30/10 19:16 , "Jimmy Johnson" <[email protected]> wrote:
>   Since the BNL collaboration meeting we have been experimenting with CSS. We
> have created a few custom products and have exercised BEAST including logging,
> BEAUTY, BOY and some miscellaneous tools against our current EPICS system.
And you didn't ask a single "how do I do this?" so far??
Outstanding!

> One thing I don¹t have a handle on is how to produce a locked down product
> that is little more than one or perhaps a small number of displays and nothing
> else, no menus, no perspective switching etc. Basically I want it so that when
> a user double clicks the application he is presented with a display screen
> (running OPI) and nothing more. Basic behavior you would get from a
> DM/MEDM/EDM screen.
I think you can do what you ask for.

Before getting to that, to elaborate on your comparison with *DM:
*DM doesn't include a single screen. It's just the screen-display-tool,
you create the screens.
*DM is not integrated with Probe, StripTool, ... None of them have a
preference GUI to configure the EPICS CA address list, there's no online
help that explains those. You have to know how EPICS_CA_ADDR_LIST happens to
be set in your environment.
*DM will also never be "locked down" in the sense that you describe:
The user is always free to move the *DM screens around, minimize them,
open a separate StripTool and place that on top of *DM etc.
On Linux/GTK/KDE or OS X the user can setup several "Workspace" or "Spaces",
i.e. several desktop arrangements and switch between them.
CSS/Eclipse gives you the same flexibility, but integrated for the control
system tools: You can move Preference Panels, Probe, EPICS PV Tree, ...
around, and it will remember the last locations through restarts of the
application. You can have several desktop arrangements ("Perspectives")
where the 'main' sections (operator displays, data browser plots) stay as
they are but the auxiliary views (preference panel, ...) can be arranged or
hidden as you like.

Back to what you could do instead...
See http://sourceforge.net/apps/trac/cs-studio/wiki/EclipseAndCSS
for an explanation of terms and some pointers.
Basically, you could take for example the BOY plugins and bundle them into
your own "MyDM" product. It could have a very limited menu bar, no
perspective switch.
It would include the display files that you want, and open your 'top level'
screen on startup. Technically, you'd have to create your own "Product" with
your own "Application" that defines the menu bar, includes the screens that
you want similar to the BOY example screens, automatically installing them
on first startup. You could also have your product automatically download
the latest screens, or always use screens behind an http://.... path.
That would be like the existing *DM. There would be no EPICS PV Tree, Data
Browser, Probe; they wouldn't show up in the context menu of PVs. You could
create a separate, standalone "MyProbe" application, so users would have to
start that separately, then copy/past PV names from "MyDM" to "MyProbe". Or
you could choose to combine BOY & Probe & EPICS PV Tree into one product,
the alarm tools into another product. It's all up to you.
Just as you can install either EDM & StripTool, or MEDM & StripTool, or DM &
Probe. With EDM, StripTool, Probe, ... you would typically install what you
want, then create something like a tcl/tk or top-level *DM screen that users
start to access these tools. Yet the tools remain standalone, no data
exchange beyond copy/paste, no common preferences and online help.
With CSS/Eclipse, the tcl/tk or top-level *DM screen changes into the
"Product". Creating that "Product" is more involved than hacking a tcl/tk or
top-level *DM screen. On the upside, the tools inside the product are more
integrated; the product can (auto-)update itself. You can as easily create
it for Windows as you can for Linux and OS X.

Thanks,
Kay



Replies:
RE: How to use BOY/OPI to produce standalone simple displays Jimmy Johnson
References:
How to use BOY/OPI to produce standalone simple displays Jimmy Johnson

Navigate by Date:
Prev: Build EPICS Base3.14.9 on Windows 张玉亮
Next: EPID Capfast symbol Philip Taylor
Index: 1994  1995  1996  1997  1998  1999  2000  2001  2002  2003  2004  2005  2006  2007  2008  2009  <20102011  2012  2013  2014  2015  2016  2017  2018  2019  2020  2021  2022  2023  2024 
Navigate by Thread:
Prev: How to use BOY/OPI to produce standalone simple displays Jimmy Johnson
Next: RE: How to use BOY/OPI to produce standalone simple displays Jimmy Johnson
Index: 1994  1995  1996  1997  1998  1999  2000  2001  2002  2003  2004  2005  2006  2007  2008  2009  <20102011  2012  2013  2014  2015  2016  2017  2018  2019  2020  2021  2022  2023  2024 
ANJ, 01 Dec 2010 Valid HTML 4.01! · Home · News · About · Base · Modules · Extensions · Distributions · Download ·
· Search · EPICS V4 · IRMIS · Talk · Bugs · Documents · Links · Licensing ·