Experimental Physics and
Industrial Control System

Pete Jemian <[email protected]> · Thu, 1 Mar 2018 12:36:21 -0600

Let's try to focus on the OP (inadequacies of current display managers),

AND assume we have accepted the notion of introducing an intermediary

database. The point was existing display managers are each programmed

by a niche (such as EPICS) rather than large (such as Debian) community,

 Some, like me, have a need to translate existing display to YADM.

To illustrate why I believe adding an additional intermediate component

will not help resolve the OP, I offer this hypothetical:

I have considerable information and GUI screens in Odesta's Double

Helix. [1,2] While still alive today, it suffers EOL issues as do many

EPICS DM tools. Are there converters available to get my screens to

YADM? No. I'll have to write them. How about migrating the database

to a newer SQL database? Same issue.

The point is, I have not solved the DM issue by adding in a SQL backend

but have created a new DB issue for future maintenance. And the new SQL

backend already appears to have performance issues for a use case (as

Mark Rivers points out) that is growing quite popular.

Pete

[1] https://www.revolvy.com/topic/Helix%20(database)
[2] https://en.wikipedia.org/wiki/Helix_(database)

On 3/1/2018 12:20 PM, Mark Rivers wrote:

That's faster than most network cards already (@ 1 Gbps) so it seems to me one would want specialized equipment / setup.

So what? I am running the display manager on the same computer as the USB-3 camera.  I just use a COTS PC with a USB-3 port, no specialized equipment, and no need to go over the network at all.

With SQL data needs to flow:

- Camera -> EPICS IOC
- IOC->SQL (what software?)
- SQL->display manager

This is clearly not as efficient as today:

Camera->EPICS IOC
EPICS IOC->display manager

A quick Google search shows lots of performance problems with using SQL for images.  Do you know what bandwidth you can actually get for writing and then reading images from SQL?

If I want to use SQL and avoid network overhead I need to run SQL on every machine that is running the camera, including Windows (many cameras/detectors are Windows only).

This would significantly increase the complexity of deployment.

Mark

I think Samsung has HDs

that go at 500+ MB/s solid state, but you'd probably want everything to go
to a RAM drive, it's as fast as RAM.

It see that as an equipment issue, not a method issue.

-----Original Message-----
From: [email protected] [mailto:[email protected]]
Sent: Thursday, March 01, 2018 12:12 PM
To: Mark Rivers <[email protected]>
Cc: '[email protected]' <[email protected]>; Pete Jemian <[email protected]>; tech-
[email protected]
Subject: RE: Idea for new Display Manager

That's faster than most network cards already (@ 1 Gbps) so it seems to me
one would want specialized equipment / setup.  I think Samsung has HDs
that go at 500+ MB/s solid state, but you'd probably want everything to go
to a RAM drive, it's as fast as RAM.

It see that as an equipment issue, not a method issue.

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.
-----------------------------------------------------------

--
----------------------------------------------------------
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