EPICS Controls Argonne National Laboratory

Experimental Physics and
Industrial Control System

1994  1995  1996  1997  1998  1999  2000  2001  2002  2003  2004  2005  2006  2007  2008  <20092010  2011  2012  2013  2014  2015  2016  2017  2018  2019  2020  2021  2022  2023  2024  Index 1994  1995  1996  1997  1998  1999  2000  2001  2002  2003  2004  2005  2006  2007  2008  <20092010  2011  2012  2013  2014  2015  2016  2017  2018  2019  2020  2021  2022  2023  2024 
<== Date ==> <== Thread ==>

Subject: Re: Remote I/O
From: Kazuro FURUKAWA <[email protected]>
To: [email protected]
Cc: [email protected]
Date: Thu, 17 Dec 2009 05:30:08 +0900
Hello Nick, 

We have requested equipment group to consider Ethernet 
connectivity since 15 years ago, because of lack of our 
manpower.  10 years ago the number of PLCs exceeded 120, and 
now 180 for 600m KEK Linac.  Some of them strictly required 
robustness of PLCs, but many other mainly require remote I/O 
capabilities.  Most of them were from Yokogawa, mainly because 
only Yokogawa had provided program download capability over 
Ethernet.  They were relatively reliable.  That was a period 
of "Everywhere TCP".  

CAMAC crates, GPIB instruments, temperature sensors, etc. 
were connected over TCP, and some others were connected thru 
Lantronix XPort.  "Everywhere TCP" was remote I/O over 
Ethernet. 

Nowadays at KEKB, we move further to "Everywhere EPICS-IOC".  
We started to embed IOCs on to controllers.  If we have to 
think about failure recovery, etc for remote I/O, why we don't 
just use Channel Access.  If we use IOC, we can use database 
links, sequencer, as well as CA. 

As we asked Yokogawa to provide Linux CPU on PLC, we started 
to embed IOCs on to Yokogawa PLCs.  That eliminates the code 
managements at two places of PLC and IOC.  We don't need 
ladder program conversion to XML.  It is a kind of "Poorman's 
VME", instead of PLC.  

While we keep many VMEs, we are using/evaluating 
 IOC on PLCs
 IOC on Windows on oscilloscopes 
 IOC on FPGAs
 IOC on microTCA/AMC (on FPGA)
I admit that some of them are not cheap, but the balance 
between resources justify them.  

We are now studying the balance to configuration management 
of the infrastructure like name servers, gateways, etc. 

Cheers, Kazuro. 

>>> On Wed, 16 Dec 2009 12:44:54 JST,  <[email protected]> wrote;
> 
> At Diamond we are considering what to use for the next generation of
> discrete I/O. Currently we have a lot of VME based hardware, but we are
> considering a good architecture for a Linux world.
> 
> The model that we are considering is a soft IOC on a Linux system
> communicating over Ethernet using an open, industry standard protocol to
> distributed DIN-Rail mounted I/O points. These I/O points take in
> Ethernet and are powered from a 24V bus that will run around the
> hardware area.
> 
> This eliminates any dependence on a specialized bus architecture (apart
> from Ethernet) on the Linux system, so they can be commodity PC's, and
> hopefully allows us to use widely available, cheap, industrial modules
> for I/O. It will not completely replace all of the requirements
> currently serviced by VME, but would be able to satisfy most of them,
> with the remaining few being serviced by the occasional VME system (or
> FPGA, or some other bus, or something else entirely in the future...).
> 
> This email is to poll the EPICS community as to the experience people
> have had, and recommendations for and against.
> 
> The sort of thing we have identified are:
> 
>  1. Modbus/TCP based modules, such as the Acromag Busworks series
> http://www.acromag.com/models.cfm?Product_Function_ID=28&Category_ID=22&;
> Group_ID=2
>  2. EtherCAT base modules, such as those from Beckhoff:
> http://www.beckhoff.com/
>  3. Standard PLC systems where (as distinct from the other two), you
> take Ethernet to a PLC controller which then has a series of modules it
> talks to in a variety of possible ways.
> 
> So, is anyone willing to share their experiences with these or similar
> systems,
> 
> Cheers,
> 
> Nick Rees
> Principal Software Engineer           Phone: +44 (0)1235-778430
> Diamond Light Source                  Fax:   +44 (0)1235-446713
> 
> -- 
> This e-mail and any attachments may contain confidential, copyright and or privileged material, and are for the use of the intended addressee only. If you are not the intended addressee or an authorised recipient of the addressee please notify us of re
> ceipt by returning the e-mail and do not use, copy, retain, distribute or disclose the information in or attached to the e-mail.
> Any opinions expressed within this e-mail are those of the individual and not necessarily of Diamond Light Source Ltd. 
> Diamond Light Source Ltd. cannot guarantee that this e-mail or any attachments are free from viruses and we cannot accept liability for any damage which you may sustain as a result of software viruses which may be transmitted in or with the message.
> Diamond Light Source Limited (company no. 4375679). Registered in England and Wales with its registered office at Diamond House, Harwell Science and Innovation Campus, Didcot, Oxfordshire, OX11 0DE, United Kingdom

-----
Kazuro FURUKAWA <[email protected]>
 Linac&KEKB,  High Energy Accelerator Research Organization (KEK), Japan
 Telephone: +81-29-864-5200 x4316,  Facsimile: +81-29-864-0321

References:
Remote I/O nick.rees

Navigate by Date:
Prev: Re: Remote I/O Stephen Lewis
Next: RE: Remote I/O nick.rees
Index: 1994  1995  1996  1997  1998  1999  2000  2001  2002  2003  2004  2005  2006  2007  2008  <20092010  2011  2012  2013  2014  2015  2016  2017  2018  2019  2020  2021  2022  2023  2024 
Navigate by Thread:
Prev: Re: Remote I/O Bruce Hill
Next: Re: Remote I/O Bruce Hill
Index: 1994  1995  1996  1997  1998  1999  2000  2001  2002  2003  2004  2005  2006  2007  2008  <20092010  2011  2012  2013  2014  2015  2016  2017  2018  2019  2020  2021  2022  2023  2024 
ANJ, 31 Jan 2014 Valid HTML 4.01! · Home · News · About · Base · Modules · Extensions · Distributions · Download ·
· Search · EPICS V4 · IRMIS · Talk · Bugs · Documents · Links · Licensing ·