Emmanuel,
I think we have been doing something similar. When we initially built
the CLS we used a design strategy of embedding small single board
computers (http://www.sil.sk.ca/micro.html) in each of our power
supplies, motor controllers, etc.
Over the years the design has evolved....
Today depending on the application we sometimes embedded IOCs, however
we are more likely to embedded Ethernet based PLCs and then have central
servers running multiple softIOC applications perform the Modbus<->CA
translation.
We still make extensive use of IOC computers
(http://www.moxa.com/product/UC-7408.htm) for RS-232 devices that run
EPICS. These are usually installed in the same rack as the equipment
being monitored.
I think a better way of this doing this is to adopt a service oriented
architecture (SOA). We have done this with a "Wrapper" around EPICS on
several of our beamlines that permits end stations to be moved between
our soft x-ray beamlines. At this point we are using an in-house
protocol however, in the long run WS is likely the right choice.
What would be an interesting approach is the development of common EPICS
WSDL specs across the EPICS community to permit the integration of
systems at the system level instead of the PV level. I think adopting
some of the emerging standards around SOA and web-services and seeing
EPICS evolve in that direction has a lot of potential benefit. At that
point you get real plug-and-play. This is the direction we have been
taking with our remote access system.
Elder
-----------------
To: Mark Rivers <[email protected]>
Subject: RE: Network plug and play epics devices
From: Emmanuel Mayssat <[email protected]>
Date: Fri, 24 Aug 2007 15:52:44 -0700
Cc: epics <[email protected]>
In-reply-to:
<DC0D3CA127373142BB40E5C6FA63B4D1010C1B94@CARSMAIL1.CARS.APS.ANL.GOV>
References:
<DC0D3CA127373142BB40E5C6FA63B4D1010C1B94@CARSMAIL1.CARS.APS.ANL.GOV>
Yes, it is plug and play.
But let's imagine that now you do this for all of your devices
(chillers, modulators, x-ray detectors...). Let's take the example of a
chiller.
A chiller usually comes with a serial or Ethernet interface. A computer
is not included (contrary to detectors;). So you add one (let's call it
a picotux computer http://en.wikipedia.org/wiki/Picotux or a gumstix).
You install epics and chiller driver on computer stick. As you do so
your chiller has just become "plug-and-play".
Now, let's create a *generic* chiller interface. So PV are
TemperatureSetPointAO
ReadBackTemperatureSetPointAI
CurrentWaterTemperatureAI
AlarmMBBI
Once connected to network all of those PVs are available.
Now I decide to change the chiller from a Schreiber to a Polyscience
(or change detector from a Roger to a Mar). Because both of the chillers
have the generic interface the control system does not perceive the
change. So no compilation, database changes are needed. No need of a
computer engineer either (he programmed the computer prior chiller
installation). In other words, only a technician is required...
To me, it appears to be an interesting design because contrary to most
of you, I have several identical sites to maintain. Plus most of those
sites are at remote locations (+ I need permission from 3rd party for
remote access). Also, at remote sites hardware may be slightly different
but software has to be the same.
Now if you push this design to the limit, where all epics controlled
device are "plug-and-play" , then it seems that your high level software
(extensions) are immune to hardware changes.
The ioc that is on the device could be seen as a software patch to the
control system.
As anybody considered such a design, were you turn all of your devices
into EPICS embedded ones?
--
E
On Fri, 2007-08-24 at 13:40 -0500, Mark Rivers wrote:
> I'm not quite sure I know what you mean, but I think we are doing what
> you are suggesting. We have, for example, x-ray detectors (MAR,
Roper)
> that have an EPICS soft IOC running on the Linux or Windows computer
> that controls the detector. When we turn on the detector and its soft
> IOC boots we can then control the detector from other IOCs that run
the
> rest of the beamline. Is that plug and play?
>
> Mark
>
>
> > -----Original Message-----
> > From: [email protected]
> > [mailto:[email protected]] On Behalf Of Emmanuel Mayssat
> > Sent: Friday, August 24, 2007 1:14 PM
> > To: epics
> > Subject: Network plug and play epics devices
> >
> > Hello all,
> >
> > In though, I have been tinkering with a network plug-and-play epics
> > devices. Let's imaging that you have a new device you want to
control
> > through EPICS. You connect it, power it, and allow for network
> > communication.
> > Now in practice, the device is not under epics control yet.
> > But what if the device includes an embedded computer with the
> > associated
> > epics ioc? Then when you plug it to the network, the PV are
> > immediately
> > available...
> >
> > Is anybody using such a design?
> >
> > --
> > Emmanuel
> >
> >
- Navigate by Date:
- Prev:
RE: Network plug and play epics devices Mark Rivers
- Next:
Programmers position (again) LYNCH, Damien
- Index:
1994
1995
1996
1997
1998
1999
2000
2001
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: Network plug and play epics devices D. Peter Siddons
- Next:
number of iocs in a control system Emmanuel Mayssat
- Index:
1994
1995
1996
1997
1998
1999
2000
2001
2002
2003
2004
2005
2006
<2007>
2008
2009
2010
2011
2012
2013
2014
2015
2016
2017
2018
2019
2020
2021
2022
2023
2024
|