Experimental Physics and Industrial Control System
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
<2018>
2019
2020
2021
2022
2023
2024
- 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
<2018>
2019
2020
2021
2022
2023
2024