EPICS Home

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  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 
<== Date ==> <== Thread ==>

Subject: Re: Remote I/O
From: "Pete R. Jemian" <[email protected]>
To: [email protected]
Cc: [email protected]
Date: Wed, 16 Dec 2009 11:03:56 -0600
Nick:

Like Mark, my experience with the Koyo PLCs is that they are reliable and low-cost.
They were exceptional for an entry-level system as there was very good documentation
supplied before and after purchase and good support from the distributor.
Also, the high uptime of this simple systems is much appreciated by beam line staff.
(For example, their output bits don't have to toggle when an IOC is rebooted.)

Several of our APS beam lines use the Koyo PLCs, mostly for implementation of
equipment protection systems.  Mark's EPICS support for Modbus/TCP communications
with the Koyo PLCs has been valuable.

The Koyo PLCs will fail the NSLS2 requirement for
> 4. Ability to produce and accept configurations and programs in a supported text format

This is of minor concern if you are not interested in running user code on the PLC.
But, for example, reading of ADC channels on the Koyo can be enhanced significantly
by running user code on the PLC.

The field experience with the Koyo PLCs (and this is likely common to other vendors)
is high reliability and easy field maintenance.

As APS has learned with our EPICS brick project, the Linux IOC may have
a cost advantage over the VME-based IOC if one can reduce or eliminate
any custom hardware that runs in the Linux IOC.  Otherwise, the cost
savings is lost in field maintenance and the rapid obsolescence cycle of
the Linux platform hardware.

Regards,
   Pete




Mark Rivers wrote:
Nick,
On a relatively small scale I've been pleased with the Modbus/TCP interface to Koyo PLCs from Automation Direct. These PLCs allow direct communication with the I/O points through Modbus. Some other manufacturers only allow Modbus access to memory registers, which the PLC program must read/write with the I/O point value. There is a scanner running, but the Koyo PLCs are very inexpensive so cost is really not much of an issue. Mark
________________________________

From: [email protected] on behalf of [email protected]
Sent: Wed 12/16/2009 6:44 AM
To: [email protected]
Subject: Remote I/O




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








--
----------------------------------------------------------
 Pete R. Jemian, Ph.D.                <[email protected]>
 Beam line Controls and Data Acquisition, Group Leader
 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.
-----------------------------------------------------------

Replies:
Re: Remote I/O David Dudley
References:
Remote I/O nick.rees
RE: Remote I/O Mark Rivers

Navigate by Date:
Prev: RE: Remote I/O Mark Rivers
Next: Re: Remote I/O Rolf Keitel
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 
Navigate by Thread:
Prev: RE: Remote I/O Mark Rivers
Next: Re: Remote I/O David Dudley
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