Argonne National Laboratory

Experimental Physics and
Industrial Control System

2002  2003  2004  2005  2006  2007  2008  2009  2010  2011  2012  2013  2014  2015  2016  2017  <20182019  2020  2021  Index 2002  2003  2004  2005  2006  2007  2008  2009  2010  2011  2012  2013  2014  2015  2016  2017  <20182019  2020  2021 
<== Date ==> <== Thread ==>

Subject: Re: C++ APIs
From: Marty Kraimer <mrkraimer@comcast.net>
To: core-talk@aps.anl.gov
Date: Sun, 29 Jul 2018 12:13:41 -0400
In a previous message for this topic, The following question appeared:

Can you name even one part of the EPICS ecosystem which hasn't had multiple implementations, APIs, and/or wrappers?


Let me give some history of EPICS development that I believe makes the following statement true.

epics-base and asyn have evolved in an orderly way.


I will not address client tools like display managers, alarm handlers, archivers, etc.
But even here the choices did not grow without bound.

Now for a short history of epics-base and asyn.

The original EPICS was a joint development between LANL/GTA and ANL/APS.
This joint development started in 1990 based on GTACS, which was developed at GTA in the last half of the 1980s. The earliest version of epics that appears on the APS web site is R3.11 dated Jan 94. Earlier versions were available (1991 or 1992?) , but not as official releases.

EPICS is based on the following concepts:
1) IOC (input output controller)
A facility can  have an arbitrary number of IOCs.
Each IOC controls and acquires data from interfaces to hardware.
An IOC contains a memory resident database composed of DBRecords.
2) CA (channel access)
This is a TCP/IP client server network protocol.
A client API is defined and implemented.
A server is implemented that runs in a IOC and provides access to the DBRecord database.

The channel access client API has had no major changes since the early 1990s other than that a Java implementation was created.
The channel access network protocol has been stable since the early 1990s.
Both the client and server implementations had to be changed for the 3.14 releases.

In the early 1990s the only supported IOC platform was VME with a Motorola 68K processor.
The only operating system was vxWorks.
The only supported cross development system was a sun 68K workstation.
The native sun workstation compiler was used to create the executable for vxWorks.

Sometime in the 1990s sun came out with solaris based systems.
Solaris supports SPARC and x86-64 instead of Motorola 68K.
At this time vxWorks started supporting cross development platforms not requiring Motorola 68K.
This required changes to EPICS.
The R3.11, R3.12, and R3.13 releases were all VME/vxWorks only IOCs.
The last R3.13 release came out in April 2004.

In the last half of the 1990s, OSI(operating system independent) code was developed.
The initial target development was linux.
OSI was not part of EPICS releases until Nov 2000 with Base Release 3.14.0alpha1.

While epics base was evolving during the 1990s, support for interfacing to hardware was also evolving.

At APS, accelerator and beam-line controls people collaborated on hardware support. The first EPICS release already had the concept of record (RSET) and device (DSET) support.
But nothing was defined below this level.
Beamline controls started development of what is now called SYNAPPS.
The early support had many flavors of device support, all using DSET.
There was support for serial, analog, digital, gpib, etc.
Most of the support was for register based VME modules.
Then a VME board with Industry Pack (IP) carriers become available.
The IP VME board also ran vxWorks, but did not have enough memory for EPICS.
Based on a masters thesis, Hideos was developed,  was used by EPICS to communicate with the IP carrier.
This was replaced by something called MPF (Message Passing Facility).

With this experience asyn development started.
It replaces MPF and offers more capability.
It uses libCom, but is designed so that it can be used independent of the DBRecord database.
It does provide DSET support for standard record types.
It was originally designed only for asynchonous message based devices.
With a few minor changes asyn soon supported synchronous register based devices.

Asyn has evolved since the late 1990s to what is today.
areaDetector is a powerful example of the use of asyn and has also been an important driver of improvements to asyn itself.

Streams is another widely used method that an EPICS IOC can use to communicate with message based devices.
But it also uses asyn for the low level interfacing to hardware.

All or most of SYNAPPS has been changed to use asyn and/or Streams for interfacing to hardware.

The 3.15 and 3.16 releases are designed to maintain compatibility with the 3.14 releases.

EPICS 7 is designed to maintain compatibility with the 3.15 and 3.16 releases while also supporting pvData/pvAccess.




References:
C++ APIs Siniša Veseli
Re: C++ APIs Michael Davidsaver
Re: C++ APIs Marty Kraimer
Re: C++ APIs Siniša Veseli
Re: C++ APIs Michael Davidsaver
Re: C++ APIs Andrew Johnson
Re: C++ APIs Michael Davidsaver
Re: C++ APIs Hartman, Steven M.
Re: C++ APIs Marty Kraimer

Navigate by Date:
Prev: Re: C++ APIs Andrew Johnson
Next: Re: alarm handler issue Andrew Johnson
Index: 2002  2003  2004  2005  2006  2007  2008  2009  2010  2011  2012  2013  2014  2015  2016  2017  <20182019  2020  2021 
Navigate by Thread:
Prev: Re: C++ APIs Andrew Johnson
Next: Build failed in Jenkins: epics-base-3.15-vx55 #327 APS Jenkins
Index: 2002  2003  2004  2005  2006  2007  2008  2009  2010  2011  2012  2013  2014  2015  2016  2017  <20182019  2020  2021 
ANJ, 30 Jul 2018 Valid HTML 4.01! · Home · News · About · Base · Modules · Extensions · Distributions · Download ·
· Search · EPICS V4 · IRMIS · Talk · Bugs · Documents · Links · Licensing ·