Experimental Physics and
Industrial Control System

[email protected] · Thu, 1 Mar 2018 09:45:34 -0800 (PST)

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