Experimental Physics and
Industrial Control System

"Mark Engbretson" <[email protected]> · Thu, 1 Mar 2018 12:32:02 -0600

Since the very beginning of EPICS, people have been rolling their own GUI's on the various platforms that they support to be able to analyze and visualize their data in ways that  dumb displays of variables just can not handle.  <Nodding to Mark Rivers and his epics clients for Visual Basic and IDL> People still do that with Igor, Labview, Mathlab, <fill in your high level graphics and analysis GUI of choice>.

But technology has advanced now to the point where you can just as easily control (or at least monitor) your experiment from a Tablet or even your smart phone if you so desire and where  high end Area Detector system really shouldn't be using Xeon based Workstation class hardware but high end gaming configurations. Where people now want integrated analysis, data archiving and processing (Bluesky and Manta) and does everyone really still need to write their own code to center a slit, tweak up a motor the same way that they have been doing for the last . . . .30+ years?

Cross Platform application have tended to focus on the lowest common denominator tools available, and the effort of a relatively small handful of people with a vested interest in having software that *works* which the community all get the advantage of their efforts. <Again nodding in the direction of Mark Rivers> It should be possible to propose protocols (such as epics) , frameworks (such as Area detector) , and computational packages (such as BlueSky) so that all of our tools play nicely together and that display managers could be as easy to swap in and out as easily as changing application skins. 

Where effort could be shifted from pretty well everyone rebuilding and maintaining most of the same sources and codes to more centralized repositories of executables <once again pointing to Mark Rivers and Prebuilt Area Detector deployments) that are the official working versions instead of tech-talk being filled with questions and answers that mostly boil down to 1) Your not using the latest version of the sources and 2) The latest versions of the sources are actually the latest known to be working versions.

It is impossible to have 1 *thing* which covers all the various types of data acquisition, analysis, storage, visualization, etc. but it should be possible to promote technologies where certain things (i.e. motors, Area Detectors, perhaps GUI's) all attempt to look the same as much as possible, and that if you need some functionality, you should be able to plug it into an existing framework instead of reinventing the wheel once again.

Me

-----Original Message-----
From: [email protected] [mailto:[email protected]] On Behalf Of Mark Rivers
Sent: Thursday, March 1, 2018 11:50 AM
To: '[email protected]' <[email protected]>; Pete Jemian <[email protected]>
Cc: [email protected]
Subject: RE: Idea for new Display Manager

We want to display 2 mega-pixel RGB images at 30 Hz = 180 MB/s.  Is SQL going to handle that efficiently?

Mark

> -----Original Message-----
> From: [email protected] 
> [mailto:[email protected]] On Behalf Of [email protected]
> Sent: Thursday, March 01, 2018 11:46 AM
> To: Pete Jemian <[email protected]>
> Cc: [email protected]
> Subject: Re: Idea for new Display Manager
> 
> Well anyone interested in building a display manager right now has to 
> know about Epics and use Epics libraries - which is somewhat 
> specialized, and also how to program - also specialized.  If there was 
> a SQL database intermediary, then they only have to know how to 
> interact with a SQL database (part of a typical software curriculum).  
> It segregates the data/control from how said data is displayed or interacted with.
> 
> If the system used in a display manager changes, becomes outdated 
> (like Motif), no matter - the SQL database standards are the same.
> 
> As you say, "One can already use any language, any system, to control 
> and display data..." which is true, today - though I have trouble 
> compiling edm for Ubuntu 64.  With this method though, a rather 
> intensive effort admittedly, a display manager would be compatible 
> with languages of tomorrow too, ones not even invented yet.  As long 
> as they are SQL database compatible, which they will be, or they won't 
> take off as a language.
> 
> Cheers
> James Richard Larsson
> 
> 
> > Now I'm confused.
> >
> > On 3/1/2018 10:46 AM, [email protected] wrote:
> >> All the displays managers for Epics *look* far behind what is 
> >> available from commercial systems, say Schneider or Rockwell.  
> >> Which are themselves far behind what programmers are doing today 
> >> with, a modern operating system or video games (also control 
> >> interfaces).  And that's what we're talking about right, at least 
> >> in part, how it looks, or how we display data?  Otherwise we could 
> >> just use camonitor on a terminal with caput.
> >>
> >> I think the key to having a decent display manager, one that adapts 
> >> to new technologies, better/different formats (say HTML5/PHP, Qt, 
> >> text a la Lynx, or some fancy Virtual Reality / VTK / QT3d 
> >> initiative) is to have Epics easily push/pull from a database (say 
> >> MySQL, PostgreSQL).  Once that is done one could use any language, 
> >> any system, to control and display data as long as said language or 
> >> method can access a typical database.
> >>
> >> As a side benefit to using a properly setup database one would 
> >> automatically get an archive, and the benefits of database 
> >> synchronization/backup, and seamless data compression.
> >>
> >> (Also if someone is excited and jumping in to do this my vote is 
> >> for submitting it the Package Management Debian/Ubuntu repository.  
> >> I'm a control systems engineer, and want to spend my time 
> >> controlling systems, not compiling very particular versions of 
> >> modules, libraries, plugins, and endless environment variables just 
> >> to begin my work.)
> >>
> >> My two cents & cheers!
> >>
> >> James Richard Larsson
> >>
> >
> > What is the value in adding an additional intermediate component, 
> > such as a SQL database server, to solve the inadequacies of the 
> > various existing display managers?  That's a new piece of work for 
> > this discussion.  Each IOC already provides the data servers with a 
> > common protocol.  One can already use any language, any system, to 
> > control and display data as long as said language or method can access an EPICS IOC.
> >
> > Pete
> >
> >
> > --
> > ----------------------------------------------------------
> > Pete R. Jemian, Ph.D.                 <[email protected]>
> > Beam line Controls and Data Acquisition (BC, aka BCDA)
> > Advanced Photon Source,    Argonne National Laboratory
> > Argonne, IL  60439                    630 - 252 - 3189
> > -----------------------------------------------------------
> >        Education is the one thing for which people
> >           are willing to pay yet not receive.
> > -----------------------------------------------------------
> >
> >
> >
> 

Experimental Physics and Industrial Control System

Experimental Physics and
Industrial Control System